* [PATCH v2 1/3] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel,
Paul Walmsley
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while back. Paul did a much better job at
finding the right words to mourn this loss than I ever could, so I will
leave this link here:
https://lore.kernel.org/lkml/alpine.DEB.2.21.999.2407240345480.11116@utopia.booyaka.com/T/#u
Co-developed-by: Paul Walmsley <pjw@kernel.org>
Co-developed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Co-developed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v2:
- add more missing entries
CREDITS | 10 ++++++++++
MAINTAINERS | 1 -
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/CREDITS b/CREDITS
index 885fb05d8816..afd1f70b41cf 100644
--- a/CREDITS
+++ b/CREDITS
@@ -3645,7 +3645,17 @@ D: Macintosh IDE Driver
N: Peter De Schrijver
E: stud11@cc4.kuleuven.ac.be
+E: p2@mind.be
+E: peter.de-schrijver@nokia.com
+E: pdeschrijver@nvidia.com
+E: p2@psychaos.be
+D: Apollo Domain workstations
+D: Ariadne and Hydra Amiga Ethernet drivers
+D: IBM PS/2, Microchannel, and Token Ring support
D: Mitsumi CD-ROM driver patches March version
+D: TWL4030 power management and audio codec driver
+D: OMAP power management
+D: NVIDIA Tegra clock and BPMP drivers, among many other things
S: Molenbaan 29
S: B2240 Zandhoven
S: Belgium
diff --git a/MAINTAINERS b/MAINTAINERS
index ef978bfca514..ffe20d770249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26145,7 +26145,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git
N: [^a-z]tegra
TEGRA CLOCK DRIVER
-M: Peter De Schrijver <pdeschrijver@nvidia.com>
M: Prashant Gaikwad <pgaikwad@nvidia.com>
S: Supported
F: drivers/clk/tegra/
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/3] Documentation: ABI: Take over as contact for sysfs-driver-tegra-fuse
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel
In-Reply-To: <20260417131549.3154534-1-thierry.reding@kernel.org>
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while ago, so I'll be taking over as contact
for this ABI documentation.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Documentation/ABI/testing/sysfs-driver-tegra-fuse | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
index b8936fad2ccf..47d5513100f6 100644
--- a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
+++ b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
@@ -1,6 +1,6 @@
What: /sys/devices/*/<our-device>/fuse
Date: February 2014
-Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
+Contact: Thierry Reding <thierry.reding@kernel.org>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
data programmed at the factory. The data is laid out in 32bit
--
2.52.0
^ permalink raw reply related
* [PATCH v2 3/3] dt-bindings: reserved-memory: Change maintainer for BPMP SHMEM
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel
In-Reply-To: <20260417131549.3154534-1-thierry.reding@kernel.org>
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while ago, so change the maintainers for BPMP
SHMEM to Jon and myself.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
index 4380f622f9a9..6efadc5f8078 100644
--- a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
@@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Tegra CPU-NS - BPMP IPC reserved memory
maintainers:
- - Peter De Schrijver <pdeschrijver@nvidia.com>
+ - Thierry Reding <thierry.reding@kernel.org>
+ - Jonathan Hunter <jonathanh@nvidia.com>
description: |
Define a memory region used for communication between CPU-NS and BPMP.
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: sc8280xp: use refgen regulator for DSI
From: Pengyu Luo @ 2026-04-17 13:24 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <54ab414e-a33e-4cdb-a125-5a980ea7e851@oss.qualcomm.com>
On Fri, Apr 17, 2026 at 8:37 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 4/17/26 2:23 PM, Pengyu Luo wrote:
> > On Sat, Feb 28, 2026 at 9:13 PM Dmitry Baryshkov
> > <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >>
> >> On Sat, Feb 28, 2026 at 08:54:30PM +0800, Pengyu Luo wrote:
> >>> Use it for the DSI controllers, since DSI nodes have been added.
> >>>
> >>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> >>> ---
> >>> This patch depends on the below series:
> >>> https://lore.kernel.org/linux-arm-msm/20260228101907.18043-1-mitltlatltl@gmail.com/
> >>
> >> Why was it not squashed into that series? I'd assume that DSI nodes are
> >> incomplete and are working "by luck" without the refgen supplies.
> >>
> >
> > Today, I did a casual read. I found the register(0x8900000 + 0x80) to
> > enable refgen is always 0 on windows. The refgen driver may be not
> > compatible with sc8280xp or the DT configuration is wrong.
>
> The Linux driver casts a software vote. Most newer SoCs should have
> a separate hw line between the PHYs and the REFGEN regulator to take
> care of it automatically.
>
> Even if a little unnecessary, this won't hurt
>
> I *think* base+0xc & BIT(3) should tell you whether the power is
> actually flowing at a given moment
>
I see. Thanks for your explanation!
Best wishes,
Pengyu
> Konrad
^ permalink raw reply
* Re: [PATCH v8 1/5] soc: qcom: ice: Add OPP-based clock scaling support for ICE
From: Harshal Dev @ 2026-04-17 13:25 UTC (permalink / raw)
To: Abhinaba Rakshit, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Adrian Hunter, Ulf Hansson, Neeraj Soni, Kuldeep Singh,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <20260409-enable-ice-clock-scaling-v8-1-ca1129798606@oss.qualcomm.com>
On 4/9/2026 5:14 PM, Abhinaba Rakshit wrote:
> Register optional operation-points-v2 table for ICE device
> during device probe. Attach the OPP-table with only the ICE
> core clock. Since, dtbinding is on a trasition phase to include
> iface clock and clock-names, attaching the opp-table to core clock
> remains options such that it does not cause probe failures.
>
> Introduce clock scaling API qcom_ice_scale_clk which scale ICE
> core clock based on the target frequency provided and if a valid
> OPP-table is registered. Use round_ceil passed to decide on the
> rounding of the clock freq against OPP-table. Clock scaling is
> disabled when a valid OPP-table is not registered.
>
> This ensures when an ICE-device specific OPP table is available,
> use the PM OPP framework to manage frequency scaling and maintain
> proper power-domain constraints.
>
> Also, ensure to drop the votes in suspend to prevent power/thermal
> retention. Subsequently restore the frequency in resume from
> core_clk_freq which stores the last ICE core clock operating frequency.
>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> drivers/soc/qcom/ice.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++
> include/soc/qcom/ice.h | 2 ++
> 2 files changed, 94 insertions(+)
>
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index bf4ab2d9e5c0360d8fe6135cc35f93b6b09e7a0e..9e869e6abc6300c7608b4d9a18e7f3e80c93f5e7 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -16,6 +16,7 @@
[..]
> @@ -742,6 +800,40 @@ static int qcom_ice_probe(struct platform_device *pdev)
> if (IS_ERR(engine))
> return PTR_ERR(engine);
>
> + /* qcom_ice_create() may return NULL if scm calls are not available */
> + if (!engine)
> + return -EOPNOTSUPP;
> +
> + err = devm_pm_opp_set_clkname(&pdev->dev, "core");
> + if (err && err != -ENOENT) {
> + dev_err(&pdev->dev, "Unable to set core clkname to OPP-table\n");
> + return err;
> + }
> +
> + /* OPP table is optional */
> + err = devm_pm_opp_of_add_table(&pdev->dev);
> + if (err && err != -ENODEV) {
> + dev_err(&pdev->dev, "Invalid OPP table in Device tree\n");
> + return err;
> + }
> +
> + /*
> + * The OPP table is optional. devm_pm_opp_of_add_table() returns
> + * -ENODEV when no OPP table is present in DT, which is not treated
> + * as an error. Therefore, track successful OPP registration only
> + * when the return value is 0.
> + */
> + engine->has_opp = (err == 0);
> + if (!engine->has_opp)
> + dev_info(&pdev->dev, "ICE OPP table is not registered, please update your DT\n");
> +
> + /*
> + * Store the core clock rate for suspend resume cycles,
> + * against OPP aware DVFS operations. core_clk_freq will
> + * have a valid value only for non-legacy bindings.
> + */
> + engine->core_clk_freq = clk_get_rate(engine->core_clk);
> +
When you are calling 4-5 functions in a function, it's probably time to define another
function to keep things simple. Maybe qcom_ice_attach_opp_table().
Also, I still have issues with engine->has_opp = (err == 0), mostly because I don't
see this style used at other placed in the kernel. I would still suggest that you
make it simpler, but I won't hard-request it.
/* The same explanatory comment as before */
if (err == -ENODEV)
engine->has_opp = false;
dev_info(...);
else
engine->has_opp = true;
With these optional suggestions, feel free to add:
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> platform_set_drvdata(pdev, engine);
>
> return 0;
> diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
> index 4bee553f0a59d86ec6ce20f7c7b4bce28a706415..4eb58a264d416e71228ed4b13e7f53c549261fdc 100644
> --- a/include/soc/qcom/ice.h
> +++ b/include/soc/qcom/ice.h
> @@ -30,5 +30,7 @@ int qcom_ice_import_key(struct qcom_ice *ice,
> const u8 *raw_key, size_t raw_key_size,
> u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
> struct qcom_ice *devm_of_qcom_ice_get(struct device *dev);
> +int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
> + bool round_ceil);
>
> #endif /* __QCOM_ICE_H__ */
>
^ permalink raw reply
* Re: [PATCH v7 2/3] ufs: host: Add ICE clock scaling during UFS clock changes
From: Harshal Dev @ 2026-04-17 13:26 UTC (permalink / raw)
To: Abhinaba Rakshit, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Neeraj Soni
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, linux-scsi
In-Reply-To: <20260302-enable-ufs-ice-clock-scaling-v7-2-669b96ecadd8@oss.qualcomm.com>
On 3/2/2026 4:19 PM, Abhinaba Rakshit wrote:
> Implement ICE (Inline Crypto Engine) clock scaling in sync with
> UFS controller clock scaling. This ensures that the ICE operates at
> an appropriate frequency when the UFS clocks are scaled up or down,
> improving performance and maintaining stability for crypto operations.
>
> For scale_up operation ensure to pass ~round_ceil (round_floor)
> and vice-versa for scale_down operations.
>
> Incase of OPP scaling is not supported by ICE, ensure to not prevent
> devfreq for UFS, as ICE OPP-table is optional.
>
> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Regards,
Harshal
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: thermal: Add Google GS101 TMU
From: Tudor Ambarus @ 2026-04-17 13:28 UTC (permalink / raw)
To: Alexey Klimov, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alim Akhtar, Bartlomiej Zolnierkiewicz,
Kees Cook, Gustavo A. R. Silva, Peter Griffin, André Draszik
Cc: willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <DGUJIFLIOK7Y.1Q4PZQU3MOWTT@linaro.org>
On 3/5/26 5:48 AM, Alexey Klimov wrote:
> Hi Tudor,
>
> On Mon Jan 19, 2026 at 12:08 PM GMT, Tudor Ambarus wrote:
>> Document the Thermal Management Unit (TMU) found on the Google GS101 SoC.
>>
>> The GS101 TMU utilizes a hybrid control model shared between the
>> Application Processor (AP) and the ACPM (Alive Clock and Power Manager)
>> firmware.
>>
>> While the TMU is a standard memory-mapped IP block, on this platform
>
> this ^^
>
okay
cut
> Is it Google TMU hardware block or Exynos/Samsung TMU block?
>
> My understanding at this point is that ACPM interface, ACPM protocols, etc
> appeared on Samsung SoCs before gs101 (maybe even before initial SCMI
> prototyping). It looks like ACPM firmware, communication via mailboxes,
> TMU channel, dealing with TMU behing ACPM, etc are actually a standard
> Samsung Exynos architectural feature, rather than a Google-specific
> implementation. I can't say though what was the first chipset where it
> was implemented.
autov920, exynos850 too can use the hybrid ACPM TMU approach.
I'll generalize the description.
>
> Given that this is a Samsung design that predates the gs101, would it
> make sense to use more generic name for this binding to reflect that
> it is Exynos-derived? That would save us from generalizing things later
The name has to match the compatible. We can rename it when other Samsung
compatibles are added.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH v8 3/5] mmc: sdhci-msm: Set ICE clk to TURBO at sdhci ICE init
From: Harshal Dev @ 2026-04-17 13:29 UTC (permalink / raw)
To: Abhinaba Rakshit, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Adrian Hunter, Ulf Hansson, Neeraj Soni, Kuldeep Singh,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, linux-scsi, linux-mmc, devicetree,
Konrad Dybcio
In-Reply-To: <20260409-enable-ice-clock-scaling-v8-3-ca1129798606@oss.qualcomm.com>
On 4/9/2026 5:14 PM, Abhinaba Rakshit wrote:
> MMC controller lacks a clock scaling mechanism, unlike the UFS
> controller. By default, the MMC controller is set to TURBO mode
> during probe, but the ICE clock remains at XO frequency,
> leading to read/write performance degradation on eMMC.
>
> To address this, set the ICE clock to TURBO during sdhci_msm_ice_init
> to align it with the controller clock. This ensures consistent
> performance and avoids mismatches between the controller
> and ICE clock frequencies.
>
> For platforms where ICE is represented as a separate device,
> use the OPP framework to vote for TURBO mode, maintaining
> proper voltage and power domain constraints.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> drivers/mmc/host/sdhci-msm.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
[...]
>
> static const struct blk_crypto_ll_ops sdhci_msm_crypto_ops; /* forward decl */
> +static int sdhci_msm_ice_scale_clk(struct sdhci_msm_host *msm_host, unsigned long target_freq,
> + bool round_ceil); /* forward decl */
>
> static int sdhci_msm_ice_init(struct sdhci_msm_host *msm_host,
> struct cqhci_host *cq_host)
> @@ -1964,6 +1966,11 @@ static int sdhci_msm_ice_init(struct sdhci_msm_host *msm_host,
> }
>
> mmc->caps2 |= MMC_CAP2_CRYPTO;
> +
> + err = sdhci_msm_ice_scale_clk(msm_host, INT_MAX, false);
The 2nd parameter is an unsigned long, do you really want to pass INT_MAX here? I would go with
UINT_MAX. But still, why go with such a high value? Do we not have an upper bound for the clk
frequency that we know we can't ever exceed for any target across OPP tables? If not, then maybe
UINT_MAX is best we can do here.
Regards,
Harshal
> + if (err && err != -EOPNOTSUPP)
> + dev_warn(dev, "Unable to boost ICE clock to TURBO\n");
> +
> return 0;
> }
>
> @@ -1989,6 +1996,16 @@ static int sdhci_msm_ice_suspend(struct sdhci_msm_host *msm_host)
> return 0;
> }
>
> +static int sdhci_msm_ice_scale_clk(struct sdhci_msm_host *msm_host,
> + unsigned long target_freq,
> + bool round_ceil)
> +{
> + if (msm_host->mmc->caps2 & MMC_CAP2_CRYPTO)
> + return qcom_ice_scale_clk(msm_host->ice, target_freq, round_ceil);
> +
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH v7 0/3] Mediatek MT8189 JPEG support
From: Nicolas Dufresne @ 2026-04-17 13:30 UTC (permalink / raw)
To: Jianhua Lin, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu
In-Reply-To: <20260417100519.1043-1-jianhua.lin@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 3866 bytes --]
Hi,
Le vendredi 17 avril 2026 à 18:05 +0800, Jianhua Lin a écrit :
> This series is based on tag: next-20260410, linux-next/master
What dependencies justify not submitting based on media-committers/next as usual
? Its fine to say you tested against linux-next of course, and if its only
working there, its really nice to explain why.
Nicolas
>
> Changes compared with v6:
> - Patches 1/3 (dt-bindings: decoder):
> update the existing `allOf` condition for mediatek,mt8189-jpgdec to
> make the 'mediatek,larb' property strictly required for MT8189 SoC.
> - Patches 2/3 (dt-bindings: encoder):
> Add an `allOf` condition to enforce that the `mediatek,larb` property
> is strictly required when the compatible string contains
> mediatek,mt8189-jpgenc.
>
> Changes compared with v5:
> - Patches 1/3 (dt-bindings: decoder):
> - Drop top-level minItems/maxItems for clock-names per Krzysztof's
> review.
> - Refine allOf block to strictly enforce clock constraints.
>
> Changes compared with v4:
> - Refines the device tree bindings for JPEG decoder and encoder.
> - Patches 1/3 (dt-bindings: decoder):
> Moved the standalone compatible string mediatek,mt8189-jpgdec
> into the first oneOf entry along with mt2701 and mt8173, as
> suggested by Rob Herring. This correctly groups all independent
> ICs and removes the redundant items wrapper.
> - Patches 2/3 (dt-bindings: encoder):
> Applied the same logic suggested by Rob Herring to the encoder
> binding. Restructured the compatible property to clearly
> distinguish between the standalone IC (mediatek,mt8189-jpgenc)
> and the ICs that must fallback to mediatek,mtk-jpgenc.
>
> Changes compared with v3:
> - The v4 is resending the cover-letter, because the v3 cover-letter was
> not sent successfully.
>
> Changes compared with v2:
> - Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
> compatible) as it belongs to a different tree/series.
> - Patches 1/3 (dt-bindings: decoder):
> - Changed the MT8189 compatible to be a standalone `const` instead of
> an `enum`.
> - Added an `allOf` block with conditional checks to enforce the single
> clock ("jpgdec") requirement for MT8189, while preserving the
> two-clock requirement for older SoCs.
> - Updated commit message to reflect the schema structure changes and
> hardware differences.
> - Patches 2/3 (dt-bindings: encoder):
> - Changed the MT8189 compatible to be a standalone `const` instead of
> an `enum` inside the `items` list, as it does not fallback to
> "mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
> - Updated commit message to explain the standalone compatible design.
> - Patches 3/3 (media: mediatek: jpeg):
> - Refined commit message for better clarity regarding 34-bit IOVA and
> single clock configuration.
>
> Changes compared with v1:
> - Patches 1/4:
> - Updating commit message
> - Patches 2/4, 3/4:
> - Updating commit message
> - Adjusted property descriptions acorrding to hardware requirements
> - Improved formatting for better readability and consistency
> - Patches 4/4:
> - Updating commit message
>
> Jianhua Lin (3):
> dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
> string
> dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
> string
> media: mediatek: jpeg: add compatible for MT8189 SoC
>
> .../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
> .../bindings/media/mediatek-jpeg-encoder.yaml | 29 ++++++++---
> .../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++
> 3 files changed, 107 insertions(+), 14 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v8 2/5] ufs: host: Add ICE clock scaling during UFS clock changes
From: Harshal Dev @ 2026-04-17 13:32 UTC (permalink / raw)
To: Abhinaba Rakshit, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Adrian Hunter, Ulf Hansson, Neeraj Soni, Kuldeep Singh,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <20260409-enable-ice-clock-scaling-v8-2-ca1129798606@oss.qualcomm.com>
On 4/9/2026 5:14 PM, Abhinaba Rakshit wrote:
> Implement ICE (Inline Crypto Engine) clock scaling in sync with
> UFS controller clock scaling. This ensures that the ICE operates at
> an appropriate frequency when the UFS clocks are scaled up or down,
> improving performance and maintaining stability for crypto operations.
>
> For scale_up operation ensure to pass ~round_ceil (round_floor)
> and vice-versa for scale_down operations.
>
> Incase of OPP scaling is not supported by ICE, ensure to not prevent
> devfreq for UFS, as ICE OPP-table is optional.
>
> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
Whoops, I mistakenly replied to v7 of this patch with a Reviewed-by, please
ignore that one.
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Regards,
Harshal
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: Harshal Dev @ 2026-04-17 13:38 UTC (permalink / raw)
To: Konrad Dybcio, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov, johannes.goede
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <82e0d347-9ac9-497c-bc67-0db9206c5dd2@oss.qualcomm.com>
On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
> On 4/17/26 11:22 AM, Harshal Dev wrote:
>> Hi,
>>
>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>> SM8x50 platforms.
>>>>
>>>> Describe the crypto engine and its BAM.
>>>>
>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>> 1 file changed, 26 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>> status = "disabled";
>>>> };
>>>>
>>>> + cryptobam: dma-controller@1dc4000 {
>>>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>> + #dma-cells = <1>;
>>>> + iommus = <&apps_smmu 0x480 0x0>,
>>>> + <&apps_smmu 0x481 0x0>;
>>>
>>> It seems like these aren't the right SIDs on this platform.. Have you
>>> tested this patch on hw?
>>
>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>> (I hope I don't need to pad them?)
>
> No, you don't
Ack.
>
>>
>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>
>> [ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>
>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>> SIDs and wait for a Tested-by from him.
>
> Thanks
>
> I think you should be able to get some life out of the crypto engine
> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
> mentioned reports a failure on Hamoa)
Sure, I'll try this, could you also point me to the bug report?
Regards,
Harshal
>
> Konrad
^ permalink raw reply
* [PATCH v2] dt-bindings: iio: dac: mcp47feb02: Fix maxItems value for reg property
From: Ariana Lazar @ 2026-04-17 13:38 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Conor Dooley, Jonathan Cameron, linux-iio, devicetree,
linux-kernel, Ariana Lazar
Change maxItems value from 8 to 1 for the channel number reg property.
Fixes: 4ba12d304175 ("dt-bindings: iio: dac: adding support for Microchip MCP47FEB02")
Link: https://lore.kernel.org/all/20260403-speed-childless-1360de358229@spud/
Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
---
Changes in v2:
- keep just maxItems value update in this patch
- remove Reported-by from commit message
- Link to v1: https://lore.kernel.org/r/20260416-mcp47feb02-fix5-v1-1-9656c2fed6d2@microchip.com
---
Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
index d2466aa6bda2106a8b695347a0edf38462294d03..f2efa0ccbaa32482dcdc69d98c1565518538793f 100644
--- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
@@ -161,8 +161,7 @@ patternProperties:
properties:
reg:
description: The channel number.
- minItems: 1
- maxItems: 8
+ maxItems: 1
label:
description: Unique name to identify which channel this is.
---
base-commit: d2a4ec19d2a2e54c23b5180e939994d3da4a6b91
change-id: 20260416-mcp47feb02-fix5-26994c5b428c
Best regards,
--
Ariana Lazar <ariana.lazar@microchip.com>
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: johannes.goede @ 2026-04-17 14:30 UTC (permalink / raw)
To: Harshal Dev, Konrad Dybcio, Thara Gopinath, Herbert Xu,
David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <0d5bf2bd-b90c-4814-bd2e-126a9bcb82ce@oss.qualcomm.com>
Hi,
On 17-Apr-26 15:38, Harshal Dev wrote:
>
>
> On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
>> On 4/17/26 11:22 AM, Harshal Dev wrote:
>>> Hi,
>>>
>>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>>> SM8x50 platforms.
>>>>>
>>>>> Describe the crypto engine and its BAM.
>>>>>
>>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>>> 1 file changed, 26 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + cryptobam: dma-controller@1dc4000 {
>>>>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>>> + #dma-cells = <1>;
>>>>> + iommus = <&apps_smmu 0x480 0x0>,
>>>>> + <&apps_smmu 0x481 0x0>;
>>>>
>>>> It seems like these aren't the right SIDs on this platform.. Have you
>>>> tested this patch on hw?
>>>
>>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>>> (I hope I don't need to pad them?)
>>
>> No, you don't
>
> Ack.
>
>>
>>>
>>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>>
>>> [ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>>
>>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>>> SIDs and wait for a Tested-by from him.
>>
>> Thanks
>>
>> I think you should be able to get some life out of the crypto engine
>> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
>> mentioned reports a failure on Hamoa)
>
> Sure, I'll try this, could you also point me to the bug report?
No bug report yet, I was asking around internally who I should
talk to about his.
I'm seeing 7.0-rc# QCE crypto selftest failures on a Lenovo ThinkPad
T14s gen 6 (Hamoa x1e78100):
[ 1.357020] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
[ 1.369951] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)"
[ 1.443143] alg: aead: rfc4309-ccm-aes-qce decryption failed on test vector 1; expected_error=0, actual_error=-6, cfg="misaligned splits crossing pages, inplace"
This is with manually compiled 7.0-rc# using Fedora's default kernel
config which includes: CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y
with the latter being hidden behind CONFIG_EXPERT for some reason.
This is a regression compared to 6.19.y where CONFIG_CRYPTO_SELFTESTS=y
is also enabled by Fedora and it works fine.
I've not looked further into this yet, other then a message to fellow
OSTT team arm64-laptop users asking for tips / whom to report this to.
I would be happy to send create a kernel.bugzilla.org bug-report
about this to, or report to email somewhere, or ...
Please let met know where you want a bug-report to be filed and
also what information to add on top of the above info ?
E.g. these failures trigger a WARN() and thus log a backtrace,
do you want those backtraces and if yes I presume I should run
them through addr2line ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 14:35 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu,
stable
In-Reply-To: <fe1e2ef2-dece-4864-a89b-a311b3ddbfcc@oss.qualcomm.com>
On 4/14/2026 2:59 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
> Should we write a zero there, then?
zero being the reset value for that register, I would prefer avoiding to
write unless needed.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-17 14:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Krzysztof Kozlowski, kuninori.morimoto.gx, broonie, lgirdwood,
robh, krzk+dt, conor+dt, geert+renesas, magnus.damm, perex, tiwai,
linux-sound, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <CAMuHMdXie1HR6XzkHXAtonh2oemNxH2UZE3uSUjW3xoOmhRjYQ@mail.gmail.com>
Hi Geert,
> It is the main clock that needs to be enabled to make the device
> function. This is independent from the notion of it being a
> "Module Stop Clock" or not, and became sort of a convention.
> Correct. On most (all?) Renesas SoCs, devices are part of a clock
> domain, and their functional clocks are managed by Runtime PM.
> It is not strictly needed to be the first clock, and mostly a relic of the past,
> when clocks weren't accessed by name, but by index.
> Also, many devices have only a single clock, so don't need a name.
Thank you for the clarification. It was very helpful and cleared up my
confusion about the clock naming and ordering.
I really appreciate your support.
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH v3 6/6] riscv: dts: microchip: add pinctrl nodes for mpfs/icicle kit
From: Conor Dooley @ 2026-04-17 14:51 UTC (permalink / raw)
To: linusw
Cc: Conor Dooley, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
linux-kernel, linux-gpio, devicetree, Valentina.FernandezAlanis
In-Reply-To: <20260119-natural-buddy-acb391bcd9f6@spud>
[-- Attachment #1: Type: text/plain, Size: 3003 bytes --]
On Mon, Jan 19, 2026 at 11:03:57AM +0000, Conor Dooley wrote:
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_fabric>;
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_fabric>;
> +};
Seemingly, I have run into an erratum here. What I noticed that this
didn't match the schematic and changed it when I applied. Turns out,
this is actually correct on engineering sample silicon but not on
production. Something like
diff --git a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi
index 2d14e92f068d5..9078e5b1e49c1 100644
--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi
+++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi
@@ -101,16 +101,6 @@ &ccc_nw {
status = "okay";
};
-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_fabric>;
-};
-
-&i2c1 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c1_mssio>;
-};
-
&mmuart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_fabric>;
diff --git a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-prod.dts b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-prod.dts
index 8afedece89d1f..636493f6584d2 100644
--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-prod.dts
+++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-prod.dts
@@ -14,6 +14,16 @@ / {
"microchip,mpfs";
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_fabric>;
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_mssio>;
+};
+
&syscontroller {
microchip,bitstream-flash = <&sys_ctrl_flash>;
};
diff --git a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
index 556aa9638282e..6fadce815c9a2 100644
--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
+++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
@@ -11,3 +11,22 @@ / {
"microchip,mpfs-icicle-kit",
"microchip,mpfs";
};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_fabric>;
+};
+
+/*
+ * Due to silicon errata, routing via MSS IOs doesn't work on ES devices.
+ * Instead, i2c1, appearing on B1/C1, which are normally MSS IOs, is routed
+ * via the fabric and back to B1/C1 via "fabric-test" functionality.
+ * This is done silently by Libero, so the iomux0 setting for i2c1 has to
+ * be fabric IO, despite tooling etc saying that MSS IOs are used.
+ *
+ * See Section 3.3 of https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/Errata/polarfiresoc/microsemi_polarfire_soc_fpga_egineering_samples_errata_er0219_v1.pdf
+ */
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_fabric>;
+};
is needed to restore functionality and a further change is required to
"document" in code the extent of the hack required to make it work.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* Re: [net-next v2 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Andrew Lunn @ 2026-04-17 14:54 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260417024523.107786-2-minda.chen@starfivetech.com>
On Fri, Apr 17, 2026 at 10:45:19AM +0800, Minda Chen wrote:
> Remove JH8100 dt-bindings because do not support it now.
> StarFive have stopped JH8100 developing and will release it
> outside.
Is there a missing "not" in that sentence?
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 02/11] media: iris: Add iris vpu bus support and register it with iommu_buses
From: Vishnu Reddy @ 2026-04-17 14:59 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <5dee6da0-9170-d9e0-5ff7-f8436331c6a9@oss.qualcomm.com>
apologies for re-sending (earlier responses was rejected due to HTML format)
On 4/17/2026 8:22 PM, Vishnu Reddy wrote:
> On 4/14/2026 8:44 PM, Dmitry Baryshkov wrote:
>> On Tue, Apr 14, 2026 at 10:29:58AM +0530, Vishnu Reddy wrote:
>>> From: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>>
>>> Add a dedicated iris VPU bus type and register it into the iommu_buses
>>> list. Iris devices require their own bus so that each device can run its
>>> own dma_configure() logic.
>> This really tells nothing, unless one has full context about the Iris
>> needs. Start by describing the issue (that the device needs to have
>> multiple devices talking to describe IOMMUs / VAs for several hardware
>> functions), then continue by describing what is needed from the IOMMU
>> subsys.
>
> This series handles firmware device which do not require multiple
> devices part.
> given this device need for specific IOMMU configuration, I'll update
> the description
> accordingly.
>
>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>>> ---
>>> drivers/iommu/iommu.c | 4 ++++
>>> drivers/media/platform/qcom/iris/Makefile | 4 ++++
>>> drivers/media/platform/qcom/iris/iris_vpu_bus.c | 32 +++++++++++++++++++++++++
>>> include/linux/iris_vpu_bus.h | 13 ++++++++++
>> How are you supposed to merge this? Through IOMMU tree? Through venus
>> tree? Can we add one single bus to the IOMMU code and use it for Iris,
>> Venus, FastRPC, host1x and all other device drivers which require
>> per-device DMA configuration?
>
> Separating out the bus definition and the Iris driver handling would
> provide a
> cleaner merge path.
>
>> Your colleagues from the FastRPC team posted a very similar code few
>> weeks ago and got exactly the same feedback. Is there a reason why your
>> teams don't sync on the IOMMU parts at all?
>
> I would admit that I missed to review that, thank you for bringing
> that discussion.
> FastRPC patches generalizes the handling for host1x, FastRPC and the
> same can be
> extended for Iris. I have left few comments there.
>
>>> 4 files changed, 53 insertions(+)
>>>
>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>> index 61c12ba78206..d8ed6ef70ecd 100644
>>> --- a/drivers/iommu/iommu.c
>>> +++ b/drivers/iommu/iommu.c
>>> @@ -13,6 +13,7 @@
>>> #include <linux/bug.h>
>>> #include <linux/types.h>
>>> #include <linux/init.h>
>>> +#include <linux/iris_vpu_bus.h>
>>> #include <linux/export.h>
>>> #include <linux/slab.h>
>>> #include <linux/errno.h>
>>> @@ -179,6 +180,9 @@ static const struct bus_type * const iommu_buses[] = {
>>> #ifdef CONFIG_CDX_BUS
>>> &cdx_bus_type,
>>> #endif
>>> +#if IS_ENABLED(CONFIG_VIDEO_QCOM_IRIS)
>>> + &iris_vpu_bus_type,
>>> +#endif
>>> };
>>>
>>> /*
>>> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
>>> index 2abbd3aeb4af..6f4052b98491 100644
>>> --- a/drivers/media/platform/qcom/iris/Makefile
>>> +++ b/drivers/media/platform/qcom/iris/Makefile
>>> @@ -31,3 +31,7 @@ qcom-iris-objs += iris_platform_gen1.o
>>> endif
>>>
>>> obj-$(CONFIG_VIDEO_QCOM_IRIS) += qcom-iris.o
>>> +
>>> +ifdef CONFIG_VIDEO_QCOM_IRIS
>>> +obj-y += iris_vpu_bus.o
>>> +endif
>>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_bus.c b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
>>> new file mode 100644
>>> index 000000000000..b51bb4b82b0e
>>> --- /dev/null
>>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
>>> @@ -0,0 +1,32 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>>> + */
>>> +
>>> +#include <linux/device.h>
>>> +#include <linux/of_device.h>
>>> +
>>> +#include "iris_platform_common.h"
>>> +
>>> +static int iris_vpu_bus_dma_configure(struct device *dev)
>>> +{
>>> + const u32 *f_id = dev_get_drvdata(dev);
>>> +
>>> + if (!f_id)
>>> + return -ENODEV;
>>> +
>>> + return of_dma_configure_id(dev, dev->parent->of_node, true, f_id);
>> I think it was discussed that this is not enough. Some of devices need
>> multiple function IDs.
>
> In this glymur series we are following the legacy way of handling
> IOMMUs and does not
> require multi map.
>
> Thanks,
> Vishnu Reddy.
>
>>> +}
>>> +
>>> +const struct bus_type iris_vpu_bus_type = {
>>> + .name = "iris-vpu-bus",
>>> + .dma_configure = iris_vpu_bus_dma_configure,
>>> +};
>>> +EXPORT_SYMBOL_GPL(iris_vpu_bus_type);
>>> +
>>> +static int __init iris_vpu_bus_init(void)
>>> +{
>>> + return bus_register(&iris_vpu_bus_type);
>>> +}
>>> +
>>> +postcore_initcall(iris_vpu_bus_init);
>>> diff --git a/include/linux/iris_vpu_bus.h b/include/linux/iris_vpu_bus.h
>>> new file mode 100644
>>> index 000000000000..5704b226f7d6
>>> --- /dev/null
>>> +++ b/include/linux/iris_vpu_bus.h
>>> @@ -0,0 +1,13 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>>> + */
>>> +
>>> +#ifndef __IRIS_VPU_BUS_H__
>>> +#define __IRIS_VPU_BUS_H__
>>> +
>>> +#if IS_ENABLED(CONFIG_VIDEO_QCOM_IRIS)
>>> +extern const struct bus_type iris_vpu_bus_type;
>>> +#endif
>>> +
>>> +#endif /* __IRIS_VPU_BUS_H__ */
>>>
>>> --
>>> 2.34.1
>>>
^ permalink raw reply
* Re: [PATCH 03/11] media: iris: Add context bank hooks for platform specific initialization
From: Vishnu Reddy @ 2026-04-17 15:03 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <3vuensoscjzsjuh7c5e3jff5cej66iwboiau7vhnpvtmqevexf@ouox5cize3fn>
On 4/14/2026 8:46 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:29:59AM +0530, Vishnu Reddy wrote:
>> Add init and deinit hooks in the platform data for context bank setup.
>> These hooks allow platform specific code to initialize and tear down
>> context banks.
>>
>> The Glymur platform requires a dedicated firmware context bank device
>> which is mapped to the firmware stream ID to load the firmware.
> Change the order of paragraphs. You should start with the definition of
> the problem rather than putting the cart before the horse and starting
> from the solution.
Ack.
Thanks,
Vishnu Reddy.
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> .../platform/qcom/iris/iris_platform_common.h | 2 ++
>> drivers/media/platform/qcom/iris/iris_probe.c | 23 +++++++++++++++++++++-
>> 2 files changed, 24 insertions(+), 1 deletion(-)
>>
^ permalink raw reply
* [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
Dear all,
Need the help of the collective wisdom of the community.
The problem I'm trying to solve is reliably obtaining the exact pixel
clock for arbitrary display modes supported by the RK3576 SoC.
Rockchip RK3576 has three display output processors VP0~VP2, each
supporting different ranges of display modes, roughly as follows:
- VP0: 4K 120Hz
- VP1: 2.5k 60Hz
- VP2: 1080p 60Hz
Each one obviously needs a pixel clock. The required frequencies for the
pixel clocks vary greatly depending on the display mode, and need to be
matched within a tight tolerance, or else many displays will refuse to
work. E.g. the preferred (maximum) display mode out of VP1 is particularly
awkward, because it requires a pixel clock of 248.88 MHz, which cannot
be obtained using integer dividers from its default clock source (GPLL
at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
outside the tolerance of e.g. DP specification, resulting in a blank
screen on most displays by default.
The clock sources are of course configurable, in particular there are muxes
connected to each VP for selecting the source of the pixel clock:
- Each VP can take the clock either from the (single!) HDMI PHY or from
its dedicated dclk_vpX_src mux
- The dclk_vpX_src mux can select the clock from a number of system PLLs
(GPLL, CPLL, VPLL, BPLL, LPLL)
While the system PLLs can be configured to output a wide range of
frequencies, they are shared between many system components. E.g. on the
current mainline kernel on one of my RK3576 boards I've got the following:
GPLL: 1188 MHz, enable count 20
CPLL: 1000 MHz, enable count 17
VPLL: 594 MHz, enable count 0 (yaay!)
BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
predividers, so are less flexible)
So ultimately there is exactly one free fractional PLL (VPLL) which can be
used to generate arbitrary pixel clocks, but we have up to three consumers
trying to drive different display modes from it (e.g. HDMI on VP0, DP on
VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
frequency on the fly to satisfy the requirements of the selected display
mode.
And this is where I'm stuck. Trying to satisfy the requirements of up to
three consumers while changing the PLL frequency on the fly sounds like
a poorly tractable mathematical problem (is it 3-SAT?). We can take the
HDMI output out of the equation, because it can be driven from the HDMI
PHY (which is capable of arbitrary rates) instead of the mux, but that
makes the decision of which dclk source to use for a VP block dependent on
which downstream consumer is connected to it (HDMI vs. something else).
Even then we somehow need two devices to cooperate in picking a PLL
frequency that satisfies the requirements of both of them, and change to it
without display corruption. I'm not even sure if the CCF has mechanisms
for that?..
What follows is a brief set of patches which illustrate a partial solution
for the case of "I just need 2.5k60Hz on VP1 via DP and don't care about
the rest". It switches the VP1 unconditionally to use VPLL as the source
for its dclk mux, allows changing the VPLL frequency on the fly, and also
changes the frequency calculation logic to allow for nearest-match
frequencies which are not necessarily rounded down. These are not meant
to be merged as-is, as I see the following issues:
- The flag allowing the PLL to change rate is in the clock driver, while
the reparenting to an unused PLL is in the device tree. If these go out
of sync, we might end up trying to change the frequency of a PLL which
is used by other consumers (I presume that could be dangerous)
- If VP0 happens to be driving DP output, it won't be able to produce the
2560x1440@60Hz mode for the same reasons as VP1 - then it must also be
reparented to VPLL and allowed to change its frequency on the fly
It does bring me from a state of "always blank screen on DP output until
the mode is switched to something magically working" to a state of
"most monitors work at the default preferred mode" though.
It is tempting to just reparent both VP0 and VP1 to VPLL and allow both of
them to change its frequency, while leaving VP2 on the default (fixed)
GPLL and relying on the fact that 148.5 MHz (the required frequency for
its maximum supported mode of 1920x1080@60Hz) is conveniently 1188/8 MHz -
just what GPLL can provide. Then also force whichever VP is driving HDMI
output to use the HDMI PHY as its clock source. But we still have the
problem of DT vs. driver coordination, and I'm not sure how to define
the policy for "if you've got HDMI connected, you must use the HDMI PHY
clock for the respective VP, whichever VP that is".
I would very much appreciate any thoughts on how to approach this.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Alexey Charkov (4):
arm64: dts: rockchip: rk3576: assign dclk_vp1_src to VPLL
clk: rockchip: pll: use round-nearest in determine_rate
clk: rockchip: rk3576: allow dclk_vp1_src to propagate rate to parent PLL
clk: rockchip: rk3576: add ROUND_CLOSEST to dclk_vp1_src divider
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 2 ++
drivers/clk/rockchip/clk-pll.c | 16 ++++++++--------
drivers/clk/rockchip/clk-rk3576.c | 4 ++--
3 files changed, 12 insertions(+), 10 deletions(-)
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20260417-rk3576-dclk-4c95bbb67581
Best regards,
--
Alexey Charkov <alchark@flipper.net>
^ permalink raw reply
* [PATCH RFC 1/4] arm64: dts: rockchip: rk3576: assign dclk_vp1_src to VPLL
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
Reparent dclk_vp1_src from GPLL to VPLL at the SoC level. VPLL is a
programmable PLL with no other consumers, allowing the CRU to synthesize
accurate pixel clocks for VP1's output with arbitrary display modes.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
index e12a2a0cfb89..2b05900c6c1c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
@@ -1338,6 +1338,8 @@ vop: vop@27d00000 {
"dclk_vp1",
"dclk_vp2",
"pll_hdmiphy0";
+ assigned-clocks = <&cru DCLK_VP1_SRC>;
+ assigned-clock-parents = <&cru PLL_VPLL>;
iommus = <&vop_mmu>;
power-domains = <&power RK3576_PD_VOP>;
rockchip,grf = <&sys_grf>;
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 2/4] clk: rockchip: pll: use round-nearest in determine_rate
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
rockchip_pll_determine_rate() walks the rate table in descending order
and picks the first entry <= the requested rate. This floor-rounding
interacts poorly with consumers that use CLK_SET_RATE_PARENT: a divider
iterating candidates asks the PLL for rate*div, and a tiny undershoot
causes the PLL to snap to a much lower entry.
For example, requesting 1991.04 MHz (248.88 MHz * 8) causes the PLL to
return 1968 MHz instead of 1992 MHz — a 24 MHz table gap that produces
a 1.2% pixel clock error when divided back down.
Change to round-to-nearest: for each table entry compute the absolute
distance from the request, and pick the entry with the smallest delta.
The CCF's divider and composite logic handle over/undershoot preferences
via their own ROUND_CLOSEST flags.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-pll.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6b853800cb6b..c142f2c4fd99 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -66,19 +66,19 @@ static int rockchip_pll_determine_rate(struct clk_hw *hw,
{
struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
const struct rockchip_pll_rate_table *rate_table = pll->rate_table;
+ unsigned long best = 0;
int i;
- /* Assuming rate_table is in descending order */
for (i = 0; i < pll->rate_count; i++) {
- if (req->rate >= rate_table[i].rate) {
- req->rate = rate_table[i].rate;
-
- return 0;
- }
+ if (abs((long)req->rate - (long)rate_table[i].rate) <
+ abs((long)req->rate - (long)best))
+ best = rate_table[i].rate;
}
- /* return minimum supported value */
- req->rate = rate_table[i - 1].rate;
+ if (best)
+ req->rate = best;
+ else
+ req->rate = rate_table[pll->rate_count - 1].rate;
return 0;
}
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 3/4] clk: rockchip: rk3576: allow dclk_vp1_src to propagate rate to parent PLL
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
dclk_vp1_src feeds the display clock for Video Port 1. When parented to
the default GPLL (1188 MHz), the 8-bit divider cannot synthesize the
248.88 MHz pixel clock required for 2560x1440@60 which VP1 supports:
1188 / 5 = 237.6 MHz (-4.53% error). This exceeds DisplayPort's +/-0.5%
tolerance and causes black screens on strict sinks.
Add CLK_SET_RATE_PARENT so that when dclk_vp1_src is reparented to a
programmable PLL (e.g. VPLL via assigned-clock-parents), the CCF divider
can ask the PLL to retune. For example, VPLL at 1992 MHz / 8 = 249 MHz
(0.048% error).
This flag relies on reparenting the VP1 source clock to VPLL at DT level
to ensure no consumer calls clk_set_rate on dclk_vp1 while its parent is
set to the boot-time default of GPLL.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-rk3576.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3576.c b/drivers/clk/rockchip/clk-rk3576.c
index 2557358e0b9d..28eb5a802e83 100644
--- a/drivers/clk/rockchip/clk-rk3576.c
+++ b/drivers/clk/rockchip/clk-rk3576.c
@@ -1105,7 +1105,7 @@ static struct rockchip_clk_branch rk3576_clk_branches[] __initdata = {
COMPOSITE(DCLK_VP0_SRC, "dclk_vp0_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
RK3576_CLKSEL_CON(145), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 10, GFLAGS),
- COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
+ COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 11, GFLAGS),
COMPOSITE(DCLK_VP2_SRC, "dclk_vp2_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 4/4] clk: rockchip: rk3576: add ROUND_CLOSEST to dclk_vp1_src divider
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
Without CLK_DIVIDER_ROUND_CLOSEST, the divider's _is_best_div() only
considers candidates where now <= target, rejecting any rate above the
target even when it is closer. Combined with the PLL round-nearest fix,
this causes the divider to still pick a suboptimal rate: with PLL
round-nearest alone, div=8 produces 249.0 MHz (0.048% over) but is
rejected because it exceeds the target, and div=3/248.0 MHz wins
(-0.354% error).
Add CLK_DIVIDER_ROUND_CLOSEST to dclk_vp1_src's div_flags so the
divider picks the rate closest to the target regardless of direction.
Together with the PLL round-nearest change, this yields:
VPLL 1992 MHz / 8 = 249.0 MHz (+0.048% error)
instead of the previous:
VPLL 1488 MHz / 6 = 248.0 MHz (-0.354% error)
This small difference appears to enable more monitors to lock to the VP1
clock when driving output at 2560x1440@60Hz via DisplayPort.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-rk3576.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3576.c b/drivers/clk/rockchip/clk-rk3576.c
index 28eb5a802e83..9fc3264ef322 100644
--- a/drivers/clk/rockchip/clk-rk3576.c
+++ b/drivers/clk/rockchip/clk-rk3576.c
@@ -1106,7 +1106,7 @@ static struct rockchip_clk_branch rk3576_clk_branches[] __initdata = {
RK3576_CLKSEL_CON(145), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 10, GFLAGS),
COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
- RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS,
+ RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS | CLK_DIVIDER_ROUND_CLOSEST,
RK3576_CLKGATE_CON(61), 11, GFLAGS),
COMPOSITE(DCLK_VP2_SRC, "dclk_vp2_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
RK3576_CLKSEL_CON(147), 8, 3, MFLAGS, 0, 8, DFLAGS,
--
2.52.0
^ permalink raw reply related
* Re: Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Conor Dooley @ 2026-04-17 15:13 UTC (permalink / raw)
To: Xuyang Dong
Cc: Krzysztof Kozlowski, ukleinek, robh, krzk+dt, conor+dt, ben-linux,
ben.dooks, p.zabel, linux-pwm, devicetree, linux-kernel, ningyu,
linmin, xuxiang, wangguosheng, pinkesh.vaghela
In-Reply-To: <3b2e80d5.55a5.19d996c6821.Coremail.dongxuyang@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
On Fri, Apr 17, 2026 at 11:11:51AM +0800, Xuyang Dong wrote:
> > > > > >
> > > > > > The DesignWare PWM includes separate reset signals dedicated to each clock
> > > > > > domain:
> > > > > > The presetn signal resets logic in pclk domain.
> > > > > > The timer_N_resetn signal resets logic in the timer_N_clk domain.
> > > > > > The resets are active-low.
> > > > > >
> > > > > > Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> > > > >
> > > > > This commit implies that your hardware differs from existing devices,
> > > > > I think you should add a device-specific compatible.
> > > > >
> > >
> > > Hi Conor and Krzysztof,
> > >
> > > The DesignWare PWM Databook for 2.13a says: "The DW_apb_timers includes
> > > separate reset signals dedicated to each clock domain". They are:
> > > The presetn signal resets logic in pclk domain (i.e., the bus clock in DT).
> > > The timer_N_resetn signal resets logic in the timer_N_clk domain (i.e.,
> > > the timer clock in DT).
> > >
> > > These reset signals are optional; it is up to the designer's
> > > implementation.
> >
> > Right, and it's that "designer's implementation" that warrants a
> > device-specific compatible.
> >
>
> Hi Conor,
>
> The YAML update for the new device-specific compatible is as follows:
>
> properties:
> compatible:
> oneOf:
> - const: snps,dw-apb-timers-pwm2
> - items:
> - enum:
> - snps,dw-apb-timers-pwm-2.13a
This is not a device-specific compatible.
Hint: device-specific means it needs to start with "eswin,eic7700" (and
probably end with "-pwm".
> - const: snps,dw-apb-timers-pwm2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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