* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg @ 2026-06-24 14:37 UTC (permalink / raw)
To: Dmitry Torokhov, Krzysztof Kozlowski, Konrad Dybcio
Cc: Rob Herring, Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm, phone-devel,
Krzysztof Kozlowski
In-Reply-To: <ajtaUb4YmyZTDLmQ@google.com>
On 24/06/2026 06:28, Dmitry Torokhov wrote:
> Hi David,
>
> On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
>> On 28/05/2026 00:13, David Heidelberg wrote:
>>> On 27/05/2026 23:56, Dmitry Torokhov wrote:
>>>> Hi David,
>>>>
>>>> On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>
>>>>> We know the driver is reporting s3706b, introduce the compatible so we
>>>>> can more easily introduce quirks for weird touchscreen replacements in
>>>>> followup series.
>>>>>
>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>> b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>> index 6b7378cf4d493..148164d456a5a 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>> @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
>>>>> };
>>>>> };
>>>>> &i2c12 {
>>>>> status = "okay";
>>>>> clock-frequency = <400000>;
>>>>> synaptics-rmi4-i2c@20 {
>>>>> - compatible = "syna,rmi4-i2c";
>>>>> + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
>>>>
>>>> So I believe we established that this device (s3706b) does not in fact
>>>> implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
>>>> fallback? Shouldn't it be just "syna,rmi4-s3706b"?
>>>
>>> The vendor supplies s3706b which does implement the RMI4 properly.
>>>
>>> The 3rd party replacement impersonating original parts may not implement
>>> it properly, but I don't address this issue in this initial submission.
>>>
>>> With this compatible we know which original part is used by the vendor
>>> and installed in the phones, so later we can deduct specific sequences
>>> for the replacement aftermarket parts to keep phone touchscreen working
>>> same as they do on Android without affecting other devices.
>>
>> Hello Dmitry.
>>
>> May I ask what is currently preventing this series from moving forward?
>>
>> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
>> and am now on the 9th iteration (this patchset). At this point, the series
>> has been under discussion for well over a year, with relatively little
>> feedback and increasingly long gaps between review rounds.
>>
>> The current approach is based on the guidance I have received so far,
>> including suggestions from the device-tree maintainers. When concerns were
>> raised, I tried to address them and rework the series accordingly.
>>
>> What I am struggling with is understanding what specific issue still needs
>> to be resolved before these patches can be accepted. If there are remaining
>> requirements, objections to the approach, or technical concerns that I have
>> not addressed, I would appreciate having them stated explicitly so I can
>> work on them.
>>
>> I also split out the straightforward, self-contained changes in the hope
>> that at least those could progress independently while I continued working
>> on any follow-up requirements. However, even those patches do not appear to
>> be moving forward.
>>
>> Could you please clarify what outcome you would like to see from this
>> series, and what concrete changes would be required to get it accepted?
>
> I am still confused about how you want to differentiate between the full
> RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
> mentioned, implements RMI4 protocol properly, so we do not need to
> actually have it documented neither in binding nor in DTS.
--- part 1 ---
This series addresses identification within device-tree. It's normal recommended
practice.
If we know, the device ships specific, but **compliant** variant, we just put it
as compatible = "more-specific", "less-specific"; in this case
"syna,rmi4-s3706b", "syna,rmi4-i2c"
This approach is used everywhere. This has nothing to do with after-market parts.
--- part 2 (irrelevant for this series) ---
>
> The issue you have with after-market parts that are not compliant and we
> need to figure out how to deal with them. Inside the driver I
As was suggested by device-tree folks, this is the first step, there isn't
better one available. If there is, please suggest one, and I'll apply it.
> essentially need a"incomplete protocol" flag that we can use to
> implement additional checks or skip known to be not implemented
> functions/queries. In DT we could introduce something like
> "oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
> and neither one should be a fallback for the other.
>
> This of course needs buy-in from DT maintainers.
As you can see, this still holds Acked-by and Reviewed-by from the relevant
people - Krzysztof and Konrad.
>
> Does this make sense?
For the scope we're discussing it doesn't seems so.
This discussion should be associated with the last revision of the full series I
sent 3 months ago. We're in very unflattering state, where:
2018 - these aftermarket touchscreen worked on Android well enough for people
to have working touch (let's say with slightly worse experience then the original).
2026 in the mainline, we cannot even more forward and report to user-space
there is aftermarket non-compliant piece of hardware installed.
Actionable steps I suggest after this series lands:
1. don't do any changes, but since we know what 3rd party touchscreen do
incorrectly deviating from the standard, REPORT it to the userspace, so USER
know, their device (phone/tablet) doesn't have original part.
2. then figure out, IF we can reasonably well workaround it and HOW to do it
These two steps present some progress which could be discussed and could lead us
somewhere, what do you think?
David
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v5 12/16] media: iris: implement support for the Agatti platform
From: Vikash Garodia @ 2026-06-24 14:30 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-12-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Port support for the AR50Lt video codec core (present for example on the
> Agatti platform) to the Iris driver. Unlike more recent cores this
> generation doesn't have the PIPE property (as it always has only one
> pipe). Also, unlike newer platforms, buffer sizes are requested from the
> firmware instead of being calculated by the driver.
>
> Co-developed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/Makefile | 1 +
> drivers/media/platform/qcom/iris/iris_hfi_gen1.c | 227 +++++++++++++++++++++
> .../platform/qcom/iris/iris_platform_common.h | 6 +
> .../platform/qcom/iris/iris_platform_vpu_ar50lt.c | 110 ++++++++++
> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
> drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 13 ++
> drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 1 +
> 7 files changed, 362 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> index f1b204b95694..bbd1f724963e 100644
> --- a/drivers/media/platform/qcom/iris/Makefile
> +++ b/drivers/media/platform/qcom/iris/Makefile
> @@ -14,6 +14,7 @@ qcom-iris-objs += iris_buffer.o \
> iris_hfi_queue.o \
> iris_platform_vpu2.o \
> iris_platform_vpu3x.o \
> + iris_platform_vpu_ar50lt.o \
> iris_power.o \
> iris_probe.o \
> iris_resources.o \
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> index ca1545d28b53..f57af31dbd9f 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> @@ -443,3 +443,230 @@ const struct iris_firmware_data iris_hfi_gen1_data = {
> .enc_ip_int_buf_tbl = sm8250_enc_ip_int_buf_tbl,
> .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8250_enc_ip_int_buf_tbl),
> };
> +
> +static const struct platform_inst_fw_cap iris_inst_fw_cap_gen1_ar50lt_dec[] = {
> + {
> + .cap_id = STAGE,
> + .min = STAGE_1,
> + .max = STAGE_2,
> + .step_or_mask = 1,
> + .value = STAGE_2,
> + .hfi_id = HFI_PROPERTY_PARAM_WORK_MODE,
> + .set = iris_set_stage,
> + },
> +};
> +
<snip>
> +
> +static const u32 iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl[] = {
gen1...
> + BUF_BIN,
> + BUF_SCRATCH_1,
> +};
> +
> +const struct iris_firmware_data iris_hfi_gen1_ar50lt_data = {
> + .init_hfi_ops = &iris_hfi_gen1_sys_ops_init,
> +
> + .inst_fw_caps_dec = iris_inst_fw_cap_gen1_ar50lt_dec,
> + .inst_fw_caps_dec_size = ARRAY_SIZE(iris_inst_fw_cap_gen1_ar50lt_dec),
> + .inst_fw_caps_enc = inst_fw_cap_gen1_ar50lt_enc,
> + .inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_gen1_ar50lt_enc),
> +
> + .dec_input_config_params_default =
> + sm8250_vdec_input_config_param_default,
> + .dec_input_config_params_default_size =
> + ARRAY_SIZE(sm8250_vdec_input_config_param_default),
> + .enc_input_config_params = sm8250_venc_input_config_param,
> + .enc_input_config_params_size =
> + ARRAY_SIZE(sm8250_venc_input_config_param),
> +
> + .dec_ip_int_buf_tbl = iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl,
> + .dec_ip_int_buf_tbl_size = ARRAY_SIZE(iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl),
same here
> + .dec_op_int_buf_tbl = sm8250_dec_op_int_buf_tbl,
> + .dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8250_dec_op_int_buf_tbl),
> +
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-24 14:25 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Yuanfang Zhang,
Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 05:49:26PM +0800, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
> Add the arm,primecell-periphid property to bypass the AMBA bus
> check and resolve the probe issue.
tnoc.c registers both an AMBA driver and a platform driver. Shouldn't it
be registered as a platform device instead?
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v5 15/16] media: venus: skip QCM2290 if Iris driver is enabled
From: Vikash Garodia @ 2026-06-24 14:24 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-15-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> As the Iris driver now supports the QCM2290 hardware too, there is a
> race between Venus and Iris drivers on binding to the corresponding
> device. Follow the approach used by other platforms and skip QCM2290 in
> the Venus driver if Iris is enabled.
>
> Signed-off-by: Dmitry Baryshkov<dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Dikshita Agarwal<dikshita.agarwal@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/venus/core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 16/16] media: iris: constify inst_fw_cap_sm8250_dec
From: Vikash Garodia @ 2026-06-24 14:23 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-16-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Mark inst_fw_cap_sm8250_dec as a const array, the data is read-only.
>
> Suggested-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov<dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_hfi_gen1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: David Lechner @ 2026-06-24 14:18 UTC (permalink / raw)
To: Lukas, Siratul Islam
Cc: andy, conor+dt, devicetree, jic23, krzk+dt, linux-iio,
linux-kernel, nuno.sa, robh
In-Reply-To: <ajuVjk-lw-DqUVnl@berta-MS-7693>
On 6/24/26 3:30 AM, Lukas wrote:
> Thanks for the review. As i said this is my first time submitting a
> patch. I have looked at already existing spi dac drivers for reference
> but i seemed to have missed quite a lot. But the comments are greatly
> appreciated.
>
> On Wed, Jun 24, 2026 at 12:56:15AM +0600, Siratul Islam wrote:
>> A link to the datasheet here would be nice.
>
> I will try to add all the small suggestions i dont mention explicitly,
> like style issues or using guard instead of manual lock/unlock to v2.
>
>>> +
>>> + if (st->internal_ref) {
>>> + st->vref_uv = 2500000; /* 2.5V internal reference */
>> A note on where this value came from or why this was chosen, or a reference to datasheet would be better.
>
> I think i would add the suggestion from David Lechner to remove the
> internal_ref property completly and add "the way of doing optional
> voltage references". This includes using the macro
> DAC8163_INTERNAL_REF_mV. Would this be acceptable?
>
>> You have a CMD_SOFT_RST defined but not used. Should this be used to reset before doing any configuration?
>
> Yes this is a command which isnt used at this point. But maybe it makes
> sense to reset the DAC first when probing.
In general we tend to reset IIO devices during probe. DACs can be an exception
though since they are output devices and resetting it could change the output.
This device is quite simple anyway, so reset probably isn't needed.
>
> Best regards
> Lukas
^ permalink raw reply
* Re: [PATCH v5 12/16] media: iris: implement support for the Agatti platform
From: Vikash Garodia @ 2026-06-24 14:17 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-12-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Port support for the AR50Lt video codec core (present for example on the
> Agatti platform) to the Iris driver. Unlike more recent cores this
> generation doesn't have the PIPE property (as it always has only one
> pipe). Also, unlike newer platforms, buffer sizes are requested from the
> firmware instead of being calculated by the driver.
>
> Co-developed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/Makefile | 1 +
> drivers/media/platform/qcom/iris/iris_hfi_gen1.c | 227 +++++++++++++++++++++
> .../platform/qcom/iris/iris_platform_common.h | 6 +
> .../platform/qcom/iris/iris_platform_vpu_ar50lt.c | 110 ++++++++++
> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
> drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 13 ++
> drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 1 +
> 7 files changed, 362 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> index f1b204b95694..bbd1f724963e 100644
> --- a/drivers/media/platform/qcom/iris/Makefile
> +++ b/drivers/media/platform/qcom/iris/Makefile
> @@ -14,6 +14,7 @@ qcom-iris-objs += iris_buffer.o \
> iris_hfi_queue.o \
> iris_platform_vpu2.o \
> iris_platform_vpu3x.o \
> + iris_platform_vpu_ar50lt.o \
> iris_power.o \
> iris_probe.o \
> iris_resources.o \
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> index ca1545d28b53..f57af31dbd9f 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1.c
> @@ -443,3 +443,230 @@ const struct iris_firmware_data iris_hfi_gen1_data = {
> .enc_ip_int_buf_tbl = sm8250_enc_ip_int_buf_tbl,
> .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8250_enc_ip_int_buf_tbl),
> };
> +
> +static const struct platform_inst_fw_cap iris_inst_fw_cap_gen1_ar50lt_dec[] = {
> + {
> + .cap_id = STAGE,
> + .min = STAGE_1,
> + .max = STAGE_2,
> + .step_or_mask = 1,
> + .value = STAGE_2,
> + .hfi_id = HFI_PROPERTY_PARAM_WORK_MODE,
> + .set = iris_set_stage,
> + },
> +};
> +
> +static const struct platform_inst_fw_cap inst_fw_cap_gen1_ar50lt_enc[] = {
> + {
> + .cap_id = STAGE,
> + .min = STAGE_1,
> + .max = STAGE_2,
> + .step_or_mask = 1,
> + .value = STAGE_2,
> + .hfi_id = HFI_PROPERTY_PARAM_WORK_MODE,
> + .set = iris_set_stage,
> + },
> + {
> + .cap_id = PROFILE_H264,
> + .min = V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE,
> + .max = V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_MAIN) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_HIGH) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_STEREO_HIGH) |
> + BIT(V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH),
> + .value = V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = PROFILE_HEVC,
> + .min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
> + .max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE),
> + .value = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = LEVEL_H264,
> + .min = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> + .max = V4L2_MPEG_VIDEO_H264_LEVEL_4_2,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1B) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_1_3) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_2_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_3_2) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_0) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_1) |
> + BIT(V4L2_MPEG_VIDEO_H264_LEVEL_4_2),
> + .value = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = LEVEL_HEVC,
> + .min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
> + .max = V4L2_MPEG_VIDEO_HEVC_LEVEL_4_1,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_2) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_2_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_3) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_3_1) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_4) |
> + BIT(V4L2_MPEG_VIDEO_HEVC_LEVEL_4_1),
> + .value = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
> + .hfi_id = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_profile_level_gen1,
> + },
> + {
> + .cap_id = HEADER_MODE,
> + .min = V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE,
> + .max = V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) |
> + BIT(V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME),
> + .value = V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
> + .hfi_id = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_header_mode_gen1,
> + },
> + {
> + .cap_id = BITRATE,
> + .min = BITRATE_MIN,
> + .max = BITRATE_MAX_AR50LT,
> + .step_or_mask = BITRATE_STEP,
> + .value = BITRATE_DEFAULT_AR50LT,
> + .hfi_id = HFI_PROPERTY_CONFIG_VENC_TARGET_BITRATE,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_INPUT_PORT |
> + CAP_FLAG_DYNAMIC_ALLOWED,
> + .set = iris_set_bitrate_gen1,
> + },
> + {
> + .cap_id = BITRATE_MODE,
> + .min = V4L2_MPEG_VIDEO_BITRATE_MODE_VBR,
> + .max = V4L2_MPEG_VIDEO_BITRATE_MODE_CBR,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_BITRATE_MODE_VBR) |
> + BIT(V4L2_MPEG_VIDEO_BITRATE_MODE_CBR),
> + .value = V4L2_MPEG_VIDEO_BITRATE_MODE_VBR,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_RATE_CONTROL,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_bitrate_mode_gen1,
> + },
> + {
> + .cap_id = FRAME_SKIP_MODE,
> + .min = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED,
> + .max = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED) |
> + BIT(V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT),
> + .value = V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + },
> + {
> + .cap_id = FRAME_RC_ENABLE,
> + .min = 0,
> + .max = 1,
> + .step_or_mask = 1,
> + .value = 1,
> + },
> + {
> + .cap_id = GOP_SIZE,
> + .min = 0,
> + .max = (1 << 16) - 1,
> + .step_or_mask = 1,
> + .value = 30,
> + .set = iris_set_u32
> + },
> + {
> + .cap_id = ENTROPY_MODE,
> + .min = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC,
> + .max = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC,
> + .step_or_mask = BIT(V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC) |
> + BIT(V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC),
> + .value = V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_H264_ENTROPY_CONTROL,
> + .flags = CAP_FLAG_OUTPUT_PORT | CAP_FLAG_MENU,
> + .set = iris_set_entropy_mode_gen1,
> + },
> + {
> + .cap_id = MIN_FRAME_QP_H264,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP,
> + .step_or_mask = 1,
> + .value = MIN_QP_8BIT_AR50LT,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MIN_FRAME_QP_HEVC,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP_HEVC,
> + .step_or_mask = 1,
> + .value = MIN_QP_8BIT_AR50LT,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MAX_FRAME_QP_H264,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP,
> + .step_or_mask = 1,
> + .value = MAX_QP,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> + {
> + .cap_id = MAX_FRAME_QP_HEVC,
> + .min = MIN_QP_8BIT_AR50LT,
> + .max = MAX_QP_HEVC,
> + .step_or_mask = 1,
> + .value = MAX_QP_HEVC,
> + .hfi_id = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE_V2,
> + .flags = CAP_FLAG_OUTPUT_PORT,
> + .set = iris_set_qp_range,
> + },
> +};
> +
> +static const u32 iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl[] = {
> + BUF_BIN,
> + BUF_SCRATCH_1,
> +};
> +
> +const struct iris_firmware_data iris_hfi_gen1_ar50lt_data = {
> + .init_hfi_ops = &iris_hfi_gen1_sys_ops_init,
> +
> + .inst_fw_caps_dec = iris_inst_fw_cap_gen1_ar50lt_dec,
> + .inst_fw_caps_dec_size = ARRAY_SIZE(iris_inst_fw_cap_gen1_ar50lt_dec),
> + .inst_fw_caps_enc = inst_fw_cap_gen1_ar50lt_enc,
> + .inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_gen1_ar50lt_enc),
> +
> + .dec_input_config_params_default =
> + sm8250_vdec_input_config_param_default,
> + .dec_input_config_params_default_size =
> + ARRAY_SIZE(sm8250_vdec_input_config_param_default),
> + .enc_input_config_params = sm8250_venc_input_config_param,
> + .enc_input_config_params_size =
> + ARRAY_SIZE(sm8250_venc_input_config_param),
> +
> + .dec_ip_int_buf_tbl = iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl,
> + .dec_ip_int_buf_tbl_size = ARRAY_SIZE(iris_hfi_gen2_ar50lt_dec_ip_int_buf_tbl),
> + .dec_op_int_buf_tbl = sm8250_dec_op_int_buf_tbl,
> + .dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8250_dec_op_int_buf_tbl),
> +
> + .enc_ip_int_buf_tbl = sm8250_enc_ip_int_buf_tbl,
> + .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8250_enc_ip_int_buf_tbl),
> +};
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
> index 6a189489369f..bc04831ae7fc 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
> @@ -39,6 +39,10 @@ struct iris_inst;
> #define MAX_HEVC_VBR_LAYER_HP_SLIDING_WINDOW 5
> #define MAX_HIER_CODING_LAYER_GEN1 6
>
> +#define BITRATE_MAX_AR50LT 100000000
> +#define BITRATE_DEFAULT_AR50LT 20000000
> +#define MIN_QP_8BIT_AR50LT 0
> +
> enum stage_type {
> STAGE_1 = 1,
> STAGE_2 = 2,
> @@ -51,8 +55,10 @@ enum pipe_type {
> };
>
> extern const struct iris_firmware_data iris_hfi_gen1_data;
> +extern const struct iris_firmware_data iris_hfi_gen1_ar50lt_data;
> extern const struct iris_firmware_data iris_hfi_gen2_data;
>
> +extern const struct iris_platform_data qcm2290_data;
> extern const struct iris_platform_data qcs8300_data;
> extern const struct iris_platform_data sc7280_data;
> extern const struct iris_platform_data sm8250_data;
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c b/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c
> new file mode 100644
> index 000000000000..393256f39112
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu_ar50lt.c
> @@ -0,0 +1,110 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "iris_core.h"
> +#include "iris_ctrls.h"
> +#include "iris_hfi_gen2.h"
> +#include "iris_hfi_gen2_defines.h"
> +#include "iris_platform_common.h"
> +#include "iris_vpu_buffer.h"
> +#include "iris_vpu_common.h"
> +
> +#define WRAPPER_INTR_STATUS_A2HWD_BMSK 0x10
> +
> +const struct iris_firmware_desc iris_vpu_ar50lt_p1_gen1_s6_desc = {
> + .firmware_data = &iris_hfi_gen1_ar50lt_data,
> + .get_vpu_buffer_size = iris_vpu_ar50lt_gen1_buf_size,
unlike gen2, gen1 is calling buffer_requirement from firmware for every
buffer types. And given that call is a synchronous call to firmware i.e
it calls and wait for a response, i see it can cause delay (and infact
not needed) if called for multiple internal buffer types. Can we see if
we can call that call once ? That call to firmware (get prop for
HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS) fetches requirement for all
buffer types.
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: iio: dac: Add DAC8163
From: David Lechner @ 2026-06-24 14:14 UTC (permalink / raw)
To: Lukas Metz
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-iio,
devicetree
In-Reply-To: <ajt0vibLhh6Mmhoc@berta-MS-7693>
On 6/24/26 1:25 AM, Lukas Metz wrote:
> Thanks a lot for the review. This is my first time submitting a
> patch so im grateful for the detailed comments and suggestions.
>
> On Tue, Jun 23, 2026 at 02:17:04PM -0500, David Lechner wrote:
>> It is more logical to put the dt-bindings patch first in the series
>> before the driver that makes use of it.
>
> I will reorder the commits in v2.
For future reference, you don't need to respond to comments that you
agree with (save us time reading).
>
>> There are a couple of more SPI properties needed since this is not a "normal"
>> SPI device. We can only write and not read because there is no D_OUT pin. So
>>
>> spi-rx-bus-width:
>> items:
>> - const: 0
>>
>> will describe this.
>
> I will the add the suggested changes to v2. Are there any other poperties
> i have missed? Same for the other comments regarding vendor-prefix,
> spi-max-frequency, avdd-supply and vref supply name.
>
>> We also want the binding to be complete even if the driver doesn't all of it, so
>> `clear-gpios` and `sync-gpios` probably make sense too.
>
> SYNC pin is the chip select pin of the device as described below. In
> that case i dont need to add it here right?
Ah, OK. It is probably worth mentioning that in the top-level description
here in the bindings.
>
>> Usually, we don't bother with a property like this since it is redundant.
>> If an external reference supply is given, then it gets used, otherwise
>> the internal reference is used.
>
> That sounds logical. I will remove the property completly.
>
>> These chips don't appear to have a chip select pin, so this comment
>> doesn't make sense to me. More logical would be to just use dac@0
>> and reg = <0>; since it should just be ignored.
>
> The SYNC pin on the device acts like a chip select pin.
> According to the datasheet: when the pin goes low it enables the input shift
> register. At least that was my understanding. On my board i have tested the
> driver with the chip select signal connected to the SYNC pin. The
> example comes straight from my own device tree where i have two devices
> on the bus. Thats why i used reg<1> here but i can change it to 0 and
> remove the comment.>
>> The pin is marked active low in the datasheet, so I would expect
>> this to be GPIO_ACTIVE_LOW.
>
> I wasnt sure about that. The pin needs to be held low continuously. I
> thought when the pin is marked active low and i initialize the pin with
> GPIOD_OUT_LOW the result will be that the pin is held high. To match the
> datasheet description seems logical though.
>
The GPIOD_OUT_LOW and GPIOD_OUT_HIGH names in the kernel are not ideal.
Think of them as "deasserted" and "asserted". If the devicetree has
GPIO_ACTIVE_LOW, then GPIOD_OUT_HIGH will "assert" the pin by pulling
the voltage low (because it is active low).
^ permalink raw reply
* Re: [PATCH v6 1/3] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Mark Brown @ 2026-06-24 14:13 UTC (permalink / raw)
To: Rob Herring
Cc: Otto Pflüger, Liam Girdwood, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260624130613.GA4054894-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
On Wed, Jun 24, 2026 at 08:06:13AM -0500, Rob Herring wrote:
> On Sat, Jun 20, 2026 at 10:54:00AM +0200, Otto Pflüger wrote:
> > Add bindings for the regulators found in the Spreadtrum/Unisoc SC2730
> > PMIC, used e.g. with the UMS512 and UMS9230 SoCs.
> >
> > Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> > .../bindings/regulator/sprd,sc2730-regulator.yaml | 44 ++++++++++++++++++++++
> > 1 file changed, 44 insertions(+)
> Applied for rc1 to fix the warnings.
Warnings?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-24 14:05 UTC (permalink / raw)
To: Sunyun Yang, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, dmitry.baryshkov, maarten.lankhorst, rfoss,
mripard
Cc: Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <CAFQXuNYq5QYAXRzcUBnyvVh5ofPBVYONCs1dM6qPgK0BDja5Ow@mail.gmail.com>
On 11/05/2026 05:28, Sunyun Yang wrote:
> <syyang@lontium.com> 于2026年5月8日周五 22:25写道：
>>
>> From: Sunyun Yang <syyang@lontium.com>
>>
>> LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port
>> mipi dsi and output hdmi, differences in hardware features:
>> - LT9611C: supports 1-port mipi dsi to hdmi 1.4
>> - LT9611EX: supports 2-port mipi dsi to hdmi 1.4
>> - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0
>>
>> Signed-off-by: Sunyun Yang <syyang@lontium.com>
>> ---
>> .../bindings/display/bridge/lontium,lt9611.yaml | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> index 429a06057ae8..e0821a63d9d7 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>> @@ -4,19 +4,23 @@
>> $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
>> +title: Lontium LT9611(UXC/C/EX/UXD) 2 Port MIPI DSI to HDMI Bridge
>>
>> maintainers:
>> - Vinod Koul <vkoul@kernel.org>
>>
>> description: |
>> - The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
>> + The LT9611、LT9611UXC、LT9611C、LT9611EX and LT9611UXD
>> + are bridge devices which convert DSI to HDMI
>>
>> properties:
>> compatible:
>> enum:
>> - lontium,lt9611
>> + - lontium,lt9611c
>> + - lontium,lt9611ex
>> - lontium,lt9611uxc
>> + - lontium,lt9611uxd
>>
>> reg:
>> maxItems: 1
>> --
>
> Gentle ping.
> Thanks.
Except mess with threading, your patchset does not build, when applied
on next-20260618.
What is the base of this?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The PCIe PHY node references mipi_pcie_analog_dphy via its phys property.
Enable this analog PHY node to make PCIe functionally viable.
Fixes: 9715b01da6cf ("arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slots")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 7ba249cc3d56..4f13e2b041e1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -431,6 +431,10 @@ gpio_speaker: gpio-controller@1f {
};
};
+&mipi_pcie_analog_dphy {
+ status = "okay";
+};
+
&pdm {
pinctrl-0 = <&pdm_dclk_a14_pins>, <&pdm_din0_pins>,
<&pdm_din1_pins>, <&pdm_din2_pins>, <&pdm_din3_pins>;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
Set the pcie_phy node to "disabled" as it is not used on some boards
and should be enabled per-board when necessary.
This change suppresses the deferred probe warning:
platform ff644000.phy: deferred probe pending: (reason unknown)
The meson-axg dtsi now disables pcie_phy by default, so enable it
for the s400 board to support PCIe functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 285c6ac1dd61..7ba249cc3d56 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -448,6 +448,10 @@ &pcieB {
status = "okay";
};
+&pcie_phy {
+ status = "okay";
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_x20_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 8ca3ac09b306..5b8ef98f6d03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -328,6 +328,7 @@ pcie_phy: phy@ff644000 {
phys = <&mipi_pcie_analog_dphy>;
phy-names = "analog";
#phy-cells = <0>;
+ status = "disabled";
};
pdm: audio-controller@ff632000 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy)
pin description, which is required for NAND controller operation.
Add it to the pinmux list.
Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6457667d974e..8ca3ac09b306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -481,7 +481,8 @@ mux {
"nand_ale",
"nand_cle",
"nand_wen_clk",
- "nand_ren_wr";
+ "nand_ren_wr",
+ "nand_rb0";
function = "nand";
input-enable;
bias-pull-up;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
nand_rb0 and emmc_ds share one pad. Before enabling nand_rb0 for nfc,
disable nfc nodes by default to resolve pinctrl resource contention.
No mainline AXG boards enable nfc currently thus no extra DTS adjustments
are needed.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f1f53fd98ae2..6457667d974e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1999,6 +1999,7 @@ nfc: nand-controller@7800 {
clocks = <&clkc CLKID_SD_EMMC_C>,
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "device";
+ status = "disabled";
};
usb2_phy1: phy@9020 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
- Disable nfc node by default ahead of nand_rb0 pin addition.
- Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
- Disable pcie_phy by default to suppress probe warning.
- Re-enable pcie_phy on S400 board to preserve PCIe functionality.
- Enable mipi_pcie_analog_dphy for PCIe on S400 board.
Changes in v4:
- Add patch to enable mipi_pcie_analog_dphy for PCIe on S400 board.
- Link to v3:
https://lore.kernel.org/all/20260617082239.645562-1-jerrysteve1101@gmail.com/
Changes in v3:
- squash "disable pcie_phy node by default" and "enable pcie_phy in
meson-axg-s400" patches
- Link to v2:
https://lore.kernel.org/all/20260617071604.635627-1-jerrysteve1101@gmail.com/
Changes in v2:
- Add patch to disable nfc node by default.
- Link to v1:
https://lore.kernel.org/all/20260529140605.1070764-1-jerrysteve1101@gmail.com/
Jun Yan (4):
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to
nand_all_pins
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for
PCIe
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 8 ++++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 ++++-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Suzuki K Poulose @ 2026-06-24 13:51 UTC (permalink / raw)
To: Jie Gan, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f39ec59f-97c4-4d5f-bf02-560adae312d9@oss.qualcomm.com>
On 24/06/2026 14:48, Jie Gan wrote:
>
>
> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>> its probe function if the arm,primecell-periphid property is absent.
>>> This causes a deferred probe issue for the TraceNoC device, as the
>>> CID/PID cannot be read from the periphid register.
>>
>> Why does it probe defer?
>>
>
> For an AMBA device, the periphid is mandatory for probing. In the
> amba_match function, AMBA attempts to read the periphid from the CID/PID
> registers if the arm,primecell-periphid property is absent in the device
> tree. If this read fails, it returns -EPROBE_DEFER, and the probe
> ultimately fails.
Why does it fail ? power management ? hw broken ? Is it really AMBA or
do you pretend that to be an AMBA device by faking the CID/PID?
Suzuki
> Most AMBA devices expose valid CID/PID registers, so specifying
> arm,primecell-periphid in the device tree is usually unnecessary.
> However, for the TraceNoC device in this case, AMBA cannot reliably read
> the periphid from the corresponding registers.
>
>> And is this required for all TNOC devices?
>
> So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
> platforms, and all exhibit probe failures due to the same root cause.
>
> I prefer to fix it on Kaanapali first.
>
> Thanks,
> Jie
>
>>
>> Konrad
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 13:48 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f0634a64-1141-4ff9-9033-825e3c75d28d@oss.qualcomm.com>
On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
> On 6/24/26 11:49 AM, Jie Gan wrote:
>> The AMBA bus attempts to read the CID/PID of a device before invoking
>> its probe function if the arm,primecell-periphid property is absent.
>> This causes a deferred probe issue for the TraceNoC device, as the
>> CID/PID cannot be read from the periphid register.
>
> Why does it probe defer?
>
For an AMBA device, the periphid is mandatory for probing. In the
amba_match function, AMBA attempts to read the periphid from the CID/PID
registers if the arm,primecell-periphid property is absent in the device
tree. If this read fails, it returns -EPROBE_DEFER, and the probe
ultimately fails.
Most AMBA devices expose valid CID/PID registers, so specifying
arm,primecell-periphid in the device tree is usually unnecessary.
However, for the TraceNoC device in this case, AMBA cannot reliably read
the periphid from the corresponding registers.
> And is this required for all TNOC devices?
So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
platforms, and all exhibit probe failures due to the same root cause.
I prefer to fix it on Kaanapali first.
Thanks,
Jie
>
> Konrad
^ permalink raw reply
* Re: [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 13:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-copper-albatross-of-youth-6abae8@quoll>
Hi Krzysztof,
> Please start testing your patches. This for sure fails tests.
>
> It does not look like you tested the DTS against bindings. Please run
> 'make dtbs_check W=1' (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.
You are right, I had tested my patches but wrongly. It is indeed failling.
I'm very sorry for that. Thank's for taking the time to explain.
Best regards,
Grégoire
^ permalink raw reply
* [PATCH] dt-bindings: mfd: khadas,mcu: Drop type reference from "fan-supply"
From: Rob Herring (Arm) @ 2026-06-24 13:36 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Ronald Claveau
Cc: Conor Dooley, linux-amlogic, devicetree, linux-kernel
"fan-supply" already has a type and shouldn't have a type $ref. Drop the
$ref to fix the warning.
Fixes: 39dd85d9246e ("dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU")
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
Applying this to my tree and sending to Linus for rc1.
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 1f135618e3b6..c6f91e7bc8aa 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -28,7 +28,6 @@ properties:
fan-supply:
description: Phandle to the regulator that powers the fan.
- $ref: /schemas/types.yaml#/definitions/phandle
required:
- compatible
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
From: William Bright @ 2026-06-24 13:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com>
Hi all,
Another gentle ping on this patch series.
Many thanks,
Will
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Konrad Dybcio @ 2026-06-24 13:28 UTC (permalink / raw)
To: Esteban Urrutia, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <b3541802-3035-40ee-8327-a65bd5d2dfee@proton.me>
On 6/24/26 3:26 PM, Esteban Urrutia wrote:
>
>
> On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>>> This is mentioned in the memory map description, but is not part
>>> of it.
>>>
>>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>>> probably valid
>>
>> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
>> trapping it.
> Then, should device trees delete these memory regions on a case-by-case
> basis, or be left as is?
I'd delete it and reintroduce as necessary
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Konrad Dybcio @ 2026-06-24 13:27 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On 6/24/26 11:49 AM, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
Why does it probe defer?
And is this required for all TNOC devices?
Konrad
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Esteban Urrutia @ 2026-06-24 13:26 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <6123a923-21dd-4f69-9ac5-02165963027c@oss.qualcomm.com>
On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>> This is mentioned in the memory map description, but is not part
>> of it.
>>
>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>> probably valid
>
> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
> trapping it.
Then, should device trees delete these memory regions on a case-by-case
basis, or be left as is?
Regards,
Esteban
^ permalink raw reply
* Re: [PATCH v11] PCI: Add support for PCIe WAKE# interrupt
From: Krishna Chaitanya Chundru @ 2026-06-24 13:25 UTC (permalink / raw)
To: sashiko-reviews; +Cc: linux-pci, devicetree, robh, conor+dt
In-Reply-To: <20260624114008.7F7A51F00A3A@smtp.kernel.org>
On 6/24/2026 5:10 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
> - [High] Hot-removing an endpoint sharing a WAKE# GPIO breaks wakeup for all remaining endpoints on that line.
> - [High] pci_remove_of_wake_gpio() unconditionally clears the device's wakeup configuration and wake IRQ, even if it never acquired the WAKE# GPIO.
> - [High] WAKE# GPIO configuration forces device wakeup to be enabled by default, violating PCI PM policy.
> - [Medium] Calling platform_pci_configure_wake() after device_add() creates a race condition that overwrites driver or userspace wakeup configuration.
> - [Medium] Hardcoded IRQ_TYPE_LEVEL_LOW ignores Device Tree GPIO polarity for the WAKE# interrupt.
> - [Medium] WAKE# GPIO configuration permanently fails if the GPIO provider returns -EPROBE_DEFER.
> --
>
> commit 9e1cd6307066585f1f51b9e7de95ae7950936ba0
> Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> PCI: Add support for PCIe WAKE# interrupt
>
> According to the PCI Express specification (PCIe r7.0, Section 5.3.3.2),
> two link wakeup mechanisms are defined: Beacon and WAKE#. This change adds
> support for the WAKE# mechanism in the PCI core.
>
> Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
> Link: https://github.com/devicetree-org/dt-schema/pull/170
>
>> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
>> index 8b18c4ba845cf..0f5effe1d7026 100644
>> --- a/drivers/pci/of.c
>> +++ b/drivers/pci/of.c
> [ ... ]
>
>> + ret = dev_pm_set_dedicated_wake_irq(&pdev->dev, wake_irq);
>> + if (ret < 0) {
>> + pci_err(pdev, "Failed to set WAKE# IRQ: %d\n", ret);
>> + return;
>> + }
>> +
>> + ret = irq_set_irq_type(wake_irq, IRQ_TYPE_LEVEL_LOW);
> [Severity: Medium]
> Does hardcoding IRQ_TYPE_LEVEL_LOW here override the logical polarity
> specified in the Device Tree?
>
> If the WAKE# GPIO is specified via the wake-gpios property with flags like
> GPIO_ACTIVE_HIGH, this explicit type setting might ignore those flags and
> fail to trigger on platforms with an inverted physical signal.
As per PCIe spec WAKE# is active low signal.
>
>> + if (ret < 0) {
>> + dev_pm_clear_wake_irq(&pdev->dev);
>> + pci_err(pdev, "Failed to set irq_type: %d\n", ret);
>> + return;
>> + }
>> +
>> + device_init_wakeup(&pdev->dev, true);
> [Severity: High]
> Could this forcefully enable wakeup by default and violate standard PCI PM
> policy?
>
> Calling device_init_wakeup() with true marks the device as wakeup capable
> and also sets dev->power.should_wakeup = true. The standard PCI core
> behavior usually marks devices as wakeup capable but leaves enablement to
> userspace opt-in.
if the client driver wants to enable wakeup IRQ, and if the WAKE# is described for
root port only, then we can't ask client driver to enable root port device wake up
capability and in suspend noirq we are not allowed to enable wakeirq, so we
are enabling here.
>> +}
>> +
>> +void pci_configure_of_wake_gpio(struct pci_dev *dev)
>> +{
>> + struct device_node *dn = pci_device_to_OF_node(dev);
>> + struct gpio_desc *gpio;
>> +
>> + if (!dn)
>> + return;
>> + /*
>> + * fwnode_gpiod_get() may fail with -EBUSY (e.g. shared WAKE#), but the
>> + * actual WAKE# trigger from the device would still work and the host
>> + * controller driver will enable power to the topology.
>> + *
>> + * -EPROBE_DEFER cannot be propagated here since pci_device_add() has no
>> + * retry mechanism.
>> + */
>> + gpio = fwnode_gpiod_get(of_fwnode_handle(dn), "wake", GPIOD_IN, NULL);
>> + if (!IS_ERR(gpio)) {
> [Severity: Medium]
> Since pci_device_add() has no retry mechanism, does swallowing -EPROBE_DEFER
> here mean WAKE# functionality will permanently fail if the GPIO controller
> providing the WAKE# line hasn't probed yet?
In device tree model -EPROBE_DEFER for GPIO is highly unlikely. since PERST gpio's
is already parsed in the controller driver before enumeration starts.
> [Severity: High]
> If multiple endpoints share a WAKE# GPIO, only the first device acquires
> it while the rest fail with -EBUSY. Can this break wakeup capabilities
> for all remaining endpoints if the first device is later hot-removed?
>
> When the first device is removed, it frees the shared GPIO via
> pci_remove_of_wake_gpio(), leaving the remaining active endpoints without
> an associated wake IRQ.
in this scenarios, ideally bridge also will share same WAKE# gpio, so if the
bridge
is removed below devices also removed. so it should not effect.
>> + dev->wake = gpio;
>> + pci_configure_wake_irq(dev, gpio);
>> + }
>> +}
>> +
>> +void pci_remove_of_wake_gpio(struct pci_dev *dev)
>> +{
>> + struct device_node *dn = pci_device_to_OF_node(dev);
>> +
>> + if (!dn)
>> + return;
>> +
>> + device_init_wakeup(&dev->dev, false);
>> + dev_pm_clear_wake_irq(&dev->dev);
>> + gpiod_put(dev->wake);
>> + dev->wake = NULL;
>> +}
> [Severity: High]
> Should this cleanup block be guarded by a check for dev->wake?
>
> As it stands, if a PCI device with an OF node failed to acquire the GPIO
> (e.g., it returned -EBUSY) or didn't have a wake property, this will still
> unconditionally clear its PME wakeup capability and detach any dedicated
> wake IRQ the driver might have configured itself.
ack.
- Krishna Chaitanya.
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index b63cd0c310bc0..143b0bd35b3c9 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
> [ ... ]
>
>> @@ -2775,6 +2775,8 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>> /* Establish pdev->tsm for newly added (e.g. new SR-IOV VFs) */
>> pci_tsm_init(dev);
>>
>> + platform_pci_configure_wake(dev);
> [Severity: Medium]
> Does calling platform_pci_configure_wake() after device_add() create a race
> condition?
>
> By the time this is called, the device is already visible in sysfs and
> uevents have fired. Local userspace tools configuring power/wakeup or
> asynchronous driver probes could have their configurations silently
> overwritten by the subsequent device_init_wakeup() call.
>
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64: dts: qcom: Add Vicharak Axon Mini
From: Konrad Dybcio @ 2026-06-24 13:24 UTC (permalink / raw)
To: Ajit Singh, Bjorn Andersson
Cc: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260624125443.18729-4-blfizzyy@gmail.com>
On 6/24/26 2:54 PM, Ajit Singh wrote:
> Add DTS for the Vicharak Axon Mini board based on the Qualcomm
> QCS6490 SoC.
>
> This adds debug UART, eMMC, UFS, SDIO WLAN, USB 2.0 host, PCIe
> support along with regulators.
>
> The UFS ICE block is kept disabled because enabling it currently causes
> an SError during qcom_ice_create() on this board. UFS works without ICE.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Ajit Singh <blfizzyy@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ 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