* Re: [PATCH] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Ayushi Makhija @ 2026-04-09 5:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut
In-Reply-To: <acVWseivbxLQ_uDM@baldur>
On 3/26/2026 9:28 PM, Bjorn Andersson wrote:
> On Thu, Mar 26, 2026 at 03:06:52PM +0530, Ayushi Makhija wrote:
>> On 3/24/2026 7:34 AM, Bjorn Andersson wrote:
>>> On Mon, Mar 23, 2026 at 03:52:29PM +0530, Ayushi Makhija wrote:
>>>> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
>>>> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
>>>>
>>>
>>> Please add Fixes: tag.
>>>
>>
>> Hi Bjorn,
>>
>> Sure, will add in new patchset.
>>
>>>> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
>>>
>>> Please start using your oss.qualcomm.com address.
>>>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
>>>> index 3837f6785320..6ba4e69bf377 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
>>>> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
>>>>
>>>> vreg_l12b_1p8: ldo12 {
>>>> regulator-name = "vreg_l12b_1p8";
>>>> - regulator-min-microvolt = <1200000>;
>>>> + regulator-min-microvolt = <1650000>;
>>>
>>> Are you sure it's not supposed to be 1.8V, given the name of the rail?
>>>
>>> Regards,
>>> Bjorn
>>
>> There was already discussion regarding the minimum voltage for this regulator on sm8550 target
>> on other upstream patch.
>>
>> Link: https://lore.kernel.org/all/aQQdQoCLeKhYtY7W@yuanjiey.ap.qualcomm.com/
>>
>> This values is according to the NT37801 panel sec
>> "The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
>> VDDI=1.65V~1.95V."
>>
>
> Yes, so the panel requires 1.65V, so regulator-min-microvolt needs to be
> at least that. But regulator-min-microvolt should account for all the
> consumers of the rail, are there any others?
>
> Which leads me to my question, the people designing the board named the
> rail VREG_L12B_1P8 in the schematics, why didn't they name it
> VREG_L12B_1P65?
>
> Please check all the consumers and make the regulator-min-microvolt work
> for all of them - if that's 1.65V, then your change is good.
>
> Regards,
> Bjorn
Hi Bjorn,
There is only one consumer of VREG_L12B_1P8 rail, i.e. NT37801 panel.
So regulator-min-microvolt as 1.65V should be fine for VREG_L12B_1P8 rail.
Thanks,
Ayushi
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: milos: Add Iris VPU v2.0
From: Dikshita Agarwal @ 2026-04-09 5:59 UTC (permalink / raw)
To: Alexander Koskovich, Vikash Garodia, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Luca Weiss, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260406-milos-iris-v1-3-17ed0167ba6f@pm.me>
On 4/6/2026 3:49 PM, Alexander Koskovich wrote:
> Add devicetree nodes for the Iris codec (VPU 2.0) found on the Milos
> platform.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> arch/arm64/boot/dts/qcom/milos.dtsi | 85 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index e1a51d43943f..07aa398c9695 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/clock/qcom,milos-dispcc.h>
> #include <dt-bindings/clock/qcom,milos-gcc.h>
> #include <dt-bindings/clock/qcom,milos-gpucc.h>
> +#include <dt-bindings/clock/qcom,milos-videocc.h>
> #include <dt-bindings/clock/qcom,rpmh.h>
> #include <dt-bindings/clock/qcom,sm8650-tcsr.h>
> #include <dt-bindings/dma/qcom-gpi.h>
> @@ -1517,6 +1518,90 @@ usb_1_dwc3_hs: endpoint {
> };
> };
>
> + iris: video-codec@aa00000 {
> + compatible = "qcom,milos-iris";
> + reg = <0 0x0aa00000 0 0xf0000>;
> +
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH 0>;
> +
> + power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>,
> + <&videocc VIDEO_CC_MVS0_GDSC>,
> + <&rpmhpd RPMHPD_CX>,
> + <&rpmhpd RPMHPD_MX>;
> + power-domain-names = "venus",
> + "vcodec0",
> + "cx",
> + "mx";
> +
> + operating-points-v2 = <&iris_opp_table>;
> +
> + clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
> + <&videocc VIDEO_CC_MVS0C_CLK>,
> + <&videocc VIDEO_CC_MVS0_CLK>;
> + clock-names = "iface",
> + "core",
> + "vcodec0_core";
> +
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_cfg SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mmss_noc MASTER_VIDEO QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> + interconnect-names = "cpu-cfg",
> + "video-mem";
> +
> + memory-region = <&video_mem>;
> +
> + resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
> + <&videocc VIDEO_CC_MVS0C_CLK_ARES>;
> + reset-names = "bus",
> + "core";
> +
> + iommus = <&apps_smmu 0x1960 0>,
> + <&apps_smmu 0x1967 0>;
> +
> + dma-coherent;
> +
> + /*
> + * IRIS firmware is signed by vendors, only enable on
> + * boards where the proper signed firmware is available.
> + */
> + status = "disabled";
> +
> + iris_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-240000000 {
> + opp-hz = /bits/ 64 <240000000>;
> + required-opps = <&rpmhpd_opp_low_svs>,
> + <&rpmhpd_opp_low_svs>;
s/rpmhpd_opp_low_svs/rpmhpd_opp_svs
> + };
> +
> + opp-338000000 {
> + opp-hz = /bits/ 64 <338000000>;
> + required-opps = <&rpmhpd_opp_svs>,
> + <&rpmhpd_opp_svs>;
> + };
> +
> + opp-366000000 {
> + opp-hz = /bits/ 64 <366000000>;
> + required-opps = <&rpmhpd_opp_svs_l1>,
> + <&rpmhpd_opp_svs_l1>;
s/rpmhpd_opp_svs_l1/rpmhpd_opp_svs
> + };
> +
> + opp-444000000 {
> + opp-hz = /bits/ 64 <444000000>;
> + required-opps = <&rpmhpd_opp_nom>,
> +
<&rpmhpd_opp_nom>;
s/rpmhpd_opp_nom/rpmhpd_opp_svs_l1
> + };
> +
> + opp-552000000 {
> + opp-hz = /bits/ 64 <552000000>;
> + required-opps = <&rpmhpd_opp_turbo>,
> + <&rpmhpd_opp_turbo>;
s/rpmhpd_opp_turbo/rpmhpd_opp_nom
Thanks,
Dikshita
> + };
> + };
> + };
> +
> videocc: clock-controller@aaf0000 {
> compatible = "qcom,milos-videocc";
> reg = <0x0 0x0aaf0000 0x0 0x10000>;
>
^ permalink raw reply
* Re: [PATCH 04/13] clk: amlogic: Add basic clock driver
From: Krzysztof Kozlowski @ 2026-04-09 6:12 UTC (permalink / raw)
To: Chuan Liu, Neil Armstrong, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-amlogic, linux-clk, devicetree, linux-kernel,
Martin Blumenstingl
In-Reply-To: <76ef272c-e09a-400e-b381-82d7f29760ca@amlogic.com>
On 08/04/2026 16:32, Chuan Liu wrote:
> Hi Krzysztof (& ALL),
> Thanks for review.
>
> On 2/9/2026 9:17 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On 09/02/2026 06:48, Chuan Liu via B4 Relay wrote:
>>> From: Chuan Liu <chuan.liu@amlogic.com>
>>>
>>> Implement core clock driver for Amlogic SoC platforms, supporting
>>
>> So how did all existing Amlogic SoC platforms work so far without basic
>> clock driver? Really, how?
>>
>> You are suppose to grow existing code, not add your completely new
>> "basic" driver just because you have it that way in downstream.
>>
>
> Firstly, apologies for the delayed response. I had intended to
> consolidate the V1 review feedback and come back with a clearer plan for
> V2 changes. In the meantime, Martin has provided many detailed and
> valuable suggestions - much appreciated.
>
> The original goal of optimizing the HW based on A9 and introducing a new
> clock driver is to reduce unnecessary complexity in the driver. On A9,
Nah, you just don't care about upstream and it is easier for you to
duplicate new code.
> we optimized the Clock/PLL controller HW to simplify driver performance,
> complexity, memory footprint, and reusability. Improvements on the HW
> side can also help drive corresponding enhancements in the driver:
> - Performance: Encapsulates sub-clock functions, reducing call paths
> - Complexity: Standardized register bits eliminate a large number of
> bit definitions (~1/3 of original code is defined register bit [1])
> - Memory: Object-oriented design avoids copy/paste for repeated clocks
Object oriented design? Sorry, what?
> - Reusability: Same controller works across SoCs without driver
> changes (or with minimal changes)
>
> The old meson driver required compromises to unify legacy controller
> characteristics and driver styles. On A9, we want a fresh start.
And maintainers don't want that. We expressed this many times already.
Not only in this thread - that's one of the most known feedbacks.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V10 4/4] thermal: qcom: add support for PMIC5 Gen3 ADC thermal monitoring
From: Daniel Lezcano @ 2026-04-09 6:12 UTC (permalink / raw)
To: Jishnu Prakash
Cc: jic23, robh, krzk+dt, conor+dt, agross, andersson, lumag,
dmitry.baryshkov, konradybcio, daniel.lezcano, sboyd, amitk,
thara.gopinath, lee, rafael, subbaraman.narayanamurthy,
david.collins, anjelique.melendez, kamal.wadhwa, rui.zhang,
lukasz.luba, devicetree, linux-arm-msm, linux-iio, linux-kernel,
linux-pm, cros-qcom-dts-watchers, quic_kotarake, neil.armstrong,
stephan.gerhold
In-Reply-To: <20260130115421.2197892-5-jishnu.prakash@oss.qualcomm.com>
On Fri, Jan 30, 2026 at 05:24:21PM +0530, Jishnu Prakash wrote:
> Add support for ADC_TM part of PMIC5 Gen3.
>
> This is an auxiliary driver under the Gen3 ADC driver, which implements the
> threshold setting and interrupt generating functionalities of QCOM ADC_TM
> drivers, used to support thermal trip points.
>
> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
> ---
> Changes since v9:
> - Replaced the break statement within scoped_guard() in tm_handler_work() with
> return statement to fix the error reported by kernel test robot.
>
> Changes since v8:
> - Made following changes to address Dmitry's comment to use module_auxiliary_driver():
> - Dropped the wrapper struct containing the auxiliary driver (struct adc_tm5_auxiliary_drv)
> which was originally meant to expose the TM interrupt callback to be called by
> main driver and replaced it with standalone definition of the auxiliary_driver struct.
> - Added call to adc5_gen3_register_tm_event_notifier() in probe to initialize the
> TM callback for main driver.
> - Replaced the module_init() and module_exit() calls with module_auxiliary_driver().
> - Made following changes to address Jonathan's comments:
> - Updated header files included in drivers/thermal/qcom/qcom-spmi-adc-tm5-gen3.c
> to follow IWYU (include-what-you-use) principles.
> - Added a DEFINE_GUARD() definition for mutex lock/unlock functions and replaced
> their existing calls with guard() and scoped_guard() statements using this definition.
> - Moved some variable declarations in tm_handler_work() to inside the for() loop.
> - Fixed if() check condition for low_temp in adc_tm5_gen3_set_trip_temp().
> - Dropped the wrapper function adc_tm5_gen3_disable_channel() around
> _adc_tm5_gen3_disable_channel() as it only calls the inner function with no other actions.
> - Replaced a pr_debug() call with dev_dbg() in tm_handler_work().
>
> Changes since v7:
> - Addressed following comments from Jonathan:
> - Replaced {0} with { } in tm_handler_work()
> - Simplified logic for setting upper_set and lower_set into
> a single line each, in tm_handler_work()
> - Cleaned up local variable declarations and high/low threshold
> check in adc_tm5_gen3_configure()
> - Moved cleanup action to disable all ADC_TM channels to probe
> end and added comment to describe it.
> - Fixed { } formatting in adctm5_auxiliary_id_table[].
>
> Changes since v6:
> - Addressed following comments from Jonathan:
> - Added error check for devm_thermal_add_hwmon_sysfs() call.
> - Used local variable `dev` in multiple places in adc_tm5_probe().
> in place of `&aux_dev->dev` and `adc_tm5->dev`.
> - Added a comment to explain cleanup action calling adc5_gen3_clear_work()
> near probe end.
> - Fixed return statement at probe end to return last called API's
> return value directly.
>
> Changes since v5:
> - Addressed following comments from Jonathan:
> - Corrected all files to follow kernel-doc formatting fully.
> - Cleaned up formatting in struct definitions.
> - Used sizeof() to specify length in register read/write calls
> instead of using integers directly.
> - Added comments in adc_tm5_probe() for skipping first SDAM for
> IRQ request and for usage of auxiliary_set_drvdata().
> - Corrected line wrap length driver file.
> - Moved INIT_WORK() and auxiliary_set_drvdata() to earlier
> locations to ensure they are ready when needed.
>
> Changes since v4:
> - Fixed a compilation error and updated dependencies in config as suggested
> by Krzysztof.
>
> drivers/thermal/qcom/Kconfig | 9 +
> drivers/thermal/qcom/Makefile | 1 +
> drivers/thermal/qcom/qcom-spmi-adc-tm5-gen3.c | 512 ++++++++++++++++++
> 3 files changed, 522 insertions(+)
> create mode 100644 drivers/thermal/qcom/qcom-spmi-adc-tm5-gen3.c
>
> diff --git a/drivers/thermal/qcom/Kconfig b/drivers/thermal/qcom/Kconfig
> index a6bb01082ec6..1acb11e4ac80 100644
> --- a/drivers/thermal/qcom/Kconfig
> +++ b/drivers/thermal/qcom/Kconfig
> @@ -21,6 +21,15 @@ config QCOM_SPMI_ADC_TM5
> Thermal client sets threshold temperature for both warm and cool and
> gets updated when a threshold is reached.
>
> +config QCOM_SPMI_ADC_TM5_GEN3
> + tristate "Qualcomm SPMI PMIC Thermal Monitor ADC5 Gen3"
> + depends on QCOM_SPMI_ADC5_GEN3
> + help
> + This enables the auxiliary thermal driver for the ADC5 Gen3 thermal
> + monitoring device. It shows up as a thermal zone with multiple trip points.
> + Thermal client sets threshold temperature for both warm and cool and
> + gets updated when a threshold is reached.
> +
> config QCOM_SPMI_TEMP_ALARM
> tristate "Qualcomm SPMI PMIC Temperature Alarm"
> depends on OF && SPMI && IIO
> diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
> index 0fa2512042e7..828d9e7bc797 100644
> --- a/drivers/thermal/qcom/Makefile
> +++ b/drivers/thermal/qcom/Makefile
> @@ -4,5 +4,6 @@ obj-$(CONFIG_QCOM_TSENS) += qcom_tsens.o
> qcom_tsens-y += tsens.o tsens-v2.o tsens-v1.o tsens-v0_1.o \
> tsens-8960.o
> obj-$(CONFIG_QCOM_SPMI_ADC_TM5) += qcom-spmi-adc-tm5.o
> +obj-$(CONFIG_QCOM_SPMI_ADC_TM5_GEN3) += qcom-spmi-adc-tm5-gen3.o
> obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
> obj-$(CONFIG_QCOM_LMH) += lmh.o
> diff --git a/drivers/thermal/qcom/qcom-spmi-adc-tm5-gen3.c b/drivers/thermal/qcom/qcom-spmi-adc-tm5-gen3.c
> new file mode 100644
> index 000000000000..882355d6606d
> --- /dev/null
> +++ b/drivers/thermal/qcom/qcom-spmi-adc-tm5-gen3.c
> @@ -0,0 +1,512 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/auxiliary_bus.h>
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/cleanup.h>
> +#include <linux/container_of.h>
> +#include <linux/device.h>
> +#include <linux/device/devres.h>
> +#include <linux/dev_printk.h>
> +#include <linux/err.h>
> +#include <linux/iio/adc/qcom-adc5-gen3-common.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/thermal.h>
> +#include <linux/types.h>
> +#include <linux/workqueue.h>
> +#include <linux/unaligned.h>
> +
> +#include "../thermal_hwmon.h"
> +
> +struct adc_tm5_gen3_chip;
> +
> +/**
> + * struct adc_tm5_gen3_channel_props - ADC_TM channel structure
> + * @timer: time period of recurring TM measurement.
> + * @tm_chan_index: TM channel number used (ranging from 1-7).
> + * @sdam_index: SDAM on which this TM channel lies.
> + * @common_props: structure with common ADC channel properties.
> + * @high_thr_en: TM high threshold crossing detection enabled.
> + * @low_thr_en: TM low threshold crossing detection enabled.
> + * @chip: ADC TM device.
> + * @tzd: pointer to thermal device corresponding to TM channel.
> + * @last_temp: last temperature that caused threshold violation,
> + * or a thermal TM channel.
> + * @last_temp_set: indicates if last_temp is stored.
> + */
> +struct adc_tm5_gen3_channel_props {
> + unsigned int timer;
> + unsigned int tm_chan_index;
> + unsigned int sdam_index;
> + struct adc5_channel_common_prop common_props;
> + bool high_thr_en;
> + bool low_thr_en;
> + struct adc_tm5_gen3_chip *chip;
> + struct thermal_zone_device *tzd;
> + int last_temp;
> + bool last_temp_set;
> +};
> +
> +/**
> + * struct adc_tm5_gen3_chip - ADC Thermal Monitoring device structure
> + * @dev_data: Top-level ADC device data.
> + * @chan_props: Array of ADC_TM channel structures.
> + * @nchannels: number of TM channels allocated
> + * @dev: SPMI ADC5 Gen3 device.
> + * @tm_handler_work: handler for TM interrupt for threshold violation.
> + */
> +struct adc_tm5_gen3_chip {
> + struct adc5_device_data *dev_data;
> + struct adc_tm5_gen3_channel_props *chan_props;
> + unsigned int nchannels;
> + struct device *dev;
> + struct work_struct tm_handler_work;
> +};
> +
> +DEFINE_GUARD(adc5_gen3, struct adc_tm5_gen3_chip *, adc5_gen3_mutex_lock(_T->dev),
> + adc5_gen3_mutex_unlock(_T->dev))
> +
> +static int get_sdam_from_irq(struct adc_tm5_gen3_chip *adc_tm5, int irq)
> +{
> + int i;
> +
> + for (i = 0; i < adc_tm5->dev_data->num_sdams; i++) {
> + if (adc_tm5->dev_data->base[i].irq == irq)
> + return i;
> + }
> + return -ENOENT;
> +}
> +
> +static irqreturn_t adctm5_gen3_isr(int irq, void *dev_id)
> +{
> + struct adc_tm5_gen3_chip *adc_tm5 = dev_id;
> + int ret, sdam_num;
> + u8 tm_status[2];
> + u8 status, val;
> +
> + sdam_num = get_sdam_from_irq(adc_tm5, irq);
> + if (sdam_num < 0) {
> + dev_err(adc_tm5->dev, "adc irq %d not associated with an sdam\n",
> + irq);
> + return IRQ_HANDLED;
> + }
> +
> + ret = adc5_gen3_read(adc_tm5->dev_data, sdam_num, ADC5_GEN3_STATUS1,
> + &status, sizeof(status));
> + if (ret) {
> + dev_err(adc_tm5->dev, "adc read status1 failed with %d\n", ret);
> + return IRQ_HANDLED;
> + }
> +
> + if (status & ADC5_GEN3_STATUS1_CONV_FAULT) {
> + dev_err_ratelimited(adc_tm5->dev,
> + "Unexpected conversion fault, status:%#x\n",
> + status);
> + val = ADC5_GEN3_CONV_ERR_CLR_REQ;
> + adc5_gen3_status_clear(adc_tm5->dev_data, sdam_num,
> + ADC5_GEN3_CONV_ERR_CLR, &val, 1);
> + return IRQ_HANDLED;
> + }
> +
> + ret = adc5_gen3_read(adc_tm5->dev_data, sdam_num, ADC5_GEN3_TM_HIGH_STS,
> + tm_status, sizeof(tm_status));
> + if (ret) {
> + dev_err(adc_tm5->dev, "adc read TM status failed with %d\n", ret);
> + return IRQ_HANDLED;
> + }
> +
> + if (tm_status[0] || tm_status[1])
> + schedule_work(&adc_tm5->tm_handler_work);
> +
> + dev_dbg(adc_tm5->dev, "Interrupt status:%#x, high:%#x, low:%#x\n",
> + status, tm_status[0], tm_status[1]);
> +
> + return IRQ_HANDLED;
This ISR routine should be revisited:
- no error message inside
- use a shared interrupt to split what is handled by the ADC and the
TM drivers
- do not return IRQ_HANDLED in case of error (cf. irqreturn.h doc)
- do not use a dedicated workqueue but the threaded mechanism of the irq
> +}
> +
> +static int adc5_gen3_tm_status_check(struct adc_tm5_gen3_chip *adc_tm5,
> + int sdam_index, u8 *tm_status, u8 *buf)
> +{
> + int ret;
> +
> + ret = adc5_gen3_read(adc_tm5->dev_data, sdam_index, ADC5_GEN3_TM_HIGH_STS,
> + tm_status, 2);
> + if (ret) {
> + dev_err(adc_tm5->dev, "adc read TM status failed with %d\n", ret);
> + return ret;
> + }
> +
> + ret = adc5_gen3_status_clear(adc_tm5->dev_data, sdam_index, ADC5_GEN3_TM_HIGH_STS_CLR,
> + tm_status, 2);
> + if (ret) {
> + dev_err(adc_tm5->dev, "adc status clear conv_req failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = adc5_gen3_read(adc_tm5->dev_data, sdam_index, ADC5_GEN3_CH_DATA0(0),
> + buf, 16);
> + if (ret)
> + dev_err(adc_tm5->dev, "adc read data failed with %d\n", ret);
> +
> + return ret;
> +}
> +
> +static void tm_handler_work(struct work_struct *work)
> +{
> + struct adc_tm5_gen3_chip *adc_tm5 = container_of(work, struct adc_tm5_gen3_chip,
> + tm_handler_work);
> + int sdam_index = -1;
> + u8 tm_status[2] = { };
> + u8 buf[16] = { };
> +
> + for (int i = 0; i < adc_tm5->nchannels; i++) {
> + struct adc_tm5_gen3_channel_props *chan_prop = &adc_tm5->chan_props[i];
> + int offset = chan_prop->tm_chan_index;
> + bool upper_set, lower_set;
> + int ret, temp;
> + u16 code;
> +
> + scoped_guard(adc5_gen3, adc_tm5) {
> + if (chan_prop->sdam_index != sdam_index) {
> + sdam_index = chan_prop->sdam_index;
> + ret = adc5_gen3_tm_status_check(adc_tm5, sdam_index,
> + tm_status, buf);
> + if (ret)
> + return;
> + }
> +
> + upper_set = ((tm_status[0] & BIT(offset)) && chan_prop->high_thr_en);
> + lower_set = ((tm_status[1] & BIT(offset)) && chan_prop->low_thr_en);
> + }
> +
> + if (!(upper_set || lower_set))
> + continue;
> +
> + code = get_unaligned_le16(&buf[2 * offset]);
> + dev_dbg(adc_tm5->dev, "ADC_TM threshold code:%#x\n", code);
Please avoid debug traces when possible
> + ret = adc5_gen3_therm_code_to_temp(adc_tm5->dev,
> + &chan_prop->common_props,
> + code, &temp);
> + if (ret) {
> + dev_err(adc_tm5->dev,
> + "Invalid temperature reading, ret = %d, code=%#x\n",
> + ret, code);
And avoid error traces in the runtime path
> + continue;
> + }
> +
> + chan_prop->last_temp = temp;
> + chan_prop->last_temp_set = true;
> + thermal_zone_device_update(chan_prop->tzd, THERMAL_TRIP_VIOLATED);
> + }
> +}
> +
> +static int adc_tm5_gen3_get_temp(struct thermal_zone_device *tz, int *temp)
> +{
> + struct adc_tm5_gen3_channel_props *prop = thermal_zone_device_priv(tz);
> + struct adc_tm5_gen3_chip *adc_tm5;
> +
> + if (!prop || !prop->chip)
> + return -EINVAL;
> +
> + adc_tm5 = prop->chip;
> +
> + if (prop->last_temp_set) {
> + pr_debug("last_temp: %d\n", prop->last_temp);
> + prop->last_temp_set = false;
> + *temp = prop->last_temp;
> + return 0;
> + }
Why do you need to do that?
The temperature should reflect the current situation even if the
reading was triggered by a thermal trip violation.
> +
> + return adc5_gen3_get_scaled_reading(adc_tm5->dev, &prop->common_props,
> + temp);
> +}
> +
> +static int adc_tm5_gen3_disable_channel(struct adc_tm5_gen3_channel_props *prop)
> +{
> + struct adc_tm5_gen3_chip *adc_tm5 = prop->chip;
> + int ret;
> + u8 val;
> +
> + prop->high_thr_en = false;
> + prop->low_thr_en = false;
> +
> + ret = adc5_gen3_poll_wait_hs(adc_tm5->dev_data, prop->sdam_index);
> + if (ret)
> + return ret;
> +
> + val = BIT(prop->tm_chan_index);
> + ret = adc5_gen3_write(adc_tm5->dev_data, prop->sdam_index,
> + ADC5_GEN3_TM_HIGH_STS_CLR, &val, sizeof(val));
> + if (ret)
> + return ret;
> +
> + val = MEAS_INT_DISABLE;
> + ret = adc5_gen3_write(adc_tm5->dev_data, prop->sdam_index,
> + ADC5_GEN3_TIMER_SEL, &val, sizeof(val));
> + if (ret)
> + return ret;
> +
> + /* To indicate there is an actual conversion request */
> + val = ADC5_GEN3_CHAN_CONV_REQ | prop->tm_chan_index;
> + ret = adc5_gen3_write(adc_tm5->dev_data, prop->sdam_index,
> + ADC5_GEN3_PERPH_CH, &val, sizeof(val));
> + if (ret)
> + return ret;
> +
> + val = ADC5_GEN3_CONV_REQ_REQ;
> + return adc5_gen3_write(adc_tm5->dev_data, prop->sdam_index,
> + ADC5_GEN3_CONV_REQ, &val, sizeof(val));
> +}
> +
> +#define ADC_TM5_GEN3_CONFIG_REGS 12
Please define at the top of the file
> +static int adc_tm5_gen3_configure(struct adc_tm5_gen3_channel_props *prop,
> + int low_temp, int high_temp)
> +{
> + struct adc_tm5_gen3_chip *adc_tm5 = prop->chip;
> + u8 buf[ADC_TM5_GEN3_CONFIG_REGS];
> + u8 conv_req;
> + u16 adc_code;
> + int ret;
> +
> + ret = adc5_gen3_poll_wait_hs(adc_tm5->dev_data, prop->sdam_index);
> + if (ret < 0)
> + return ret;
> +
> + ret = adc5_gen3_read(adc_tm5->dev_data, prop->sdam_index,
> + ADC5_GEN3_SID, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> +
> + /* Write SID */
> + buf[0] = FIELD_PREP(ADC5_GEN3_SID_MASK, prop->common_props.sid);
> +
> + /* Select TM channel and indicate there is an actual conversion request */
> + buf[1] = ADC5_GEN3_CHAN_CONV_REQ | prop->tm_chan_index;
> +
> + buf[2] = prop->timer;
> +
> + /* Digital param selection */
> + adc5_gen3_update_dig_param(&prop->common_props, &buf[3]);
> +
> + /* Update fast average sample value */
> + buf[4] &= ~ADC5_GEN3_FAST_AVG_CTL_SAMPLES_MASK;
> + buf[4] |= prop->common_props.avg_samples | ADC5_GEN3_FAST_AVG_CTL_EN;
> +
> + /* Select ADC channel */
> + buf[5] = prop->common_props.channel;
> +
> + /* Select HW settle delay for channel */
> + buf[6] = FIELD_PREP(ADC5_GEN3_HW_SETTLE_DELAY_MASK,
> + prop->common_props.hw_settle_time_us);
> +
> + /* High temperature corresponds to low voltage threshold */
> + prop->low_thr_en = (high_temp != INT_MAX);
> + if (prop->low_thr_en) {
> + adc_code = qcom_adc_tm5_gen2_temp_res_scale(high_temp);
> + put_unaligned_le16(adc_code, &buf[8]);
> + }
> +
> + /* Low temperature corresponds to high voltage threshold */
> + prop->high_thr_en = (low_temp != -INT_MAX);
> + if (prop->high_thr_en) {
> + adc_code = qcom_adc_tm5_gen2_temp_res_scale(low_temp);
> + put_unaligned_le16(adc_code, &buf[10]);
> + }
> +
> + buf[7] = 0;
> + if (prop->high_thr_en)
> + buf[7] |= ADC5_GEN3_HIGH_THR_INT_EN;
> + if (prop->low_thr_en)
> + buf[7] |= ADC5_GEN3_LOW_THR_INT_EN;
> +
> + ret = adc5_gen3_write(adc_tm5->dev_data, prop->sdam_index, ADC5_GEN3_SID,
> + buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> +
> + conv_req = ADC5_GEN3_CONV_REQ_REQ;
> + return adc5_gen3_write(adc_tm5->dev_data, prop->sdam_index,
> + ADC5_GEN3_CONV_REQ, &conv_req, sizeof(conv_req));
> +}
> +
> +static int adc_tm5_gen3_set_trip_temp(struct thermal_zone_device *tz,
> + int low_temp, int high_temp)
> +{
> + struct adc_tm5_gen3_channel_props *prop = thermal_zone_device_priv(tz);
> + struct adc_tm5_gen3_chip *adc_tm5;
> +
> + if (!prop || !prop->chip)
> + return -EINVAL;
> +
> + adc_tm5 = prop->chip;
> +
> + dev_dbg(adc_tm5->dev, "channel:%s, low_temp(mdegC):%d, high_temp(mdegC):%d\n",
> + prop->common_props.label, low_temp, high_temp);
> +
> + guard(adc5_gen3)(adc_tm5);
> + if (high_temp == INT_MAX && low_temp == -INT_MAX)
> + return adc_tm5_gen3_disable_channel(prop);
Why disable the channel instead of returning an errno ?
> + return adc_tm5_gen3_configure(prop, low_temp, high_temp);
> +}
> +
> +static const struct thermal_zone_device_ops adc_tm_ops = {
> + .get_temp = adc_tm5_gen3_get_temp,
> + .set_trips = adc_tm5_gen3_set_trip_temp,
> +};
> +
> +static int adc_tm5_register_tzd(struct adc_tm5_gen3_chip *adc_tm5)
> +{
> + unsigned int i, channel;
> + struct thermal_zone_device *tzd;
> + int ret;
> +
> + for (i = 0; i < adc_tm5->nchannels; i++) {
> + channel = ADC5_GEN3_V_CHAN(adc_tm5->chan_props[i].common_props);
> + tzd = devm_thermal_of_zone_register(adc_tm5->dev, channel,
> + &adc_tm5->chan_props[i],
> + &adc_tm_ops);
> +
> + if (IS_ERR(tzd)) {
> + if (PTR_ERR(tzd) == -ENODEV) {
> + dev_warn(adc_tm5->dev,
> + "thermal sensor on channel %d is not used\n",
> + channel);
> + continue;
> + }
> + return dev_err_probe(adc_tm5->dev, PTR_ERR(tzd),
> + "Error registering TZ zone:%ld for channel:%d\n",
> + PTR_ERR(tzd), channel);
> + }
> + adc_tm5->chan_props[i].tzd = tzd;
> + ret = devm_thermal_add_hwmon_sysfs(adc_tm5->dev, tzd);
> + if (ret)
> + return ret;
> + }
> + return 0;
> +}
> +
> +static void adc5_gen3_clear_work(void *data)
> +{
> + struct adc_tm5_gen3_chip *adc_tm5 = data;
> +
> + cancel_work_sync(&adc_tm5->tm_handler_work);
> +}
> +
> +static void adc5_gen3_disable(void *data)
> +{
> + struct adc_tm5_gen3_chip *adc_tm5 = data;
> + int i;
> +
> + guard(adc5_gen3)(adc_tm5);
> + /* Disable all available TM channels */
> + for (i = 0; i < adc_tm5->nchannels; i++)
> + adc_tm5_gen3_disable_channel(&adc_tm5->chan_props[i]);
> +}
> +
> +static void adctm_event_handler(struct auxiliary_device *adev)
> +{
> + struct adc_tm5_gen3_chip *adc_tm5 = auxiliary_get_drvdata(adev);
> +
> + schedule_work(&adc_tm5->tm_handler_work);
> +}
> +
> +static int adc_tm5_probe(struct auxiliary_device *aux_dev,
> + const struct auxiliary_device_id *id)
> +{
> + struct adc_tm5_gen3_chip *adc_tm5;
> + struct tm5_aux_dev_wrapper *aux_dev_wrapper;
> + struct device *dev = &aux_dev->dev;
> + int i, ret;
> +
> + adc_tm5 = devm_kzalloc(dev, sizeof(*adc_tm5), GFP_KERNEL);
> + if (!adc_tm5)
> + return -ENOMEM;
> +
> + aux_dev_wrapper = container_of(aux_dev, struct tm5_aux_dev_wrapper,
> + aux_dev);
> +
> + adc_tm5->dev = dev;
> + adc_tm5->dev_data = aux_dev_wrapper->dev_data;
> + adc_tm5->nchannels = aux_dev_wrapper->n_tm_channels;
> + adc_tm5->chan_props = devm_kcalloc(dev, aux_dev_wrapper->n_tm_channels,
> + sizeof(*adc_tm5->chan_props), GFP_KERNEL);
> + if (!adc_tm5->chan_props)
> + return -ENOMEM;
> +
> + for (i = 0; i < adc_tm5->nchannels; i++) {
> + adc_tm5->chan_props[i].common_props = aux_dev_wrapper->tm_props[i];
> + adc_tm5->chan_props[i].timer = MEAS_INT_1S;
> + adc_tm5->chan_props[i].sdam_index = (i + 1) / 8;
> + adc_tm5->chan_props[i].tm_chan_index = (i + 1) % 8;
> + adc_tm5->chan_props[i].chip = adc_tm5;
> + }
> +
> + INIT_WORK(&adc_tm5->tm_handler_work, tm_handler_work);
Why is it needed
> + /*
> + * Skipping first SDAM IRQ as it is requested in parent driver.
> + * If there is a TM violation on that IRQ, the parent driver calls
> + * the notifier (adctm_event_handler) exposed from this driver to handle it.
> + */
> + for (i = 1; i < adc_tm5->dev_data->num_sdams; i++) {
> + ret = devm_request_threaded_irq(dev,
> + adc_tm5->dev_data->base[i].irq,
> + NULL, adctm5_gen3_isr, IRQF_ONESHOT,
> + adc_tm5->dev_data->base[i].irq_name,
> + adc_tm5);
The threaded interrupts set the isr in a thread and from the thread
handling the event, there is a work queue scheduled. Why not use the
top and bottom halves of the threaded interrupt ? Hopefully you should
be able to remove the lock.
> + if (ret < 0)
> + return ret;
> + }
> +
> + /*
> + * This drvdata is only used in the function (adctm_event_handler)
> + * called by parent ADC driver in case of TM violation on the first SDAM.
> + */
> + auxiliary_set_drvdata(aux_dev, adc_tm5);
> +
> + adc5_gen3_register_tm_event_notifier(dev, adctm_event_handler);
> +
> + /*
> + * This is to cancel any instances of tm_handler_work scheduled by
> + * TM interrupt, at the time of module removal.
> + */
> +
Remove the extra line
> + ret = devm_add_action(dev, adc5_gen3_clear_work, adc_tm5);
> + if (ret)
> + return ret;
> +
> + ret = adc_tm5_register_tzd(adc_tm5);
> + if (ret)
> + return ret;
> +
> + /* This is to disable all ADC_TM channels in case of probe failure. */
> +
Remove the extra line
> + return devm_add_action(dev, adc5_gen3_disable, adc_tm5);
> +}
> +
> +static const struct auxiliary_device_id adctm5_auxiliary_id_table[] = {
> + { .name = "qcom_spmi_adc5_gen3.adc5_tm_gen3", },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(auxiliary, adctm5_auxiliary_id_table);
> +
> +static struct auxiliary_driver adctm5gen3_auxiliary_driver = {
> + .id_table = adctm5_auxiliary_id_table,
> + .probe = adc_tm5_probe,
> +};
> +
> +module_auxiliary_driver(adctm5gen3_auxiliary_driver);
> +
> +MODULE_DESCRIPTION("SPMI PMIC Thermal Monitor ADC driver");
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS("QCOM_SPMI_ADC5_GEN3");
> --
> 2.25.1
>
--
^ permalink raw reply
* Re: [PATCH v6 09/21] dt-bindings: display: renesas,rzg2l-du: Refuse port@1 for RZ/G2UL
From: Krzysztof Kozlowski @ 2026-04-09 6:21 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, laurent.pinchart, linux-renesas-soc,
biju.das.jz, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Magnus Damm, Laurent Pinchart, Tomi Valkeinen, dri-devel,
devicetree, linux-kernel, linux-clk, stable
In-Reply-To: <8a3dd4df30a6d950e5f38d46f4d9f396da67aa71.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:54PM +0200, Tommaso Merciai wrote:
> The RZ/G2UL DU supports only a single port@0 DPI. Explicitly refuse
> port@1 in the ports node.
>
> Fixes: 2ef7cb1cea7d ("dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings")
> Cc: stable@vger.kernel.org
Please describe bug being fixed here in such case.
Commit msg so far explains none.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 23/27] clk: mediatek: Add MT8196 disp-ao clock support
From: Jason-JH Lin (林睿祥) @ 2026-04-09 6:30 UTC (permalink / raw)
To: aford173@gmail.com
Cc: Guangjie Song (宋光杰), robh@kernel.org,
kernel@collabora.com, Sirius Wang (王皓昱),
Nancy Lin (林欣螢), AngeloGioacchino Del Regno,
linux-mediatek@lists.infradead.org, conor+dt@kernel.org,
mturquette@baylibre.com, richardcochran@gmail.com,
Project_Global_Chrome_Upstream_Group, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, krzk+dt@kernel.org, Laura Nao,
Nicolas Prado, p.zabel@pengutronix.de,
Singo Chang (張興國),
Paul-pl Chen (陳柏霖), wenst@chromium.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-clk@vger.kernel.org, matthias.bgg@gmail.com,
sboyd@kernel.org
In-Reply-To: <CAHCN7x+K25H-QWLDA6SoGSzxv9koO0wFOrjfWNePc+0AfjCVZg@mail.gmail.com>
>
[snip]
> > > > > +static const struct of_device_id
> > > > > of_match_clk_mt8196_vdisp_ao[]
> > > > > = {
> > > > > + { .compatible = "mediatek,mt8196-vdisp-ao", .data =
> > > > > &mm_v_mcd },
> > > >
> > > > Hi Laura,
> > > >
> > > > We are going to send mtk-mmsys driver for MT8196 recently, but
> > > > we
> > > > found
> > > > the compatible name is used here.
> > > >
> > > > As your commit message, vdisp-ao is integrated with the mtk-
> > > > mmsys
> > > > driver, which registers the vdisp-ao clock driver via
> > > > platform_device_register_data().
> > > >
> > > > Shouldn't this compatible name belong to mmsys driver for
> > > > MT8196?
> > > >
> > >
> > > That's right, my fault for missing that! Thanks for the heads up.
> > >
> > > I'm aware Angelo is currently restructuring mediatek-drm
> > > (including
> > > mmsys and mutex), and that might affect the way vdisp-ao is
> > > loaded
> > > too.
> > > So I'm not sure whether it makes sense to send a patch to fix
> > > this
> > > right away.
> >
> > OK, we'll try to contact Angelo from other places.
> > Thanks for your confirmation!
> >
>
>
> If anyone wants me to test anything, I have a Chromebook with the
> mt8196 that I can test code, so feel free to CC me on anything that
> you want tested. I'd love to see this stuff pushed upstream.
>
> thanks
>
> adam
Hi Adam,
However, we still need some more time to discuss and refactor this.
We'll send the new patch if necessary.
Thank you for your help!
Regards,
Jason-JH Lin
> >
> > Regards,
> > Jason-JH.Lin
> >
> > >
> > > Best,
> > >
> > > Laura
> > >
> >
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Peng Fan @ 2026-04-09 6:33 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Dario Binacchi, Markus Niebel, Maud Spierings,
Alexander Stein, Ernest Van Hoecke, Josua Mayer,
Francesco Dolcini, Primoz Fiser
In-Reply-To: <1ed7e2100e3feb74c9f0006d5b88e1bba1ad4339.1775669847.git.stefano.r@variscite.com>
On Wed, Apr 08, 2026 at 07:39:45PM +0200, Stefano Radaelli wrote:
>From: Stefano Radaelli <stefano.r@variscite.com>
>
>Add device tree support for the Variscite VAR-SOM-MX91 system on module.
>This SOM is designed to be used with various carrier boards.
>
>The module includes:
>- NXP i.MX91 MPU processor
>- Up to 2GB 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-9/i-mx-91/var-som-mx91/
>Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite VAR-SOM-MX91 Boards
From: Krzysztof Kozlowski @ 2026-04-09 7:16 UTC (permalink / raw)
To: Stefano Radaelli, 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, Dario Binacchi, Markus Niebel,
Maud Spierings, Alexander Stein, Ernest Van Hoecke, Josua Mayer,
Francesco Dolcini, Primoz Fiser
In-Reply-To: <86635091cd5db0ecb7f07c5ad9d6f735ec349485.1775669847.git.stefano.r@variscite.com>
On 08/04/2026 19:39, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add DT compatible strings for Variscite VAR-SOM-MX91 SoM and Symphony
> development carrier Board.
>
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 5/9] riscv: dts: spacemit: k1: add SD card controller and pinctrl support
From: Troy Mitchell @ 2026-04-09 7:17 UTC (permalink / raw)
To: Iker Pedrosa, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Adrian Hunter, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-5-b5b8a1b2bfc8@gmail.com>
On Tue Apr 7, 2026 at 4:25 PM CST, Iker Pedrosa wrote:
> Add SD card controller infrastructure for SpacemiT K1 SoC with complete
> pinctrl support for both standard and UHS modes.
>
> - Add sdhci0 controller definition with clocks, resets and interrupts
> - Add mmc1_cfg pinctrl for 3.3V standard SD operation
> - Add mmc1_uhs_cfg pinctrl for 1.8V UHS high-speed operation
> - Configure appropriate drive strength and power-source properties
>
> This provides complete SD card infrastructure that K1-based boards can
> enable.
>
> Tested-by: Anand Moon <linux.amoon@gmail.com>
> Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev>
^ permalink raw reply
* [PATCH 0/2] rtc: nct3018y: add support for control register initialization
From: David Wang @ 2026-04-09 7:21 UTC (permalink / raw)
To: a.zummo, alexandre.belloni, robh, krzk+dt, conor+dt
Cc: andrew, avi.fishman, tmaimon77, tali.perry1, venture, yuenn,
benjaminfair, ctcchien, mimi05633, openbmc, linux-rtc, devicetree,
linux-kernel, davidwang, David Wang
This series adds support for an optional Device Tree property
"nuvoton,ctrl-reg-val" to initialize the RTC control register (0x0A).
This provides flexibility for different platforms (especially in
server environments) to configure behaviors such as 24h mode and
write ownership without driver source modifications.
David Wang (2):
dt-bindings: rtc: nct3018y: add nuvoton,ctrl-reg-val property
rtc: nct3018y: add optional control register initialization
.../devicetree/bindings/rtc/nuvoton,nct3018y.yaml | 5 +++++
drivers/rtc/rtc-nct3018y.c | 9 +++++++++
2 files changed, 14 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH 1/2] dt-bindings: rtc: nct3018y: add nuvoton,ctrl-reg-val property
From: David Wang @ 2026-04-09 7:21 UTC (permalink / raw)
To: a.zummo, alexandre.belloni, robh, krzk+dt, conor+dt
Cc: andrew, avi.fishman, tmaimon77, tali.perry1, venture, yuenn,
benjaminfair, ctcchien, mimi05633, openbmc, linux-rtc, devicetree,
linux-kernel, davidwang, David Wang
In-Reply-To: <cover.1775717959.git.tomato1220@gmail.com>
Add "nuvoton,ctrl-reg-val" vendor property to allow optional
initialization of the RTC control register (0x0A).
This allows platform-specific configurations like 24h mode and
write ownership to be defined via Device Tree.
Signed-off-by: David Wang <tomato1220@gmail.com>
---
Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
index 4f9b5604acd9..0984dfb77170 100644
--- a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
+++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
@@ -24,6 +24,10 @@ properties:
reset-source: true
+ nuvoton,ctrl-reg-val:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Initial value for the control register (0x0A).
+
required:
- compatible
- reg
@@ -39,6 +43,7 @@ examples:
rtc@6f {
compatible = "nuvoton,nct3018y";
reg = <0x6f>;
+ nuvoton,ctrl-reg-val = <0x21>;
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] rtc: nct3018y: add optional control register initialization
From: David Wang @ 2026-04-09 7:21 UTC (permalink / raw)
To: a.zummo, alexandre.belloni, robh, krzk+dt, conor+dt
Cc: andrew, avi.fishman, tmaimon77, tali.perry1, venture, yuenn,
benjaminfair, ctcchien, mimi05633, openbmc, linux-rtc, devicetree,
linux-kernel, davidwang, David Wang
In-Reply-To: <cover.1775717959.git.tomato1220@gmail.com>
Support the "nuvoton,ctrl-reg-val" Device Tree property to initialize
the RTC control register (0x0A) during the probe phase.
This provides flexibility for different platforms to override default
hardware settings.
Signed-off-by: David Wang <tomato1220@gmail.com>
---
drivers/rtc/rtc-nct3018y.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/rtc/rtc-nct3018y.c b/drivers/rtc/rtc-nct3018y.c
index cd4b1db902e9..4bc47b4ac935 100644
--- a/drivers/rtc/rtc-nct3018y.c
+++ b/drivers/rtc/rtc-nct3018y.c
@@ -534,6 +534,15 @@ static int nct3018y_probe(struct i2c_client *client)
}
}
+ if (!of_property_read_u32(client->dev.of_node, "nuvoton,ctrl-reg-val", &flags)) {
+
+ err = i2c_smbus_write_byte_data(client, NCT3018Y_REG_CTRL, (u8)flags);
+ if (err < 0) {
+ dev_dbg(&client->dev, "Unable to write NCT3018Y_REG_CTRL.\n");
+ return err;
+ }
+ }
+
flags = 0;
err = i2c_smbus_write_byte_data(client, NCT3018Y_REG_ST, flags);
if (err < 0) {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3] dt-bindings: gpio: cavium,thunder-8890: Remove DT binding
From: Krzysztof Kozlowski @ 2026-04-09 7:21 UTC (permalink / raw)
To: Shi Hao
Cc: robh, brgl, krzk+dt, conor+dt, rric, linux-gpio, devicetree,
linux-kernel
In-Reply-To: <20260408093313.17025-1-i.shihao.999@gmail.com>
On Wed, Apr 08, 2026 at 03:03:13PM +0530, Shi Hao wrote:
> Remove the cavium,thunder-8890 GPIO binding as there are no active
> use cases. A previous attempt was made to convert the binding to DT
> schema, but since the binding is unused, remove it instead.
Last sentence is not relevant to Git log/history. Instead useful would
be to tell what made you think that binding is not used, because it is
not obvious - the in kernel driver does not bind via compatible, but PCI.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: rtc: nct3018y: add nuvoton,ctrl-reg-val property
From: Krzysztof Kozlowski @ 2026-04-09 7:23 UTC (permalink / raw)
To: David Wang, a.zummo, alexandre.belloni, robh, krzk+dt, conor+dt
Cc: andrew, avi.fishman, tmaimon77, tali.perry1, venture, yuenn,
benjaminfair, ctcchien, mimi05633, openbmc, linux-rtc, devicetree,
linux-kernel, davidwang
In-Reply-To: <ba0845c590eda42a28b3799a6f40294ba74a726e.1775717959.git.tomato1220@gmail.com>
On 09/04/2026 09:21, David Wang wrote:
> Add "nuvoton,ctrl-reg-val" vendor property to allow optional
> initialization of the RTC control register (0x0A).
>
> This allows platform-specific configurations like 24h mode and
> write ownership to be defined via Device Tree.
>
> Signed-off-by: David Wang <tomato1220@gmail.com>
> ---
> Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> index 4f9b5604acd9..0984dfb77170 100644
> --- a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> +++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> @@ -24,6 +24,10 @@ properties:
>
> reset-source: true
>
> + nuvoton,ctrl-reg-val:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Initial value for the control register (0x0A).
24h mode is not a property of a board. I don't know what "write
ownership" is.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: i3c: Add AST2600 I3C global registers
From: Krzysztof Kozlowski @ 2026-04-09 7:28 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak
In-Reply-To: <7f55458097ef651b4fc46650254afd3fa7b87348.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:35PM +0200, Dawid Glazik wrote:
> Introduce the device-tree bindings for I3C global registers found on
> AST2600 SoCs.
>
> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
> ---
> I wasn't sure if I should add newline at the end of the
> file or not so I took
> https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/i3c
> as an example.
Answer is: you cannot have patch warnings.
Documentation/devicetree/bindings/i3c does not have patch warning, does
it?
> ---
> .../i3c/aspeed,ast2600-i3c-global.yaml | 55 +++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c-global.yaml
>
> diff --git a/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c-global.yaml b/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c-global.yaml
> new file mode 100644
> index 000000000000..edecc18796a9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c-global.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i3c/aspeed,ast2600-i3c-global.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASPEED AST2600 I3C Global Registers
> +
> +description: |
> + The AST2600 SoC provides a shared I3C global register block used by all
> + I3C controller instances. This block contains per-instance global
Why are you adding syscon to I3C controllers? Only I3C controllers go
to i3c directory.
syscons go soc.
> + configuration fields, including controller instance ID and SDA pull-up
> + configuration.
> + Each I3C controller references this syscon node through the
> + aspeed,global-regs property.
> +
> +maintainers:
> + - Dawid Glazik <dawid.glazik@linux.intel.com>
> +
> +allOf:
> + - $ref: /schemas/mfd/syscon-common.yaml#
> +
> +properties:
> + compatible:
> + items:
> + - const: aspeed,ast2600-i3c-global
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
I do not see any differences against syscon.yaml binding. Why do you
need separate file? Look first how other platforms do it.
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
Drop entire node, not needed.
> +
> + i3c-global@0 {
> + compatible = "aspeed,ast2600-i3c-global", "syscon";
> + reg = <0x0 0x1000>;
> + resets = <&syscon ASPEED_RESET_I3C_DMA>;
> + };
> + };
> +...
> \ No newline at end of file
Patch warning.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: aspeed-g6: Add nodes for i3c controllers
From: Krzysztof Kozlowski @ 2026-04-09 7:30 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak, Jeremy Kerr
In-Reply-To: <51c4bdc02b45f67a0e32610a228091e137c135a6.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:34PM +0200, Dawid Glazik wrote:
> Add the i3c controller devices to the ast2600 g6 common dts. We add all
> 6 busses to the common g6 definition, but leave disabled through the
> status property, to be enabled per-platform.
>
> Originally-by: Jeremy Kerr <jk@codeconstruct.com.au>
Don't invent tags. This is not used outside of TIP.
> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
> ---
> v3:
> - add i3c aliases
> - rebase on top of latest tree and solve conflicts
> - as agreed with Jeremy off-list, he said I can take authorship of this going forward
> v2:
> - use inline bus representation, without the i3c: label
> ---
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 97 +++++++++++++++++++++++++
> 1 file changed, 97 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index f5641128614f..f986fcbed604 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -29,6 +29,12 @@ aliases {
> i2c13 = &i2c13;
> i2c14 = &i2c14;
> i2c15 = &i2c15;
> + i3c0 = &i3c0;
> + i3c1 = &i3c1;
> + i3c2 = &i3c2;
> + i3c3 = &i3c3;
> + i3c4 = &i3c4;
> + i3c5 = &i3c5;
Bus aliases are not properties of SoC DTSI.
> serial0 = &uart1;
> serial1 = &uart2;
> serial2 = &uart3;
> @@ -1066,6 +1072,97 @@ i2c15: i2c@800 {
> };
> };
>
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
> +
> + i3c_global: i3c-global@0 {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: i3c: Add AST2600 I3C global registers
From: Krzysztof Kozlowski @ 2026-04-09 7:30 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak
In-Reply-To: <20260409-beneficial-sociable-tamarin-dbcaeb@quoll>
On 09/04/2026 09:28, Krzysztof Kozlowski wrote:
> On Wed, Apr 08, 2026 at 10:34:35PM +0200, Dawid Glazik wrote:
>> Introduce the device-tree bindings for I3C global registers found on
>> AST2600 SoCs.
>>
>> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
>> ---
>> I wasn't sure if I should add newline at the end of the
>> file or not so I took
>> https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/i3c
>> as an example.
>
> Answer is: you cannot have patch warnings.
>
> Documentation/devicetree/bindings/i3c does not have patch warning, does
> it?
And if you tested this code with standard tools, you would see that...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: aspeed-g6: Add nodes for i3c controllers
From: Krzysztof Kozlowski @ 2026-04-09 7:31 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak, Jeremy Kerr
In-Reply-To: <51c4bdc02b45f67a0e32610a228091e137c135a6.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:34PM +0200, Dawid Glazik wrote:
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
> +
> + i3c_global: i3c-global@0 {
> + compatible = "aspeed,ast2600-i3c-global", "syscon";
Also undocumented ABI. Apply this patch and run checkpatch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 19/19] gpio: add GPIO controller found on Waveshare DSI TOUCH panels
From: Bartosz Golaszewski @ 2026-04-09 7:41 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: dri-devel, devicetree, linux-kernel, linux-gpio, Neil Armstrong,
Jessica Zhang, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij
In-Reply-To: <l6pezliurpgv2mopw2xl4gfgpki6r3v6ufpsaavj774qnxgept@h3jxxpco23oa>
On Thu, Apr 9, 2026 at 3:26 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> >
> > This driver looks like it could be easily converted to use gpio-regmap and
> > become much shorter in the process. Could you please take a look at
> > linux/gpio/regmap.h?
>
> I took a glance. It is a nice wrapper, but I think being able to call
> waveshare_gpio_set() internally without extra troubles overweights the
> bonuses of the wrapper. Also, I'd agree if there were extra complexity
> here (e.g. the stride or the in/out handling), but having just the out
> GPIOs doesn't seem to warrant it.
>
> An alternative would be to split away the backlight into a separate
> pwm-backlight device. Then having waveshare_gpio_set() isn't that
> important and thus I could switch to GPIO_REGMAP. But then... We don't
> have real control over the PWM. We are really programming some values,
> with the actual PWM duty cycle calculations being handled internally.
>
> With all that in mind, unless you really insist, I'd prefer to leave
> this part the driver as is.
>
Ok, with the other issues fixed it's good to go then.
Bart
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Krzysztof Kozlowski @ 2026-04-09 7:43 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, tychang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai
In-Reply-To: <20260408025243.1155482-3-eleanor.lin@realtek.com>
On Wed, Apr 08, 2026 at 10:52:41AM +0800, Yu-Chun Lin wrote:
> +maintainers:
> + - Tzuyi Chang <tychang@realtek.com>
> +
> +description: |
> + GPIO controller for the Realtek RTD1625 SoC, featuring a per-pin register
> + architecture that differs significantly from earlier RTD series controllers.
> + Each GPIO has dedicated registers for configuration (direction, input/output
> + values, debounce), and interrupt control supporting edge and level detection
> + modes.
> +
> +properties:
> + compatible:
> + enum:
> + - realtek,rtd1625-iso-gpio
> + - realtek,rtd1625-isom-gpio
> +
> + reg:
> + maxItems: 1
> + description: |
> + Memory region containing both interrupt control and GPIO
> + configuration registers in a contiguous address space.
> +
> + For realtek,rtd1625-iso-gpio:
> + - Base + 0x0 ~ 0xff: Interrupt control registers
> + - Base + 0x100 ~ 0x397: GPIO configuration registers
> +
> + For realtek,rtd1625-isom-gpio:
> + - Base + 0x0 ~ 0x1f: Interrupt control registers
> + - Base + 0x20 ~ 0x2f: GPIO configuration registers
Drop description, you are duplicating here DTS. Bindings do not need to
serve as reference manual for the device.
However when you state them like this and give them names, I have the
same concerns as last time - please consult your datasheet whether this
is really one address space.
With description dropped:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: rtc: nct3018y: add nuvoton,ctrl-reg-val property
From: David Wang @ 2026-04-09 7:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: a.zummo, alexandre.belloni, robh, krzk+dt, conor+dt, andrew,
avi.fishman, tmaimon77, tali.perry1, venture, yuenn, benjaminfair,
ctcchien, mimi05633, openbmc, linux-rtc, devicetree, linux-kernel,
davidwang
In-Reply-To: <a1e24b69-b90a-47d7-b952-bca45fcc6281@kernel.org>
On Apr 9, 2026, at 15:23, Krzysztof Kozlowski wrote:
>
> On 09/04/2026 09:21, David Wang wrote:
> > Add "nuvoton,ctrl-reg-val" vendor property to allow optional
> > initialization of the RTC control register (0x0A).
> >
> > This allows platform-specific configurations like 24h mode and
> > write ownership to be defined via Device Tree.
> >
> > Signed-off-by: David Wang <tomato1220@gmail.com>
> > ---
> > Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > index 4f9b5604acd9..0984dfb77170 100644
> > --- a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > @@ -24,6 +24,10 @@ properties:
> >
> > reset-source: true
> >
> > + nuvoton,ctrl-reg-val:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: Initial value for the control register (0x0A).
>
> 24h mode is not a property of a board. I don't know what "write
> ownership" is.
>
> Best regards,
> Krzysztof
Hi Krzysztof,
Thanks for your feedback. Let me clarify these two points based on the
NCT3018Y datasheet:
1. Regarding "write ownership": The NCT3018Y features two I2C
interfaces (Primary and Secondary). The TWO (Time Write Ownership) bit
in the control register determines which interface has the authority
to write to the RTC. We need to ensure the interface connected to our
SoC is granted this ownership during probe—especially for factory-new
chips—to ensure the RTC is writable.
2. Regarding "24h mode": This bit determines the internal data format
in which time is stored within the RTC hardware. Setting this ensures
the hardware's internal storage layout matches the driver's
expectation from the start.
Best regards,
David Wang
^ permalink raw reply
* [PATCH] dt-bindings: mmc: st,sdhci: convert to DT schema
From: Charan Pedumuru @ 2026-04-09 7:43 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin
Cc: linux-mmc, devicetree, linux-kernel, Charan Pedumuru
Convert STMicroelectronics sdhci-st MMC/SD controller binding to DT schema.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 -------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 122 +++++++++++++++++++++
2 files changed, 122 insertions(+), 110 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
deleted file mode 100644
index ccf82b4ee838..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-* STMicroelectronics sdhci-st MMC/SD controller
-
-This file documents the differences between the core properties in
-Documentation/devicetree/bindings/mmc/mmc.txt and the properties
-used by the sdhci-st driver.
-
-Required properties:
-- compatible: Must be "st,sdhci" and it can be compatible to "st,sdhci-stih407"
- to set the internal glue logic used for configuring the MMC
- subsystem (mmcss) inside the FlashSS (available in STiH407 SoC
- family).
-
-- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory)
- See: Documentation/devicetree/bindings/resource-names.txt
-- clocks: Phandle to the clock.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-- interrupts: One mmc interrupt should be described here.
-- interrupt-names: Should be "mmcirq".
-
-- pinctrl-names: A pinctrl state names "default" must be defined.
-- pinctrl-0: Phandle referencing pin configuration of the sd/emmc controller.
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-- reg: This must provide the host controller base address and it can also
- contain the FlashSS Top register for TX/RX delay used by the driver
- to configure DLL inside the flashSS, if so reg-names must also be
- specified.
-
-Optional properties:
-- reg-names: Should be "mmc" and "top-mmc-delay". "top-mmc-delay" is optional
- for eMMC on stih407 family silicon to configure DLL inside FlashSS.
-
-- non-removable: Non-removable slot. Also used for configuring mmcss in STiH407 SoC
- family.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- bus-width: Number of data lines.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- max-frequency: Can be 200MHz, 100MHz or 50MHz (default) and used for
- configuring the CCONFIG3 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- resets: Phandle and reset specifier pair to softreset line of HC IP.
- See: Documentation/devicetree/bindings/reset/reset.txt
-
-- vqmmc-supply: Phandle to the regulator dt node, mentioned as the vcc/vdd
- supply in eMMC/SD specs.
-
-- sd-uhs-sdr50: To enable the SDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-sdr104: To enable the SDR104 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-ddr50: To enable the DDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-Example:
-
-/* Example stih416e eMMC configuration */
-
-mmc0: sdhci@fe81e000 {
- compatible = "st,sdhci";
- reg = <0xfe81e000 0x1000>;
- interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_a1_ls 1>;
- bus-width = <8>
-
-/* Example SD stih407 family configuration */
-
-mmc1: sdhci@9080000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09080000 0x7ff>;
- reg-names = "mmc";
- interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sd1>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_1>;
- resets = <&softreset STIH407_MMC1_SOFTRESET>;
- bus-width = <4>;
-};
-
-/* Example eMMC stih407 family configuration */
-
-mmc0: sdhci@9060000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
- reg-names = "mmc", "top-mmc-delay";
- interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_0>;
- vqmmc-supply = <&vmmc_reg>;
- max-frequency = <200000000>;
- bus-width = <8>;
- non-removable;
- sd-uhs-sdr50;
- sd-uhs-sdr104;
- sd-uhs-ddr50;
-};
diff --git a/Documentation/devicetree/bindings/mmc/st,sdhci.yaml b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
new file mode 100644
index 000000000000..22060fe6e364
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/st,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics SDHCI-ST MMC/SD Controller
+
+description:
+ The STMicroelectronics SDHCI-ST MMC/SD host controller, which is
+ compliant with the SD Host Controller Interface (SDHCI) specification and
+ is used to interface with MMC, SD and SDIO cards. The ST SDHCI controller
+ extends the standard SDHCI capabilities with platform-specific
+ configurations such as additional register regions,clock inputs, and delay
+ control mechanisms required for signal timing adjustments which are
+ necessary to support high-speed modes and ensure reliable data transfer
+ across different ST SoCs.
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - const: st,sdhci
+ - items:
+ - const: st,sdhci-stih407
+ - const: st,sdhci
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - mmc
+ - top-mmc-delay
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - mmc
+ - icn
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: mmcirq
+
+ pinctrl-names:
+ const: default
+
+ resets:
+ maxItems: 1
+ description: Phandle to reset line of host controller.
+
+ vqmmc-supply:
+ description: Regulator supplying I/O voltage (Vcc/Vdd for SD/eMMC).
+
+ non-removable:
+ type: boolean
+ description:
+ Indicates a non-removable device (e.g., eMMC). Also used for mmcss config.
+
+ bus-width:
+ description: Number of data lines.
+ enum: [1, 4, 8]
+
+ max-frequency:
+ enum: [50000000, 100000000, 200000000]
+ default: 50000000
+ description:
+ Maximum bus frequency. Used to configure CCONFIG3 in mmcss.
+
+ sd-uhs-sdr50:
+ type: boolean
+
+ sd-uhs-sdr104:
+ type: boolean
+
+ sd-uhs-ddr50:
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - pinctrl-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ sdhci@9060000 {
+ compatible = "st,sdhci-stih407", "st,sdhci";
+ reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
+ reg-names = "mmc", "top-mmc-delay";
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mmcirq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0>;
+ clock-names = "mmc", "icn";
+ clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
+ <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
+ bus-width = <8>;
+ };
+...
---
base-commit: e77a5a5cfe43b4c25bd44a3818e487033287517f
change-id: 20260327-st-mmc-c906ad95ff83
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ permalink raw reply related
* Re: [PATCH 0/6] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: Paolo Abeni @ 2026-04-09 7:46 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
On 4/3/26 6:43 PM, Luca Weiss wrote:
> First, two fixes that unbreak IPA v5.0+, which can be applied
> independently.
>
> Then add support for IPA v5.2 which can be found in the Milos SoC. And
> finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
> starts working.
You should have probably split the series in 2, with patches 1 & 2
targeting net and the following ones targeting net-next. It looks like
patch 5 needs some adjustment. I'm applying the first 2.
/P
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: lemans: Move PCIe devices into soc node
From: Shawn Guo @ 2026-04-09 7:48 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Krzysztof Kozlowski, Manivannan Sadhasivam,
Mrinmay Sarkar, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260331090147.18522-1-shengchao.guo@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 05:01:47PM +0800, Shawn Guo wrote:
> These PCIe devices with MMIO address should be inside soc node rather
> than outside.
>
> Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes")
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
As this is a prerequisite of my Lemans DTS split series, I'm including
it into the series.
Shawn
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Stefano Radaelli @ 2026-04-09 7:48 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Dario Binacchi, Markus Niebel, Maud Spierings, Alexander Stein,
Ernest Van Hoecke, Josua Mayer, Francesco Dolcini, Primoz Fiser
In-Reply-To: <adcdWdTcVR2T2F5c@lizhi-Precision-Tower-5810>
Hi Frank!
On Wed, Apr 08, 2026 at 11:30:33PM -0400, Frank Li wrote:
>
> what' difference with imx93-var-som ? Can you reuse it?
>
The imx91-var-som is conceptually similar to imx93-var-som, and I used
it as a reference while preparing this DTS.
However, it cannot be directly reused as there are several hardware
differences between the two platforms, including SoC integration and
peripheral configuration (e.g. pinctrl, and available IPs).
So a separate description is required for imx91.
Best regards,
Stefano
^ 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