* [PATCH 3/3] arm64: tegra: Correct Tegra234 p3740 interrupt flags
From: Krzysztof Kozlowski @ 2026-04-06 6:49 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, devicetree, linux-tegra, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260406064935.27968-4-krzysztof.kozlowski@oss.qualcomm.com>
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5540 codec driver requests interrupt on rising edge, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dts b/arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dts
index 9ce55b4d2de8..97cede1fcb70 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dts
@@ -75,7 +75,7 @@ rt5640: audio-codec@1c {
compatible = "realtek,rt5640";
reg = <0x1c>;
interrupt-parent = <&gpio>;
- interrupts = <TEGRA234_MAIN_GPIO(F, 3) GPIO_ACTIVE_HIGH>;
+ interrupts = <TEGRA234_MAIN_GPIO(F, 3) IRQ_TYPE_EDGE_RISING>;
clocks = <&bpmp TEGRA234_CLK_AUD_MCLK>;
clock-names = "mclk";
--
2.51.0
^ permalink raw reply related
* [PATCH 2/3] arm64: tegra: Correct Tegra234 p3737 interrupt flags
From: Krzysztof Kozlowski @ 2026-04-06 6:49 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, devicetree, linux-tegra, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260406064935.27968-4-krzysztof.kozlowski@oss.qualcomm.com>
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5540 codec driver requests interrupt on rising edge, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701.dtsi b/arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701.dtsi
index f6cad29355e6..420858a8f4a8 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701.dtsi
@@ -67,7 +67,7 @@ audio-codec@1c {
compatible = "realtek,rt5640";
reg = <0x1c>;
interrupt-parent = <&gpio>;
- interrupts = <TEGRA234_MAIN_GPIO(AC, 5) GPIO_ACTIVE_HIGH>;
+ interrupts = <TEGRA234_MAIN_GPIO(AC, 5) IRQ_TYPE_EDGE_RISING>;
clocks = <&bpmp TEGRA234_CLK_AUD_MCLK>;
clock-names = "mclk";
realtek,dmic1-data-pin = <RT5640_DMIC1_DATA_PIN_NONE>;
--
2.51.0
^ permalink raw reply related
* [PATCH 1/3] arm64: tegra: Correct Tegra194 p2972 interrupt flags
From: Krzysztof Kozlowski @ 2026-04-06 6:49 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, devicetree, linux-tegra, linux-kernel
Cc: Krzysztof Kozlowski
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5658 codec driver requests interrupt on both edges, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
index ea6f397a2792..5462200f1176 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
@@ -2170,7 +2170,7 @@ rt5658: audio-codec@1a {
compatible = "realtek,rt5658";
reg = <0x1a>;
interrupt-parent = <&gpio>;
- interrupts = <TEGRA194_MAIN_GPIO(S, 5) GPIO_ACTIVE_HIGH>;
+ interrupts = <TEGRA194_MAIN_GPIO(S, 5) IRQ_TYPE_EDGE_RISING>;
clocks = <&bpmp TEGRA194_CLK_AUD_MCLK>;
clock-names = "mclk";
realtek,jd-src = <2>;
--
2.51.0
^ permalink raw reply related
* [PATCH] arm64: tegra: Enable interconnect for MC and EMC on Tegra210
From: Aaron Kling via B4 Relay @ 2026-04-06 6:39 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter
Cc: Thierry Reding, devicetree, linux-tegra, linux-kernel,
Aaron Kling
From: Aaron Kling <webgeek1234@gmail.com>
These are being referenced by actmon, but are not currently enabled.
Fixes: 654427e0b9b7 ("arm64: tegra: Add OPP tables on Tegra210")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
When the opp tables were added to tegra210 [0], there was a previous
commit [1] that enabled interconnect on the mc and emc nodes. This was
later reverted [2] because some setups such as the Nvidia regression
test bench do not pass emc training data and thus the emc driver cannot
probe. Since interconnects cannot be optionally routed, the dc
interconnect routes cannot be enabled if the kernel is to support
bootloader setups that do not properly pass emc training data. Thus this
only fixes the routes enough for actmon to operate, because actmon
failing to probe is no more fatal than an emc failure.
This depends on the mc/emc driver patch to add interconnect support [3],
which should be merged first.
[0] https://lore.kernel.org/linux-tegra/20251021-t210-actmon-p4-v5-3-4a4dbc49fbc8@gmail.com/
[1] https://lore.kernel.org/linux-tegra/20251021-t210-actmon-p4-v5-2-4a4dbc49fbc8@gmail.com/
[2] https://lore.kernel.org/linux-tegra/20251217104744.184153-1-jonathanh@nvidia.com/
[3] https://lore.kernel.org/linux-tegra/20260406-t210-actmon-p2-v7-1-91adf535cf8f@gmail.com/
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 5f5e5370d70966918943232acab8992bf91ec42a..a5537a5c472c4bf5d649cc52372e531452b594f7 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -1028,6 +1028,7 @@ mc: memory-controller@70019000 {
#iommu-cells = <1>;
#reset-cells = <1>;
+ #interconnect-cells = <1>;
};
emc: external-memory-controller@7001b000 {
@@ -1041,6 +1042,7 @@ emc: external-memory-controller@7001b000 {
nvidia,memory-controller = <&mc>;
operating-points-v2 = <&emc_icc_dvfs_opp_table>;
+ #interconnect-cells = <0>;
#cooling-cells = <2>;
};
---
base-commit: 2febe6e6ee6e34c7754eff3c4d81aa7b0dcb7979
change-id: 20260405-tegra210-actmon-dt-fixup-690c74952299
Best regards,
--
Aaron Kling <webgeek1234@gmail.com>
^ permalink raw reply related
* [PATCH v7] memory: tegra210: Support interconnect framework
From: Aaron Kling via B4 Relay @ 2026-04-06 6:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Thierry Reding, Jonathan Hunter
Cc: linux-kernel, linux-tegra, Aaron Kling
From: Aaron Kling <webgeek1234@gmail.com>
This makes mc and emc interconnect providers and allows for dynamic
memory clock scaling.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Changes in v7:
- Squash fixes found during previous foray through -next
- Use kzalloc_obj in place of kzalloc
- Link to v6: https://lore.kernel.org/r/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com
Changes in v6:
- Fix style nit
- Link to v5: https://lore.kernel.org/r/20251021-t210-actmon-p2-v5-1-a07dc70e948d@gmail.com
Changes in v5:
- Split series
- Link to v4: https://lore.kernel.org/r/20250923-t210-actmon-v4-0-442d1eb6377c@gmail.com
Changes in v4:
- Various cleanups in patch 5 as requested by review
- Fix a couple typos in patch 4
- Link to v3: https://lore.kernel.org/r/20250906-t210-actmon-v3-0-1403365d571e@gmail.com
Changes in v3:
- In patch 5, don't fail mc probe if opp tables are missing
- Add more mc bindings to patch 1
- Add patch to use tegra210-mc bindings in the mc driver
- Re-order series to align patches within a subsystem to each other
- Link to v2: https://lore.kernel.org/r/20250903-t210-actmon-v2-0-e0d534d4f8ea@gmail.com
Changes in v2:
- Assume 64-bit dram bus width in patch 4
- Add dt-bindings patch to document the new properties on the
tegra210-emc node.
- Link to v1: https://lore.kernel.org/r/20250828-t210-actmon-v1-0-aeb19ec1f244@gmail.com
---
drivers/memory/tegra/Kconfig | 1 +
drivers/memory/tegra/tegra210-emc-core.c | 287 ++++++++++++++++++++++++++++++-
drivers/memory/tegra/tegra210-emc.h | 24 +++
drivers/memory/tegra/tegra210.c | 81 +++++++++
4 files changed, 390 insertions(+), 3 deletions(-)
diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index fc5a277918267ee8240f9fb9efeb80275db4790b..2d0be29afe2b9ebf9a0630ef7fb6fb43ff359499 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -55,6 +55,7 @@ config TEGRA210_EMC
tristate "NVIDIA Tegra210 External Memory Controller driver"
depends on ARCH_TEGRA_210_SOC || COMPILE_TEST
select TEGRA210_EMC_TABLE
+ select PM_OPP
help
This driver is for the External Memory Controller (EMC) found on
Tegra210 chips. The EMC controls the external DRAM on the board.
diff --git a/drivers/memory/tegra/tegra210-emc-core.c b/drivers/memory/tegra/tegra210-emc-core.c
index e96ca4157d48182574310f8caf72687bed7cc16a..c7850df2a21d9f6b837bc1fa24a159fc18b0498a 100644
--- a/drivers/memory/tegra/tegra210-emc-core.c
+++ b/drivers/memory/tegra/tegra210-emc-core.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/of_reserved_mem.h>
#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
#include <linux/slab.h>
#include <linux/thermal.h>
#include <soc/tegra/fuse.h>
@@ -87,6 +88,13 @@
#define LPDDR2_MR4_SRR GENMASK(2, 0)
+/*
+ * Tegra210 memory layout can be 1 channel at 64-bit or 2 channels at 32-bit
+ * each. Either way, the total bus width will always be 64-bit.
+ */
+#define DRAM_DATA_BUS_WIDTH_BYTES (64 / 8)
+#define DDR 2
+
static const struct tegra210_emc_sequence *tegra210_emc_sequences[] = {
&tegra210_emc_r21021,
};
@@ -1569,6 +1577,79 @@ static int tegra210_emc_set_rate(struct device *dev,
return 0;
}
+static void tegra210_emc_rate_requests_init(struct tegra210_emc *emc)
+{
+ unsigned int i;
+
+ for (i = 0; i < EMC_RATE_TYPE_MAX; i++) {
+ emc->requested_rate[i].min_rate = 0;
+ emc->requested_rate[i].max_rate = ULONG_MAX;
+ }
+}
+
+static int emc_request_rate(struct tegra210_emc *emc,
+ unsigned long new_min_rate,
+ unsigned long new_max_rate,
+ enum emc_rate_request_type type)
+{
+ struct emc_rate_request *req = emc->requested_rate;
+ unsigned long min_rate = 0, max_rate = ULONG_MAX;
+ unsigned int i;
+ int err;
+
+ /* select minimum and maximum rates among the requested rates */
+ for (i = 0; i < EMC_RATE_TYPE_MAX; i++, req++) {
+ if (i == type) {
+ min_rate = max(new_min_rate, min_rate);
+ max_rate = min(new_max_rate, max_rate);
+ } else {
+ min_rate = max(req->min_rate, min_rate);
+ max_rate = min(req->max_rate, max_rate);
+ }
+ }
+
+ if (min_rate > max_rate) {
+ dev_err_ratelimited(emc->dev, "%s: type %u: out of range: %lu %lu\n",
+ __func__, type, min_rate, max_rate);
+ return -ERANGE;
+ }
+
+ err = clk_set_rate(emc->clk, min_rate);
+ if (err)
+ return err;
+
+ emc->requested_rate[type].min_rate = new_min_rate;
+ emc->requested_rate[type].max_rate = new_max_rate;
+
+ return 0;
+}
+
+static int emc_set_min_rate(struct tegra210_emc *emc, unsigned long rate,
+ enum emc_rate_request_type type)
+{
+ struct emc_rate_request *req = &emc->requested_rate[type];
+ int ret;
+
+ mutex_lock(&emc->rate_lock);
+ ret = emc_request_rate(emc, rate, req->max_rate, type);
+ mutex_unlock(&emc->rate_lock);
+
+ return ret;
+}
+
+static int emc_set_max_rate(struct tegra210_emc *emc, unsigned long rate,
+ enum emc_rate_request_type type)
+{
+ struct emc_rate_request *req = &emc->requested_rate[type];
+ int ret;
+
+ mutex_lock(&emc->rate_lock);
+ ret = emc_request_rate(emc, req->min_rate, rate, type);
+ mutex_unlock(&emc->rate_lock);
+
+ return ret;
+}
+
/*
* debugfs interface
*
@@ -1641,7 +1722,7 @@ static int tegra210_emc_debug_min_rate_set(void *data, u64 rate)
if (!tegra210_emc_validate_rate(emc, rate))
return -EINVAL;
- err = clk_set_min_rate(emc->clk, rate);
+ err = emc_set_min_rate(emc, rate, EMC_RATE_DEBUG);
if (err < 0)
return err;
@@ -1671,7 +1752,7 @@ static int tegra210_emc_debug_max_rate_set(void *data, u64 rate)
if (!tegra210_emc_validate_rate(emc, rate))
return -EINVAL;
- err = clk_set_max_rate(emc->clk, rate);
+ err = emc_set_max_rate(emc, rate, EMC_RATE_DEBUG);
if (err < 0)
return err;
@@ -1758,6 +1839,194 @@ static void tegra210_emc_debugfs_init(struct tegra210_emc *emc)
&tegra210_emc_debug_temperature_fops);
}
+static inline struct tegra210_emc *
+to_tegra210_emc_provider(struct icc_provider *provider)
+{
+ return container_of(provider, struct tegra210_emc, icc_provider);
+}
+
+static struct icc_node_data *
+emc_of_icc_xlate_extended(const struct of_phandle_args *spec, void *data)
+{
+ struct icc_provider *provider = data;
+ struct icc_node_data *ndata;
+ struct icc_node *node;
+
+ /* External Memory is the only possible ICC route */
+ list_for_each_entry(node, &provider->nodes, node_list) {
+ if (node->id != TEGRA_ICC_EMEM)
+ continue;
+
+ ndata = kzalloc_obj(*ndata);
+ if (!ndata)
+ return ERR_PTR(-ENOMEM);
+
+ /*
+ * SRC and DST nodes should have matching TAG in order to have
+ * it set by default for a requested path.
+ */
+ ndata->tag = TEGRA_MC_ICC_TAG_ISO;
+ ndata->node = node;
+
+ return ndata;
+ }
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+
+static int emc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ struct tegra210_emc *emc = to_tegra210_emc_provider(dst->provider);
+ unsigned long long peak_bw = icc_units_to_bps(dst->peak_bw);
+ unsigned long long avg_bw = icc_units_to_bps(dst->avg_bw);
+ unsigned long long rate = max(avg_bw, peak_bw);
+ int err;
+
+ /*
+ * Tegra210 EMC runs on a clock rate of SDRAM bus. This means that
+ * EMC clock rate is twice smaller than the peak data rate because
+ * data is sampled on both EMC clock edges.
+ */
+ do_div(rate, DDR * DRAM_DATA_BUS_WIDTH_BYTES);
+ rate = min_t(u64, rate, U32_MAX);
+
+ err = emc_set_min_rate(emc, rate, EMC_RATE_ICC);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int tegra210_emc_icc_get_init_bw(struct icc_node *node, u32 *avg, u32 *peak)
+{
+ *avg = 0;
+ *peak = 0;
+
+ return 0;
+}
+
+static int tegra210_emc_interconnect_init(struct tegra210_emc *emc)
+{
+ const struct tegra_mc_soc *soc = emc->mc->soc;
+ struct icc_node *node;
+ int err;
+
+ emc->icc_provider.dev = emc->dev;
+ emc->icc_provider.set = emc_icc_set;
+ emc->icc_provider.data = &emc->icc_provider;
+ emc->icc_provider.aggregate = soc->icc_ops->aggregate;
+ emc->icc_provider.xlate_extended = emc_of_icc_xlate_extended;
+ emc->icc_provider.get_bw = tegra210_emc_icc_get_init_bw;
+
+ icc_provider_init(&emc->icc_provider);
+
+ /* create External Memory Controller node */
+ node = icc_node_create(TEGRA_ICC_EMC);
+ if (IS_ERR(node))
+ return PTR_ERR(node);
+
+ node->name = "External Memory Controller";
+ icc_node_add(node, &emc->icc_provider);
+
+ /* link External Memory Controller to External Memory (DRAM) */
+ err = icc_link_create(node, TEGRA_ICC_EMEM);
+ if (err)
+ goto remove_nodes;
+
+ /* create External Memory node */
+ node = icc_node_create(TEGRA_ICC_EMEM);
+ if (IS_ERR(node)) {
+ err = PTR_ERR(node);
+ goto remove_nodes;
+ }
+
+ node->name = "External Memory (DRAM)";
+ icc_node_add(node, &emc->icc_provider);
+
+ err = icc_provider_register(&emc->icc_provider);
+ if (err)
+ goto remove_nodes;
+
+ return 0;
+
+remove_nodes:
+ icc_nodes_remove(&emc->icc_provider);
+
+ return dev_err_probe(emc->dev, err, "failed to initialize ICC\n");
+}
+
+static int tegra210_emc_opp_table_init(struct tegra210_emc *emc)
+{
+ u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
+ struct dev_pm_opp *opp;
+ unsigned long rate;
+ int err, max_opps, i;
+
+ err = dev_pm_opp_set_supported_hw(emc->dev, &hw_version, 1);
+ if (err < 0)
+ return dev_err_probe(emc->dev, err, "failed to set OPP supported HW\n");
+
+ emc->hw_opp_token = err;
+
+ err = dev_pm_opp_of_add_table(emc->dev);
+ if (err) {
+ if (err == -ENODEV)
+ dev_err_probe(emc->dev, err,
+ "OPP table not found, please update your device tree\n");
+ else
+ dev_err_probe(emc->dev, err, "failed to add OPP table\n");
+
+ goto put_hw_table;
+ }
+
+ max_opps = dev_pm_opp_get_opp_count(emc->dev);
+ if (max_opps <= 0) {
+ err = max_opps ?: -EINVAL;
+ dev_err_probe(emc->dev, err, "Failed to add OPPs\n");
+ goto remove_table;
+ }
+
+ if (emc->num_timings != max_opps) {
+ err = -EINVAL;
+ dev_err_probe(emc->dev, err, "OPP table does not match emc table\n");
+ goto remove_table;
+ }
+
+ for (i = 0; i < emc->num_timings; i++) {
+ rate = emc->timings[i].rate * 1000;
+ opp = dev_pm_opp_find_freq_exact(emc->dev, rate, true);
+ if (IS_ERR(opp)) {
+ err = PTR_ERR(opp);
+ dev_err_probe(emc->dev, err, "Rate %lu not found in OPP table\n", rate);
+ goto remove_table;
+ }
+
+ dev_pm_opp_put(opp);
+ }
+
+ dev_info_once(emc->dev, "OPP HW ver. 0x%x, current clock rate %lu MHz\n",
+ hw_version, clk_get_rate(emc->clk) / 1000000);
+
+ return 0;
+
+remove_table:
+ dev_pm_opp_of_remove_table(emc->dev);
+put_hw_table:
+ dev_pm_opp_put_supported_hw(emc->hw_opp_token);
+ emc->hw_opp_token = 0;
+
+ return err;
+}
+
+static void tegra210_emc_opp_table_cleanup(struct tegra210_emc *emc)
+{
+ if (emc->hw_opp_token) {
+ dev_pm_opp_of_remove_table(emc->dev);
+ dev_pm_opp_put_supported_hw(emc->hw_opp_token);
+ emc->hw_opp_token = 0;
+ }
+}
+
static void tegra210_emc_detect(struct tegra210_emc *emc)
{
u32 value;
@@ -1966,17 +2235,27 @@ static int tegra210_emc_probe(struct platform_device *pdev)
tegra210_emc_debugfs_init(emc);
+ err = tegra210_emc_opp_table_init(emc);
+ if (!err) {
+ tegra210_emc_rate_requests_init(emc);
+ tegra210_emc_interconnect_init(emc);
+ } else if (err != -ENODEV) {
+ goto detach;
+ }
+
cd = devm_thermal_of_cooling_device_register(emc->dev, np, "emc", emc,
&tegra210_emc_cd_ops);
if (IS_ERR(cd)) {
err = PTR_ERR(cd);
dev_err(emc->dev, "failed to register cooling device: %d\n",
err);
- goto detach;
+ goto cleanup_table;
}
return 0;
+cleanup_table:
+ tegra210_emc_opp_table_cleanup(emc);
detach:
debugfs_remove_recursive(emc->debugfs.root);
tegra210_clk_emc_detach(emc->clk);
@@ -1990,6 +2269,7 @@ static void tegra210_emc_remove(struct platform_device *pdev)
{
struct tegra210_emc *emc = platform_get_drvdata(pdev);
+ tegra210_emc_opp_table_cleanup(emc);
debugfs_remove_recursive(emc->debugfs.root);
tegra210_clk_emc_detach(emc->clk);
of_reserved_mem_device_release(emc->dev);
@@ -2050,6 +2330,7 @@ static struct platform_driver tegra210_emc_driver = {
.name = "tegra210-emc",
.of_match_table = tegra210_emc_of_match,
.pm = &tegra210_emc_pm_ops,
+ .sync_state = icc_sync_state,
},
.probe = tegra210_emc_probe,
.remove = tegra210_emc_remove,
diff --git a/drivers/memory/tegra/tegra210-emc.h b/drivers/memory/tegra/tegra210-emc.h
index 8988bcf1529072a7bdc93b185ebe0d51d82c1763..e6f267823f9f0ee18cd60778116dc5ca2730a5d4 100644
--- a/drivers/memory/tegra/tegra210-emc.h
+++ b/drivers/memory/tegra/tegra210-emc.h
@@ -8,6 +8,7 @@
#include <linux/clk.h>
#include <linux/clk/tegra.h>
+#include <linux/interconnect-provider.h>
#include <linux/io.h>
#include <linux/platform_device.h>
@@ -784,6 +785,17 @@ enum {
#define TRIM_REGS_SIZE 138
#define BURST_REGS_SIZE 221
+enum emc_rate_request_type {
+ EMC_RATE_DEBUG,
+ EMC_RATE_ICC,
+ EMC_RATE_TYPE_MAX,
+};
+
+struct emc_rate_request {
+ unsigned long min_rate;
+ unsigned long max_rate;
+};
+
struct tegra210_emc_per_channel_regs {
u16 bank;
u16 offset;
@@ -932,6 +944,18 @@ struct tegra210_emc {
} debugfs;
struct tegra210_clk_emc_provider provider;
+
+ struct icc_provider icc_provider;
+ int hw_opp_token;
+
+ /*
+ * There are multiple sources in the EMC driver which could request
+ * a min/max clock rate, these rates are contained in this array.
+ */
+ struct emc_rate_request requested_rate[EMC_RATE_TYPE_MAX];
+
+ /* protect shared rate-change code path */
+ struct mutex rate_lock;
};
struct tegra210_emc_sequence {
diff --git a/drivers/memory/tegra/tegra210.c b/drivers/memory/tegra/tegra210.c
index f58f3ef6f68191ede7098bfa4dad546ce4de275d..bcc441e786301438279e5318373d502e3b22eec5 100644
--- a/drivers/memory/tegra/tegra210.c
+++ b/drivers/memory/tegra/tegra210.c
@@ -3,6 +3,9 @@
* Copyright (C) 2015-2026 NVIDIA CORPORATION. All rights reserved.
*/
+#include <linux/of.h>
+#include <linux/device.h>
+
#include <dt-bindings/memory/tegra210-mc.h>
#include "mc.h"
@@ -1282,6 +1285,83 @@ static const struct tegra_mc_intmask tegra210_mc_intmasks[] = {
},
};
+static int tegra210_mc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ /* TODO: program PTSA */
+ return 0;
+}
+
+static int tegra210_mc_icc_aggregate(struct icc_node *node, u32 tag, u32 avg_bw,
+ u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
+{
+ /*
+ * ISO clients need to reserve extra bandwidth up-front because
+ * there could be high bandwidth pressure during initial filling
+ * of the client's FIFO buffers. Secondly, we need to take into
+ * account impurities of the memory subsystem.
+ */
+ if (tag & TEGRA_MC_ICC_TAG_ISO)
+ peak_bw = tegra_mc_scale_percents(peak_bw, 400);
+
+ *agg_avg += avg_bw;
+ *agg_peak = max(*agg_peak, peak_bw);
+
+ return 0;
+}
+
+static struct icc_node_data *
+tegra210_mc_of_icc_xlate_extended(const struct of_phandle_args *spec, void *data)
+{
+ struct tegra_mc *mc = icc_provider_to_tegra_mc(data);
+ const struct tegra_mc_client *client;
+ unsigned int i, idx = spec->args[0];
+ struct icc_node_data *ndata;
+ struct icc_node *node;
+
+ list_for_each_entry(node, &mc->provider.nodes, node_list) {
+ if (node->id != idx)
+ continue;
+
+ ndata = kzalloc_obj(*ndata);
+ if (!ndata)
+ return ERR_PTR(-ENOMEM);
+
+ client = &mc->soc->clients[idx];
+ ndata->node = node;
+
+ switch (client->swgroup) {
+ case TEGRA_SWGROUP_DC:
+ case TEGRA_SWGROUP_DCB:
+ case TEGRA_SWGROUP_PTC:
+ case TEGRA_SWGROUP_VI:
+ /* these clients are isochronous by default */
+ ndata->tag = TEGRA_MC_ICC_TAG_ISO;
+ break;
+
+ default:
+ ndata->tag = TEGRA_MC_ICC_TAG_DEFAULT;
+ break;
+ }
+
+ return ndata;
+ }
+
+ for (i = 0; i < mc->soc->num_clients; i++) {
+ if (mc->soc->clients[i].id == idx)
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ dev_err(mc->dev, "invalid ICC client ID %u\n", idx);
+
+ return ERR_PTR(-EINVAL);
+}
+
+static const struct tegra_mc_icc_ops tegra210_mc_icc_ops = {
+ .xlate_extended = tegra210_mc_of_icc_xlate_extended,
+ .aggregate = tegra210_mc_icc_aggregate,
+ .set = tegra210_mc_icc_set,
+};
+
const struct tegra_mc_soc tegra210_mc_soc = {
.clients = tegra210_mc_clients,
.num_clients = ARRAY_SIZE(tegra210_mc_clients),
@@ -1294,6 +1374,7 @@ const struct tegra_mc_soc tegra210_mc_soc = {
.reset_ops = &tegra_mc_reset_ops_common,
.resets = tegra210_mc_resets,
.num_resets = ARRAY_SIZE(tegra210_mc_resets),
+ .icc_ops = &tegra210_mc_icc_ops,
.ops = &tegra30_mc_ops,
.regs = &tegra20_mc_regs,
.handle_irq = tegra30_mc_irq_handlers,
---
base-commit: 2febe6e6ee6e34c7754eff3c4d81aa7b0dcb7979
change-id: 20260405-t210-actmon-p2-0bcd5fc65ec6
Best regards,
--
Aaron Kling <webgeek1234@gmail.com>
^ permalink raw reply related
* Re: [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: zhang @ 2026-04-05 0:58 UTC (permalink / raw)
To: joonwonkang
Cc: angelogioacchino.delregno, jassisinghbrar, jonathanh,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding
In-Reply-To: <20260404124428.3077670-1-joonwonkang@google.com>
Hi! Joonwon Kang.
I just looked at the content of your email, and I think we can design a resource priority scheduling system with 70% and 30% priority allocation. The specific idea is as follows:
During task execution, each task can be tagged. Important tasks can be allocated to the 30% of resources, while the remaining 70% can be used to run low-load and repetitive pipeline tasks.
The specific algorithm can be written as follows: reserve 30% of the runtime space for the system's critical processes. For the remaining 70% of non-critical processes, a judgment can be made: if resource usage exceeds 70%, the excess processes are marked with a priority deferred tag and run only when resources are freed up.
--
the-essence-of-life
^ permalink raw reply
* Re: [PATCH] staging: rtl8723bs: fix logical continuation style
From: Ethan Tidmore @ 2026-04-04 22:26 UTC (permalink / raw)
To: Paarth Mahadik, marvin24
Cc: gregkh, ac100, linux-tegra, linux-staging, linux-kernel
In-Reply-To: <20260404072626.134642-1-paarth.mahadik@gmail.com>
On Sat Apr 4, 2026 at 2:26 AM CDT, Paarth Mahadik wrote:
> Logical continuation should be on the previous line,
> move && to the end of the preceding line and align
> the continuation with the opening parenthesis.
>
> Signed-off-by: Paarth Mahadik <paarth.mahadik@gmail.com>
> ---
LGTM.
Reviewed-by: Ethan Tidmore <ethantidmore06@gmail.com>
Thanks,
ET
^ permalink raw reply
* Re: (subset) [PATCH v8 0/9] Enhancements to pcie-tegra194 driver
From: Manivannan Sadhasivam @ 2026-04-04 15:28 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kwilczynski, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159,
Manikanta Maddireddy
Cc: linux-pci, linux-tegra, linux-kernel
In-Reply-To: <20260324191000.1095768-1-mmaddireddy@nvidia.com>
On Wed, 25 Mar 2026 00:39:51 +0530, Manikanta Maddireddy wrote:
> This series[1] was originally posted by Vidya Sagar, and I have rebased
> it onto 6.19.0-rc6-next. I addressed review comments and split this into
> two series, one for fixes and the other is for enhancements(current).
> I verified these patches on Jetson AGX Orin(Tegra234 SoC).
>
> Disabling L1SS capability based on support-clkreq device tree property
> is moved to common DWC driver, so I reworked below patch to disable
> just L1.2 capability on Tegra234 SoC.
> - PCI: tegra194: Disable L1.2 capability of Tegra234 EP
>
> [...]
Applied, thanks!
[1/9] PCI: tegra194: Drive CLKREQ# signal low explicitly
commit: cab9cf41c26efcb38b6a010bb47eb865d2c28b8f
[2/9] PCI: tegra194: Calibrate pipe to UPHY for Endpoint mode
commit: 48950d06f43ae06a292dba4d36055f4b798f08dd
[3/9] PCI: tegra194: Remove IRQF_ONESHOT flag during Endpoint interrupt registration
commit: 255ba6db039d78c5984c0e0f5cd5f90a4665a7ef
[4/9] PCI: tegra194: Enable DMA interrupt
commit: 7cbba5a0dc2719bd3002cc8d88f8dacd240ca4a8
[5/9] PCI: tegra194: Enable hardware hot reset mode in Endpoint
commit: 02f546088a94726b0b1a1012a0b8d6a3ac635d2e
[6/9] dt-bindings: PCI: tegra194: Add monitor clock support
commit: 513bafa5a569c9138849da2396227a7f5378a8dd
[7/9] PCI: tegra194: Add core monitor clock support
commit: 8eb40477d93539505b7d8104d5cd776282eba44f
[9/9] PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latency
commit: 814f4e4b6cceda9e816fbeaf2a6a0f9b50b3f23a
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 00/14] Fixes to pcie-tegra194 driver
From: Manivannan Sadhasivam @ 2026-04-04 15:10 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kwilczynski, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159,
Manikanta Maddireddy
Cc: linux-pci, linux-tegra, linux-kernel
In-Reply-To: <20260324190755.1094879-1-mmaddireddy@nvidia.com>
On Wed, 25 Mar 2026 00:37:41 +0530, Manikanta Maddireddy wrote:
> This series[1] was originally posted by Vidya Sagar, and I have rebased
> it onto 6.19.0-rc6-next. I addressed review comments and split this into
> two series, one for fixes(current) and the other is for enhancements.
> I verified these patches on Jetson AGX Orin(Tegra234 SoC).
>
> I added below four new patches to fix bugs, commit message of each
> patch has the details on the bug and fix.
> - PCI: tegra194: Use HW version number
> - PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on
> - PCI: tegra194: Disable PERST IRQ only in Endpoint mode
>
> [...]
Applied, thanks!
[01/14] PCI: tegra194: Fix polling delay for L2 state
commit: 368e83ebef4527fa5dae9074e9e8086bb8f8c15f
[02/14] PCI: tegra194: Increase LTSSM poll time on surprise down
commit: 592dd01fa4bed72b1b523e48a8e0336002169e98
[03/14] PCI: tegra194: Disable LTSSM after transition to detect on surprise down
commit: 5b2322bd2b0a3d3d98dc1e27ec372221faa98140
[04/14] PCI: tegra194: Don't force the device into the D0 state before L2
commit: 7049b21df37359e2da77e1c553062d60bd175f4f
[05/14] PCI: tegra194: Disable PERST IRQ only in Endpoint mode
commit: 5e05484b857981bdf7ad247d8bd9e1733edebe9b
[06/14] PCI: tegra194: Use devm_gpiod_get_optional() to parse "nvidia,refclk-select"
commit: 4ee540f02d5de5ccabcfee266f12e8bec960564b
[07/14] PCI: tegra194: Disable direct speed change for Endpoint
commit: 431451cf9acdec5df2210d6a4139a0f8678fc6bd
[08/14] PCI: tegra194: Set LTR message request before PCIe link up
commit: 24fa3bae1337e91eafdcd6f45dc89edbff4a8e71
[09/14] PCI: tegra194: Allow system suspend when the Endpoint link is not up
commit: f6faa564bd25742d814382de582a5069b9a48f57
[10/14] PCI: tegra194: Free up EP resources during remove()
commit: 33d10df4c93fc8dc455275ee704157a1b4b3f60d
[11/14] PCI: tegra194: Use DWC IP core version
commit: 645e07639d6bdfaf1836b73fbf5547bb054d225f
[12/14] PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well
commit: b210b15956061e27f2bbb7a740792227c34ee338
[13/14] PCI: tegra194: Disable L1.2 capability of Tegra234 EP
commit: 1443e9be158dc199b279a7fd26fa960b1833b9c2
[14/14] PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on
commit: 93d2f203b330f3f487a3786fe19dc84c618f2b3e
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [GIT PULL 4/7] ARM: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-04-04 14:04 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <20260329151045.1443133-4-thierry.reding@kernel.org>
On Sun, Mar 29, 2026 at 05:10:41PM +0200, Thierry Reding wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
>
> Hi ARM SoC maintainers,
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm-dt
>
> for you to fetch changes up to ce74a6c6d88ba9ee29a6b99ac97ffcded577c85d:
>
> ARM: tegra: paz00: Configure WiFi rfkill switch through device tree (2026-03-28 00:56:36 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v7.1-rc1
>
> Various improvements for Tegra114 boards, as well as some legacy cleanup
> for PAZ00 and Transformers devices.
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: Joonwon Kang @ 2026-04-04 12:44 UTC (permalink / raw)
To: jassisinghbrar
Cc: angelogioacchino.delregno, jonathanh, joonwonkang,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding
In-Reply-To: <CABb+yY0uDQh-3cadPQONV=NJKjMtc4mJekgjmHYVaHnfHXvGZQ@mail.gmail.com>
> On Fri, Apr 3, 2026 at 9:51 AM Joonwon Kang <joonwonkang@google.com> wrote:
> >
> > > On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> > > >
> > > > Previously, a sender thread in mbox_send_message() could be woken up at
> > > > a wrong time in blocking mode. It is because there was only a single
> > > > completion for a channel whereas messages from multiple threads could be
> > > > sent in any order; since the shared completion could be signalled in any
> > > > order, it could wake up a wrong sender thread.
> > > >
> > > > This commit resolves the false wake-up issue with the following changes:
> > > > - Completions are created just as many as the number of concurrent sender
> > > > threads
> > > > - A completion is created on a sender thread's stack
> > > > - Each slot of the message queue, i.e. `msg_data`, contains a pointer to
> > > > its target completion
> > > > - tx_tick() signals the completion of the currently active slot of the
> > > > message queue
> > > >
> > > I think I reviewed it already or is this happening on
> > > one-channel-one-client usage? Because mailbox api does not support
> > > channels shared among multiple clients.
> >
> > Yes, this patch is handling the one-channel-one-client usage but when that
> > single channel is shared between multiple threads.
>
> hmm.... how is this not single-channel-multiple-clients ?
> A channel is returned as an opaque token to the clients, if that
> client shares that with other threads - they will race.
They will race because of the current blocking mode implementation. With this
patch, they should not race as it handles the known racing point. So, I think
it will be important to decide whether to support multi-threads in blocking
mode or not.
> It is the job of the original client to serialize its threads' access
> to the channel.
I can see the disparity with the non-blocking mode here. Currently, the client
does not need to serialize its threads' access to the channel in non-blocking
mode whereas it needs to in blocking mode. It would be nice if the client does
not need to in both modes, but it may also depend on the necessity as you said.
> > From my understanding, the
> > discussion back then ended with how to circumvent the issue rather than whether
> > we will eventually solve this in the mailbox framework or not, and if yes, how
> > we will, and if not, why.
>
> It will be interesting to see how many current clients actually need
> to share channels. If there are enough, it makes sense to implement
> some helper api
> on top of existing code, instead of changing its nature totally.
I agree that we may need research on the current uses of channels and the
necessity of shared channels. However, it may require non-trivial amount of
time since it requires thorough understanding of the context of every client
driver. At this point, I think we at least need a clear documentation in terms
of multi-threads support as we have none now. Since it is obvious that
multi-threads is not supported for now, I can create another patch to add this
to the API doc to be clear. How do you think?
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH v3 2/2] mailbox: Make mbox_send_message() return error code when tx fails
From: Joonwon Kang @ 2026-04-04 11:47 UTC (permalink / raw)
To: jassisinghbrar
Cc: akpm, angelogioacchino.delregno, jonathanh, joonwonkang,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding, lee
In-Reply-To: <CABb+yY23aTXeXu6G-8sHjw32DCqmhsJLu2Mt-txenOgTBiyv+A@mail.gmail.com>
> On Fri, Apr 3, 2026 at 10:19 AM Joonwon Kang <joonwonkang@google.com> wrote:
> >
> > > On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> > > >
> > > > When the mailbox controller failed transmitting message, the error code
> > > > was only passed to the client's tx done handler and not to
> > > > mbox_send_message(). For this reason, the function could return a false
> > > > success. This commit resolves the issue by introducing the tx status and
> > > > checking it before mbox_send_message() returns.
> > > >
> > > Can you please share the scenario when this becomes necessary? This
> > > can potentially change the ground underneath some clients, so we have
> > > to be sure this is really useful.
> >
> > I would say the problem here is generic enough to apply to all the cases where
> > the send result needs to be checked. Since the return value of the send API is
> > not the real send result, any users who believe that this blocking send API
> > will return the real send result could fall for that. For example, users may
> > think the send was successful even though it was not actually. I believe it is
> > uncommon that users have to register a callback solely to get the send result
> > even though they are using the blocking send API already. Also, I guess there
> > is no special reason why only the mailbox send API should work this way among
> > other typical blocking send APIs. For these reasons, this patch makes the send
> > API return the real send result. This way, users will not need to register the
> > redundant callback and I think the return value will align with their common
> > expectation.
> >
> Clients submit a message into the Mailbox subsystem to be sent out to
> the remote side which can happen immediately or later.
> If submission fails, clients get immediately notified. If transmission
> fails (which is now internal to the subsystem) it is reported to the
> client by a callback.
> If the API was called mbox_submit_message (which it actually is)
> instead of mbox_send_message, there would be no confusion.
> We can argue how good/bad the current implementation is, but the fact
> is that it is here. And I am reluctant to cause churn without good
> reason.
> Again, as I said, any, _legal_, setup scenario will help me come over
> my reluctance.
mbox_send_message() in blocking mode is not only for submitting the message in
the first place if we read through the API docs.
From the API doc for `mbox_send_message()`:
```
* If the client had set 'tx_block', the call will return
* either when the remote receives the data or when 'tx_tout' millisecs
* run out.
```
From the API doc for `struct mbox_client`:
```
* @tx_block: If the mbox_send_message should block until data is
* transmitted.
```
With the docs, I think it is apparent that the API covers "transmission" of the
message, not only submission of it. If sumbitting is the sole purpose of the
API, what does the API block for in the first place? We would not need the
blocking mode at all then.
The current return value of the API in failure cases is as follows:
- When submission fails, returns failure.
- When submission succeeds but timeout occurs during transmission, return
failure, i.e. -ETIME.
- When submission succeeds but transmission fails without timeout, return
success.
The third case looks problematic. This patch is focusing on this. There is also
disparity to handle the failure between timeout(the second case) and
non-timeout(the third case). Why does it not return failure when non-timeout
error occurs during transmission whereas it does when timeout occurs during
transmission? If the API is solely for submission, why does it return failure
instead of success in the second case?
In the third case, the controller(or the client) will inform the mailbox core
of the transmission failure. Then, why not return that failure as a return
value of the API despite having this information in the core?
An alternative to fixing this issue would be adding the API doc by saying like:
- In blocking mode, the send API will return -ETIME when timeout occurs during
transmission, but it will not return failure but success(since submission
itself was successful before transmission) when other errors occur during
transmission. Users have to register a callback to collect the error code
when non-timeout error occurs.
But, I think we can go away with this unnecessary confusion by fixing the API
just to return the error code when error occurs regardless of whether it is
timeout or not. Then, we could simply say:
- In blocking mode, the send API will return failure when error occurs.
Since this patch is pointing out this anomaly of the send API's behavior, I
am not sure what scenario we would need more. In other words, the current way
of working would be more surprising to the users than the fixed version of it
as it was when I found out this issue for the first time.
Do you think that this change will cause any other problem on the client side
than fixing the existing issue? If not, I am wondering why not go fix the
issue with this patch.
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH v3 0/4] PCI: endpoint: Add Tegra194/234 BAR layout and pci_endpoint_test support
From: Manivannan Sadhasivam @ 2026-04-04 10:47 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kwilczynski, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159,
Manikanta Maddireddy
Cc: linux-pci, linux-tegra, linux-kernel
In-Reply-To: <20260324080857.916263-1-mmaddireddy@nvidia.com>
On Tue, 24 Mar 2026 13:38:53 +0530, Manikanta Maddireddy wrote:
> This series is on top of https://lore.kernel.org/linux-pci/20260312130229.2282001-12-cassel@kernel.org/T/#u
>
> This series wires up Tegra194 and Tegra234 PCI endpoint controllers to the
> shared PCI endpoint and test infrastructure:
>
> 1. Add a new reserved-region type for MSI-X (Table and PBA) so EPC drivers
> can describe hardware-owned MSI-X regions behind a BAR_RESERVED BAR.
>
> [...]
Applied, thanks!
[1/4] PCI: endpoint: Add reserved region type for MSI-X Table and PBA
commit: 5f352433ea39171e19fbb3a7e18d983510176854
[2/4] PCI: tegra194: Make BAR0 programmable and remove 1MB size limit
commit: 5aec1f18b326ddc455ae9d9d0f5394efc20eee9b
[3/4] PCI: tegra194: Expose BAR2 (MSI-X) and BAR4 (DMA) as 64-bit BAR_RESERVED
commit: 12a22fb38cbba1991a3f174912b343cdb6afa186
[4/4] misc: pci_endpoint_test: Add Tegra194 and Tegra234 device table entries
commit: 5ab7a225888baa5474def18ba3b0a298d27e6ba0
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* [PATCH] staging: rtl8723bs: fix logical continuation style
From: Paarth Mahadik @ 2026-04-04 7:26 UTC (permalink / raw)
To: marvin24
Cc: gregkh, ac100, linux-tegra, linux-staging, linux-kernel,
Paarth Mahadik
Logical continuation should be on the previous line,
move && to the end of the preceding line and align
the continuation with the opening parenthesis.
Signed-off-by: Paarth Mahadik <paarth.mahadik@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_btcoex.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_btcoex.c b/drivers/staging/rtl8723bs/core/rtw_btcoex.c
index 0191a943f0a4..f47c9d079e70 100644
--- a/drivers/staging/rtl8723bs/core/rtw_btcoex.c
+++ b/drivers/staging/rtl8723bs/core/rtw_btcoex.c
@@ -10,8 +10,8 @@
void rtw_btcoex_MediaStatusNotify(struct adapter *padapter, u8 media_status)
{
- if ((media_status == RT_MEDIA_CONNECT)
- && (check_fwstate(&padapter->mlmepriv, WIFI_AP_STATE) == true)) {
+ if ((media_status == RT_MEDIA_CONNECT) &&
+ (check_fwstate(&padapter->mlmepriv, WIFI_AP_STATE) == true)) {
rtw_hal_set_hwreg(padapter, HW_VAR_DL_RSVD_PAGE, NULL);
}
--
2.53.0
^ permalink raw reply related
* [PATCH] staging: nvec: fix block comment style
From: Paarth Mahadik @ 2026-04-04 6:37 UTC (permalink / raw)
To: marvin24
Cc: gregkh, ac100, linux-tegra, linux-staging, linux-kernel,
Paarth Mahadik
Block comments should use * on subsequent lines and
have the closing */ on a separate line.
Signed-off-by: Paarth Mahadik <paarth.mahadik@gmail.com>
---
drivers/staging/nvec/nvec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index e9af66a08448..0e655f79ea4a 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -660,7 +660,8 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
to_send = nvec->tx->data[0];
nvec->tx->pos = 1;
/* delay ACK due to AP20 HW Bug
- do not replace by usleep_range */
+ * do not replace by usleep_range
+ */
udelay(33);
} else if (status == (I2C_SL_IRQ)) {
nvec->rx->data[1] = received;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH V4 0/3] net: stmmac: Fix Tegra234 MGBE clock
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Jon Hunter
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, thierry.reding, netdev, devicetree, linux-tegra
In-Reply-To: <20260401102941.17466-1-jonathanh@nvidia.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 11:29:38 +0100 you wrote:
> The name of the PTP ref clock for the Tegra234 MGBE ethernet controller
> does not match the generic name in the stmmac platform driver. Despite
> this basic ethernet is functional on the Tegra234 platforms that use
> this driver and as far as I know, we have not tested PTP support with
> this driver. Hence, the risk of breaking any functionality is low.
>
> The previous attempt to fix this in the stmmac platform driver, by
> supporting the Tegra234 PTP clock name, was rejected [0]. The preference
> from the netdev maintainers is to fix this in the DT binding for
> Tegra234.
>
> [...]
Here is the summary with links:
- [V4,1/3] net: stmmac: Fix PTP ref clock for Tegra234
https://git.kernel.org/netdev/net/c/1345e9f4e3f3
- [V4,2/3] dt-bindings: net: Fix Tegra234 MGBE PTP clock
https://git.kernel.org/netdev/net/c/fb22b1fc5bca
- [V4,3/3] arm64: tegra: Fix Tegra234 MGBE PTP clock
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 2/2] mailbox: Make mbox_send_message() return error code when tx fails
From: Jassi Brar @ 2026-04-03 16:36 UTC (permalink / raw)
To: Joonwon Kang
Cc: angelogioacchino.delregno, jonathanh, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-tegra, matthias.bgg, stable,
thierry.reding, akpm
In-Reply-To: <20260403151950.2592581-1-joonwonkang@google.com>
On Fri, Apr 3, 2026 at 10:19 AM Joonwon Kang <joonwonkang@google.com> wrote:
>
> > On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> > >
> > > When the mailbox controller failed transmitting message, the error code
> > > was only passed to the client's tx done handler and not to
> > > mbox_send_message(). For this reason, the function could return a false
> > > success. This commit resolves the issue by introducing the tx status and
> > > checking it before mbox_send_message() returns.
> > >
> > Can you please share the scenario when this becomes necessary? This
> > can potentially change the ground underneath some clients, so we have
> > to be sure this is really useful.
>
> I would say the problem here is generic enough to apply to all the cases where
> the send result needs to be checked. Since the return value of the send API is
> not the real send result, any users who believe that this blocking send API
> will return the real send result could fall for that. For example, users may
> think the send was successful even though it was not actually. I believe it is
> uncommon that users have to register a callback solely to get the send result
> even though they are using the blocking send API already. Also, I guess there
> is no special reason why only the mailbox send API should work this way among
> other typical blocking send APIs. For these reasons, this patch makes the send
> API return the real send result. This way, users will not need to register the
> redundant callback and I think the return value will align with their common
> expectation.
>
Clients submit a message into the Mailbox subsystem to be sent out to
the remote side which can happen immediately or later.
If submission fails, clients get immediately notified. If transmission
fails (which is now internal to the subsystem) it is reported to the
client by a callback.
If the API was called mbox_submit_message (which it actually is)
instead of mbox_send_message, there would be no confusion.
We can argue how good/bad the current implementation is, but the fact
is that it is here. And I am reluctant to cause churn without good
reason.
Again, as I said, any, _legal_, setup scenario will help me come over
my reluctance.
Thanks
Jassi
^ permalink raw reply
* Re: [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: Jassi Brar @ 2026-04-03 16:19 UTC (permalink / raw)
To: Joonwon Kang
Cc: angelogioacchino.delregno, jonathanh, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-tegra, matthias.bgg, stable,
thierry.reding
In-Reply-To: <20260403145119.2581034-1-joonwonkang@google.com>
On Fri, Apr 3, 2026 at 9:51 AM Joonwon Kang <joonwonkang@google.com> wrote:
>
> > On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> > >
> > > Previously, a sender thread in mbox_send_message() could be woken up at
> > > a wrong time in blocking mode. It is because there was only a single
> > > completion for a channel whereas messages from multiple threads could be
> > > sent in any order; since the shared completion could be signalled in any
> > > order, it could wake up a wrong sender thread.
> > >
> > > This commit resolves the false wake-up issue with the following changes:
> > > - Completions are created just as many as the number of concurrent sender
> > > threads
> > > - A completion is created on a sender thread's stack
> > > - Each slot of the message queue, i.e. `msg_data`, contains a pointer to
> > > its target completion
> > > - tx_tick() signals the completion of the currently active slot of the
> > > message queue
> > >
> > I think I reviewed it already or is this happening on
> > one-channel-one-client usage? Because mailbox api does not support
> > channels shared among multiple clients.
>
> Yes, this patch is handling the one-channel-one-client usage but when that
> single channel is shared between multiple threads.
hmm.... how is this not single-channel-multiple-clients ?
A channel is returned as an opaque token to the clients, if that
client shares that with other threads - they will race.
It is the job of the original client to serialize its threads' access
to the channel.
> From my understanding, the
> discussion back then ended with how to circumvent the issue rather than whether
> we will eventually solve this in the mailbox framework or not, and if yes, how
> we will, and if not, why.
It will be interesting to see how many current clients actually need
to share channels. If there are enough, it makes sense to implement
some helper api
on top of existing code, instead of changing its nature totally.
Thanks
Jassi
^ permalink raw reply
* Re: [PATCH v3 2/2] mailbox: Make mbox_send_message() return error code when tx fails
From: Joonwon Kang @ 2026-04-03 15:19 UTC (permalink / raw)
To: jassisinghbrar
Cc: angelogioacchino.delregno, jonathanh, joonwonkang,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding, akpm
In-Reply-To: <CABb+yY3hYcJ82QGor3w5KKHUGz9Pc1k64Jdf-94E4Yvv0DTeyQ@mail.gmail.com>
> On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> >
> > When the mailbox controller failed transmitting message, the error code
> > was only passed to the client's tx done handler and not to
> > mbox_send_message(). For this reason, the function could return a false
> > success. This commit resolves the issue by introducing the tx status and
> > checking it before mbox_send_message() returns.
> >
> Can you please share the scenario when this becomes necessary? This
> can potentially change the ground underneath some clients, so we have
> to be sure this is really useful.
I would say the problem here is generic enough to apply to all the cases where
the send result needs to be checked. Since the return value of the send API is
not the real send result, any users who believe that this blocking send API
will return the real send result could fall for that. For example, users may
think the send was successful even though it was not actually. I believe it is
uncommon that users have to register a callback solely to get the send result
even though they are using the blocking send API already. Also, I guess there
is no special reason why only the mailbox send API should work this way among
other typical blocking send APIs. For these reasons, this patch makes the send
API return the real send result. This way, users will not need to register the
redundant callback and I think the return value will align with their common
expectation.
Regarding the change in the ground for some clients, could you help to clarify
a bit more on what change, you expect, would surprise the clients?
Thanks,
Joonwon Kang
>
> Thanks
> Jassi
>
>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Joonwon Kang <joonwonkang@google.com>
> > ---
> > drivers/mailbox/mailbox.c | 20 +++++++++++++++-----
> > include/linux/mailbox_controller.h | 2 ++
> > 2 files changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> > index d63386468982..ea9aec9dc947 100644
> > --- a/drivers/mailbox/mailbox.c
> > +++ b/drivers/mailbox/mailbox.c
> > @@ -21,7 +21,10 @@
> > static LIST_HEAD(mbox_cons);
> > static DEFINE_MUTEX(con_mutex);
> >
> > -static int add_to_rbuf(struct mbox_chan *chan, void *mssg, struct completion *tx_complete)
> > +static int add_to_rbuf(struct mbox_chan *chan,
> > + void *mssg,
> > + struct completion *tx_complete,
> > + int *tx_status)
> > {
> > int idx;
> >
> > @@ -34,6 +37,7 @@ static int add_to_rbuf(struct mbox_chan *chan, void *mssg, struct completion *tx
> > idx = chan->msg_free;
> > chan->msg_data[idx].data = mssg;
> > chan->msg_data[idx].tx_complete = tx_complete;
> > + chan->msg_data[idx].tx_status = tx_status;
> > chan->msg_count++;
> >
> > if (idx == MBOX_TX_QUEUE_LEN - 1)
> > @@ -91,12 +95,13 @@ static void msg_submit(struct mbox_chan *chan)
> >
> > static void tx_tick(struct mbox_chan *chan, int r, int idx)
> > {
> > - struct mbox_message mssg = {MBOX_NO_MSG, NULL};
> > + struct mbox_message mssg = {MBOX_NO_MSG, NULL, NULL};
> >
> > scoped_guard(spinlock_irqsave, &chan->lock) {
> > if (idx >= 0 && idx != chan->active_req) {
> > chan->msg_data[idx].data = MBOX_NO_MSG;
> > chan->msg_data[idx].tx_complete = NULL;
> > + chan->msg_data[idx].tx_status = NULL;
> > return;
> > }
> >
> > @@ -116,8 +121,10 @@ static void tx_tick(struct mbox_chan *chan, int r, int idx)
> > if (chan->cl->tx_done)
> > chan->cl->tx_done(chan->cl, mssg.data, r);
> >
> > - if (r != -ETIME && chan->cl->tx_block)
> > + if (r != -ETIME && chan->cl->tx_block) {
> > + *mssg.tx_status = r;
> > complete(mssg.tx_complete);
> > + }
> > }
> >
> > static enum hrtimer_restart txdone_hrtimer(struct hrtimer *hrtimer)
> > @@ -286,15 +293,16 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> > int t;
> > int idx;
> > struct completion tx_complete;
> > + int tx_status = 0;
> >
> > if (!chan || !chan->cl || mssg == MBOX_NO_MSG)
> > return -EINVAL;
> >
> > if (chan->cl->tx_block) {
> > init_completion(&tx_complete);
> > - t = add_to_rbuf(chan, mssg, &tx_complete);
> > + t = add_to_rbuf(chan, mssg, &tx_complete, &tx_status);
> > } else {
> > - t = add_to_rbuf(chan, mssg, NULL);
> > + t = add_to_rbuf(chan, mssg, NULL, NULL);
> > }
> >
> > if (t < 0) {
> > @@ -318,6 +326,8 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> > idx = t;
> > t = -ETIME;
> > tx_tick(chan, t, idx);
> > + } else if (tx_status < 0) {
> > + t = tx_status;
> > }
> > }
> >
> > diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
> > index 912499ad08ed..890da97bcb50 100644
> > --- a/include/linux/mailbox_controller.h
> > +++ b/include/linux/mailbox_controller.h
> > @@ -117,10 +117,12 @@ struct mbox_controller {
> > * struct mbox_message - Internal representation of a mailbox message
> > * @data: Data packet
> > * @tx_complete: Pointer to the transmission completion
> > + * @tx_status: Pointer to the transmission status
> > */
> > struct mbox_message {
> > void *data;
> > struct completion *tx_complete;
> > + int *tx_status;
> > };
> >
> > /**
> > --
> > 2.53.0.1185.g05d4b7b318-goog
> >
^ permalink raw reply
* Re: [PATCH V4 1/3] net: stmmac: Fix PTP ref clock for Tegra234
From: Simon Horman @ 2026-04-03 15:16 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, netdev, devicetree, linux-tegra
In-Reply-To: <20260401102941.17466-2-jonathanh@nvidia.com>
On Wed, Apr 01, 2026 at 11:29:39AM +0100, Jon Hunter wrote:
> Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not
> 0 before configuring timestamping") was added the following error is
> observed on Tegra234:
>
> ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
> WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
>
> It turns out that the Tegra234 device-tree binding defines the PTP ref
> clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now
> exposes this and that the PTP clock is not configured correctly.
>
> In order to update device-tree to use the correct 'ptp_ref' name, update
> the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using
> 'ptp-ref' if this clock name is present.
>
> Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
The nit below notwithstanding this looks good to me.
Reviewed-by: Simon Horman <horms@kernel.org>
> ---
> .../net/ethernet/stmicro/stmmac/dwmac-tegra.c | 20 +++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
> index b4b39e6a169e..3af2f001fada 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
...
> @@ -216,6 +216,7 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
> struct plat_stmmacenet_data *plat;
> struct stmmac_resources res;
> struct tegra_mgbe *mgbe;
> + bool use_legacy_ptp = false;
> int irq, err, i;
> u32 value;
>
nit: As this is Networking code, please retain reverse xmas tree order --
longest line to shortest -- for local variable declarations.
...
^ permalink raw reply
* Re: [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: Joonwon Kang @ 2026-04-03 14:51 UTC (permalink / raw)
To: jassisinghbrar
Cc: angelogioacchino.delregno, jonathanh, joonwonkang,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding
In-Reply-To: <CABb+yY0ub51k-eFpPfgARXtwYjWzRSjbPDLtoMD77YQR8JH+=Q@mail.gmail.com>
> On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> >
> > Previously, a sender thread in mbox_send_message() could be woken up at
> > a wrong time in blocking mode. It is because there was only a single
> > completion for a channel whereas messages from multiple threads could be
> > sent in any order; since the shared completion could be signalled in any
> > order, it could wake up a wrong sender thread.
> >
> > This commit resolves the false wake-up issue with the following changes:
> > - Completions are created just as many as the number of concurrent sender
> > threads
> > - A completion is created on a sender thread's stack
> > - Each slot of the message queue, i.e. `msg_data`, contains a pointer to
> > its target completion
> > - tx_tick() signals the completion of the currently active slot of the
> > message queue
> >
> I think I reviewed it already or is this happening on
> one-channel-one-client usage? Because mailbox api does not support
> channels shared among multiple clients.
Yes, this patch is handling the one-channel-one-client usage but when that
single channel is shared between multiple threads. From my understanding, the
discussion back then ended with how to circumvent the issue rather than whether
we will eventually solve this in the mailbox framework or not, and if yes, how
we will, and if not, why. I think it should still be resolved in the framework
for the reasons in the cover letter. Could you help to give a second review
with regards to those aspects?
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH] gpiolib: Make deferral warnings debug messages
From: Bartosz Golaszewski @ 2026-04-03 9:03 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jon Hunter
Cc: Bartosz Golaszewski, linux-gpio, linux-tegra
In-Reply-To: <20260401133441.47641-1-jonathanh@nvidia.com>
On Wed, 01 Apr 2026 14:34:41 +0100, Jon Hunter wrote:
> With the recent addition of the shared GPIO support, warning messages
> such as the following are being observed ...
>
> reg-fixed-voltage regulator-vdd-3v3-pcie: cannot find GPIO chip
> gpiolib_shared.proxy.6, deferring
>
> These are seen even with GPIO_SHARED_PROXY=y.
>
> [...]
Applied, thanks!
[1/1] gpiolib: Make deferral warnings debug messages
https://git.kernel.org/brgl/c/c0cd31bc3a92ac04147660a3821780f57b76bf1f
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [arm-tegra:for-7.1/pci 4/5] drivers/pci/controller/pcie-tegra264.c:228:27: warning: left shift count >= width of type
From: kernel test robot @ 2026-04-03 8:43 UTC (permalink / raw)
To: Thierry Reding; +Cc: oe-kbuild-all, linux-tegra, Manikanta Maddireddy
tree: https://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git for-7.1/pci
head: 9aa0c83c7374a1aa096bad5ae3260bb8bc62d0c1
commit: 270ae177795a7046f1e0ad2692f15b73b0ecf5d2 [4/5] PCI: tegra: Add Tegra264 support
config: openrisc-allmodconfig (https://download.01.org/0day-ci/archive/20260403/202604030544.CYytXhkh-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260403/202604030544.CYytXhkh-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604030544.CYytXhkh-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/pci/controller/pcie-tegra264.c: In function 'tegra264_pcie_check_ranges':
>> drivers/pci/controller/pcie-tegra264.c:228:27: warning: left shift count >= width of type [-Wshift-count-overflow]
228 | phys = hi << 32 | lo;
| ^~
drivers/pci/controller/pcie-tegra264.c:232:28: warning: left shift count >= width of type [-Wshift-count-overflow]
232 | limit = hi << 32 | lo | mask;
| ^~
drivers/pci/controller/pcie-tegra264.c:248:19: warning: left shift count >= width of type [-Wshift-count-overflow]
248 | phys = hi << 32 | lo;
| ^~
vim +228 drivers/pci/controller/pcie-tegra264.c
152
153 /*
154 * The various memory regions used by the controller (I/O, memory, ECAM) are
155 * set up during early boot and have hardware-level protections in place. If
156 * the DT ranges don't match what's been setup, the controller won't be able
157 * to write the address endpoints properly, so make sure to validate that DT
158 * and firmware programming agree on these ranges.
159 */
160 static bool tegra264_pcie_check_ranges(struct platform_device *pdev)
161 {
162 struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
163 struct device_node *np = pcie->dev->of_node;
164 struct of_pci_range_parser parser;
165 phys_addr_t phys, limit, hi, lo;
166 struct of_pci_range range;
167 struct resource *res;
168 bool status = true;
169 u32 value;
170 int err;
171
172 err = of_pci_range_parser_init(&parser, np);
173 if (err < 0)
174 return false;
175
176 for_each_of_pci_range(&parser, &range) {
177 unsigned int addr_hi, addr_lo, limit_hi, limit_lo, enable;
178 unsigned long type = range.flags & IORESOURCE_TYPE_BITS;
179 phys_addr_t start, end, mask;
180 const char *region = NULL;
181
182 end = range.cpu_addr + range.size - 1;
183 start = range.cpu_addr;
184
185 switch (type) {
186 case IORESOURCE_IO:
187 addr_hi = XAL_RC_IO_BASE_HI;
188 addr_lo = XAL_RC_IO_BASE_LO;
189 limit_hi = XAL_RC_IO_LIMIT_HI;
190 limit_lo = XAL_RC_IO_LIMIT_LO;
191 enable = XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN;
192 mask = SZ_64K - 1;
193 region = "I/O";
194 break;
195
196 case IORESOURCE_MEM:
197 if (range.flags & IORESOURCE_PREFETCH) {
198 addr_hi = XAL_RC_MEM_64BIT_BASE_HI;
199 addr_lo = XAL_RC_MEM_64BIT_BASE_LO;
200 limit_hi = XAL_RC_MEM_64BIT_LIMIT_HI;
201 limit_lo = XAL_RC_MEM_64BIT_LIMIT_LO;
202 enable = XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN;
203 region = "prefetchable memory";
204 } else {
205 addr_hi = XAL_RC_MEM_32BIT_BASE_HI;
206 addr_lo = XAL_RC_MEM_32BIT_BASE_LO;
207 limit_hi = XAL_RC_MEM_32BIT_LIMIT_HI;
208 limit_lo = XAL_RC_MEM_32BIT_LIMIT_LO;
209 enable = XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN;
210 region = "memory";
211 }
212
213 mask = SZ_1M - 1;
214 break;
215 }
216
217 /* not interested in anything that's not I/O or memory */
218 if (!region)
219 continue;
220
221 /* don't check regions that haven't been enabled */
222 value = readl(pcie->xal + XAL_RC_BAR_CNTL_STANDARD);
223 if ((value & enable) == 0)
224 continue;
225
226 hi = readl(pcie->xal + addr_hi);
227 lo = readl(pcie->xal + addr_lo);
> 228 phys = hi << 32 | lo;
229
230 hi = readl(pcie->xal + limit_hi);
231 lo = readl(pcie->xal + limit_lo);
232 limit = hi << 32 | lo | mask;
233
234 if (phys != start || limit != end) {
235 dev_err(pcie->dev,
236 "%s region mismatch: %pap-%pap -> %pap-%pap\n",
237 region, &phys, &limit, &start, &end);
238 status = false;
239 }
240 }
241
242 res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
243 if (!res)
244 return false;
245
246 hi = readl(pcie->xal + XAL_RC_ECAM_BASE_HI);
247 lo = readl(pcie->xal + XAL_RC_ECAM_BASE_LO);
248 phys = hi << 32 | lo;
249
250 value = readl(pcie->xal + XAL_RC_ECAM_BUSMASK);
251 limit = phys + ((value + 1) << 20) - 1;
252
253 if (phys != res->start || limit != res->end) {
254 dev_err(pcie->dev,
255 "ECAM region mismatch: %pap-%pap -> %pap-%pap\n",
256 &phys, &limit, &res->start, &res->end);
257 status = false;
258 }
259
260 return status;
261 }
262
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-04-03 7:39 UTC (permalink / raw)
To: Thierry Reding, arm, soc
Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <ac5aLzMyfnxa-LLi@orome>
On 02/04/2026 14:00, Thierry Reding wrote:
> On Sun, Mar 29, 2026 at 05:10:38PM +0200, Thierry Reding wrote:
>> From: Thierry Reding <thierry.reding@gmail.com>
>>
>> Hi ARM SoC maintainers,
>>
>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>>
>> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-dt-bindings
>>
>> for you to fetch changes up to bed2f5b4de6c6fd8f8928f6373ad92e8795c370f:
>>
>> dt-bindings: arm: tegra: Document Jetson AGX Thor DevKit (2026-03-28 01:05:24 +0100)
>>
>> Thanks,
>> Thierry
>>
>> ----------------------------------------------------------------
>> dt-bindings: Changes for v7.1-rc1
>>
>> This contains a few conversions to DT schema along with various
>> additions and fixes to reduce the amount of validation warnings.
>>
>> Included are also a new binding for the PCIe controller found on
>> Tegra264 as well as compatible strings for the Jetson AGX Thor
>> Developer Kit.
>>
>> ----------------------------------------------------------------
>> Sumit Gupta (1):
>> dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
>>
>> Svyatoslav Ryhel (1):
>> dt-bindings: display: tegra: Document Tegra20 HDMI port
>>
>> Thierry Reding (9):
>> dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
>> dt-bindings: phy: tegra-xusb: Document Type C support
>> dt-bindings: clock: tegra124-dfll: Convert to json-schema
>> dt-bindings: interrupt-controller: tegra: Fix reg entries
>> dt-bindings: arm: tegra: Add missing compatible strings
>> dt-bindings: phy: tegra: Document Tegra210 USB PHY
>> dt-bindings: memory: Add Tegra210 memory controller bindings
>> dt-bindings: memory: tegra210: Mark EMC as cooling device
>> dt-bindings: arm: tegra: Document Jetson AGX Thor DevKit
>>
>> Documentation/devicetree/bindings/arm/tegra.yaml | 56 +++-
>> .../bindings/arm/tegra/nvidia,tegra234-cbb.yaml | 4 +
>> .../bindings/clock/nvidia,tegra124-dfll.txt | 155 -----------
>> .../bindings/clock/nvidia,tegra124-dfll.yaml | 290 +++++++++++++++++++++
>> .../display/tegra/nvidia,tegra20-hdmi.yaml | 13 +-
>> .../interrupt-controller/nvidia,tegra20-ictlr.yaml | 23 +-
>> .../memory-controllers/nvidia,tegra210-emc.yaml | 6 +-
>> .../memory-controllers/nvidia,tegra210-mc.yaml | 77 ++++++
>> .../bindings/pci/nvidia,tegra264-pcie.yaml | 149 +++++++++++
>> .../bindings/phy/nvidia,tegra194-xusb-padctl.yaml | 39 ++-
>> .../bindings/phy/nvidia,tegra20-usb-phy.yaml | 1 +
>> 11 files changed, 649 insertions(+), 164 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
>> create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.yaml
>> create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-mc.yaml
>> create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
>
> Hi ARM SoC maintainers,
>
> Please ignore this for now. I'm dropping my set of patches from this
> because they upset the DT maintainers. I'll send another version with
> only Sumit and Svyatoslav's patches.
I plan to take this, because rejecting it won't improve anything and
patches seems to be non-conflicting. In the future, please do not filter
out addresses of other maintainers and their lists from
get_maintainers.pl output for patches belonging to their subsystems. If
the patchset becomes 50-Cc-patch-bomb, then standard rule of submitting
patches applies - should be split.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-04-03 7:35 UTC (permalink / raw)
To: Thierry Reding, arm, soc
Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <ac5ahWb1I-qnaK_Y@orome>
On 02/04/2026 14:02, Thierry Reding wrote:
> On Sun, Mar 29, 2026 at 05:10:43PM +0200, Thierry Reding wrote:
>> From: Thierry Reding <thierry.reding@gmail.com>
>>
>> Hi ARM SoC maintainers,
>>
>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>>
>> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm64-dt
>>
>> for you to fetch changes up to c70e6bc11d2008fbb19695394b69fd941ab39030:
>>
>> arm64: tegra: Add Tegra264 GPIO controllers (2026-03-28 01:36:46 +0100)
>>
>> Thanks,
>> Thierry
>>
>> ----------------------------------------------------------------
>> arm64: tegra: Device tree changes for v7.1-rc1
>>
>> Various fixes and new additions across a number of devices. GPIO and PCI
>> are enabled on Tegra264 and the Jetson AGX Thor Developer Kit, allowing
>> it to boot via network and mass storage.
>>
>> ----------------------------------------------------------------
>> Diogo Ivo (1):
>> arm64: tegra: smaug: Enable SPI-NOR flash
>>
>> Jon Hunter (1):
>> arm64: tegra: Fix RTC aliases
>>
>> Prathamesh Shete (1):
>> arm64: tegra: Add Tegra264 GPIO controllers
>>
>> Thierry Reding (6):
>> dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
>> Merge branch for-7.1/dt-bindings into for-7.1/pci
>> arm64: tegra: Fix snps,blen properties
>> arm64: tegra: Drop redundant clock and reset names for TSEC
>> arm64: tegra: Add PCI controllers on Tegra264
>> arm64: tegra: Add Jetson AGX Thor Developer Kit support
>>
>> .../bindings/pci/nvidia,tegra264-pcie.yaml | 149 +++++++++
>> arch/arm64/boot/dts/nvidia/Makefile | 2 +
>> arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 12 +
>> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 -
>> arch/arm64/boot/dts/nvidia/tegra234-p3701.dtsi | 1 +
>> arch/arm64/boot/dts/nvidia/tegra234-p3767.dtsi | 1 +
>> arch/arm64/boot/dts/nvidia/tegra234.dtsi | 6 +-
>> .../dts/nvidia/tegra264-p4071-0000+p3834-0008.dts | 11 +
>> .../boot/dts/nvidia/tegra264-p4071-0000+p3834.dtsi | 12 +
>> arch/arm64/boot/dts/nvidia/tegra264.dtsi | 336 +++++++++++++++++++--
>> 10 files changed, 500 insertions(+), 32 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
>> create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p4071-0000+p3834-0008.dts
>> create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p4071-0000+p3834.dtsi
>
> Hi ARM SoC maintainers,
>
> DT maintainers objected to the way I wanted to handle the DT bindings
> dependency here, so I'll drop the whole PCI stuff from this and redo the
> PR.
It took me ages to get that information from you but finally you pointed
me that this is shared with PCI, so it is fine.
Best regards,
Krzysztof
^ 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