* [PATCH v4 6/7] pwm: tegra: Add support for Tegra264
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
Tegra264 changes the register layout to accommodate wider fields
for duty and scale, and adds configurable depth which will be
supported in a later patch.
Add SoC data and update top comment to describe register layout
in more detail.
Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 75 ++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 61 insertions(+), 14 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index d7968521fbfd..c9d30724e339 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -7,22 +7,60 @@
* Copyright (c) 2010-2020, NVIDIA Corporation.
* Based on arch/arm/plat-mxc/pwm.c by Sascha Hauer <s.hauer@pengutronix.de>
*
- * Overview of Tegra Pulse Width Modulator Register:
- * 1. 13-bit: Frequency division (SCALE)
- * 2. 8-bit : Pulse division (DUTY)
- * 3. 1-bit : Enable bit
+ * Overview of Tegra Pulse Width Modulator Register
+ * CSR_0 of Tegra20, Tegra186, and Tegra194:
+ * +-------+-------+-----------------------------------------------------------+
+ * | Bit | Field | Description |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 31 | ENB | Enable Pulse width modulator. |
+ * | | | 0 = DISABLE, 1 = ENABLE. |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 30:16 | PWM_0 | Pulse width that needs to be programmed. |
+ * | | | 0 = Always low. |
+ * | | | 1 = 1 / 256 pulse high. |
+ * | | | 2 = 2 / 256 pulse high. |
+ * | | | N = N / 256 pulse high. |
+ * | | | Only 8 bits are usable [23:16]. |
+ * | | | Bit[24] can be programmed to 1 to achieve 100% duty |
+ * | | | cycle. In this case the other bits [23:16] are set to |
+ * | | | don’t care. |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 12:0 | PFM_0 | Frequency divider that needs to be programmed, also known |
+ * | | | as SCALE. Division by (1 + PFM_0). |
+ * +-------+-------+-----------------------------------------------------------+
*
- * The PWM clock frequency is divided by 256 before subdividing it based
- * on the programmable frequency division value to generate the required
- * frequency for PWM output. The maximum output frequency that can be
- * achieved is (max rate of source clock) / 256.
- * e.g. if source clock rate is 408 MHz, maximum output frequency can be:
- * 408 MHz/256 = 1.6 MHz.
- * This 1.6 MHz frequency can further be divided using SCALE value in PWM.
+ * CSR_0 of Tegra264:
+ * +-------+-------+-----------------------------------------------------------+
+ * | Bit | Field | Description |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 31:16 | PWM_0 | Pulse width that needs to be programmed. |
+ * | | | 0 = Always low. |
+ * | | | 1 = 1 / (1 + CSR_1.DEPTH) pulse high. |
+ * | | | 2 = 2 / (1 + CSR_1.DEPTH) pulse high. |
+ * | | | N = N / (1 + CSR_1.DEPTH) pulse high. |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 15:0 | PFM_0 | Frequency divider that needs to be programmed, also known |
+ * | | | as SCALE. Division by (1 + PFM_0). |
+ * +-------+-------+-----------------------------------------------------------+
+ *
+ * CSR_1 of Tegra264:
+ * +-------+-------+-----------------------------------------------------------+
+ * | Bit | Field | Description |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 31 | ENB | Enable Pulse width modulator. |
+ * | | | 0 = DISABLE, 1 = ENABLE. |
+ * +-------+-------+-----------------------------------------------------------+
+ * | 30:15 | DEPTH | Depth for pulse width modulator. This controls the pulse |
+ * | | | time generated. Division by (1 + CSR_1.DEPTH). |
+ * +-------+-------+-----------------------------------------------------------+
*
- * PWM pulse width: 8 bits are usable [23:16] for varying pulse width.
- * To achieve 100% duty cycle, program Bit [24] of this register to
- * 1’b1. In which case the other bits [23:16] are set to don't care.
+ * The PWM clock frequency is divided by DEPTH = (1 + CSR_1.DEPTH) before subdividing it
+ * based on the programmable frequency division value to generate the required frequency
+ * for PWM output. DEPTH is fixed to 256 before Tegra264. The maximum output frequency
+ * that can be achieved is (max rate of source clock) / DEPTH.
+ * e.g. if source clock rate is 408 MHz, and DEPTH = 256, maximum output frequency can be:
+ * 408 MHz / 256 ~= 1.6 MHz.
+ * This 1.6 MHz frequency can further be divided using SCALE value in PWM.
*
* Limitations:
* - When PWM is disabled, the output is driven to inactive.
@@ -56,6 +94,7 @@
#define PWM_SCALE_SHIFT 0
#define PWM_CSR_0 0
+#define PWM_CSR_1 4
#define PWM_DEPTH 256
@@ -418,10 +457,18 @@ static const struct tegra_pwm_soc tegra186_pwm_soc = {
.scale_width = 13,
};
+static const struct tegra_pwm_soc tegra264_pwm_soc = {
+ .num_channels = 1,
+ .enable_reg = PWM_CSR_1,
+ .duty_width = 16,
+ .scale_width = 16,
+};
+
static const struct of_device_id tegra_pwm_of_match[] = {
{ .compatible = "nvidia,tegra20-pwm", .data = &tegra20_pwm_soc },
{ .compatible = "nvidia,tegra186-pwm", .data = &tegra186_pwm_soc },
{ .compatible = "nvidia,tegra194-pwm", .data = &tegra186_pwm_soc },
+ { .compatible = "nvidia,tegra264-pwm", .data = &tegra264_pwm_soc },
{ }
};
MODULE_DEVICE_TABLE(of, tegra_pwm_of_match);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 5/7] pwm: tegra: Parametrize duty and scale field widths
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang,
Thierry Reding, Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
Tegra264 has wider fields for the duty and scale register fields.
Parameterize the driver in preparation. The depth value also
becomes disconnected from the width of the duty field, so define
it separately.
Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index b925ef914411..d7968521fbfd 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -52,16 +52,19 @@
#include <soc/tegra/common.h>
#define PWM_ENABLE (1 << 31)
-#define PWM_DUTY_WIDTH 8
#define PWM_DUTY_SHIFT 16
-#define PWM_SCALE_WIDTH 13
#define PWM_SCALE_SHIFT 0
#define PWM_CSR_0 0
+#define PWM_DEPTH 256
+
struct tegra_pwm_soc {
unsigned int num_channels;
unsigned int enable_reg;
+
+ unsigned int duty_width;
+ unsigned int scale_width;
};
struct tegra_pwm_chip {
@@ -106,22 +109,22 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
/*
* Convert from duty_ns / period_ns to a fixed number of duty ticks
- * per (1 << PWM_DUTY_WIDTH) cycles and make sure to round to the
+ * per PWM_DEPTH cycles and make sure to round to the
* nearest integer during division.
*/
- c *= (1 << PWM_DUTY_WIDTH);
+ c *= PWM_DEPTH;
c = DIV_ROUND_CLOSEST_ULL(c, period_ns);
val = (u32)c << PWM_DUTY_SHIFT;
/*
- * min period = max clock limit >> PWM_DUTY_WIDTH
+ * min period = max clock limit / PWM_DEPTH
*/
if (period_ns < pc->min_period_ns)
return -EINVAL;
/*
- * Compute the prescaler value for which (1 << PWM_DUTY_WIDTH)
+ * Compute the prescaler value for which PWM_DEPTH
* cycles at the PWM clock rate will take period_ns nanoseconds.
*
* num_channels: If single instance of PWM controller has multiple
@@ -135,7 +138,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
*/
if (pc->soc->num_channels == 1) {
/*
- * Rate is multiplied with 2^PWM_DUTY_WIDTH so that it matches
+ * Rate is multiplied with PWM_DEPTH so that it matches
* with the maximum possible rate that the controller can
* provide. Any further lower value can be derived by setting
* PFM bits[0:12].
@@ -145,7 +148,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
* source clock rate as required_clk_rate, PWM controller will
* be able to configure the requested period.
*/
- required_clk_rate = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC << PWM_DUTY_WIDTH,
+ required_clk_rate = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * PWM_DEPTH,
period_ns);
if (required_clk_rate > clk_round_rate(pc->clk, required_clk_rate))
@@ -169,7 +172,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
/* Consider precision in PWM_SCALE_WIDTH rate calculation */
rate = mul_u64_u64_div_u64(pc->clk_rate, period_ns,
- (u64)NSEC_PER_SEC << PWM_DUTY_WIDTH);
+ (u64)NSEC_PER_SEC * PWM_DEPTH);
/*
* Since the actual PWM divider is the register's frequency divider
@@ -185,7 +188,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
* Make sure that the rate will fit in the register's frequency
* divider field.
*/
- if (rate >> PWM_SCALE_WIDTH)
+ if (rate >> pc->soc->scale_width)
return -EINVAL;
val |= rate << PWM_SCALE_SHIFT;
@@ -324,7 +327,7 @@ static int tegra_pwm_probe(struct platform_device *pdev)
/* Set minimum limit of PWM period for the IP */
pc->min_period_ns =
- (NSEC_PER_SEC / (pc->clk_rate >> PWM_DUTY_WIDTH)) + 1;
+ (NSEC_PER_SEC / (pc->clk_rate / PWM_DEPTH)) + 1;
pc->rst = devm_reset_control_get_exclusive(&pdev->dev, "pwm");
if (IS_ERR(pc->rst)) {
@@ -404,11 +407,15 @@ static int __maybe_unused tegra_pwm_runtime_resume(struct device *dev)
static const struct tegra_pwm_soc tegra20_pwm_soc = {
.num_channels = 4,
.enable_reg = PWM_CSR_0,
+ .duty_width = 8,
+ .scale_width = 13,
};
static const struct tegra_pwm_soc tegra186_pwm_soc = {
.num_channels = 1,
.enable_reg = PWM_CSR_0,
+ .duty_width = 8,
+ .scale_width = 13,
};
static const struct of_device_id tegra_pwm_of_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/7] pwm: tegra: Parametrize enable register offset
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
On Tegra264, the PWM enablement bit is not located at the base address
of the PWM controller. Hence, introduce an enablement offset field in
the tegra_pwm_soc structure to describe the offset of the register.
Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index 358c81cea05b..b925ef914411 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -61,6 +61,7 @@
struct tegra_pwm_soc {
unsigned int num_channels;
+ unsigned int enable_reg;
};
struct tegra_pwm_chip {
@@ -197,8 +198,9 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
err = pm_runtime_resume_and_get(pwmchip_parent(chip));
if (err)
return err;
- } else
+ } else if (pc->soc->enable_reg == PWM_CSR_0) {
val |= PWM_ENABLE;
+ }
pwm_writel(pwm, PWM_CSR_0, val);
@@ -213,6 +215,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
static int tegra_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
int rc = 0;
u32 val;
@@ -220,20 +223,22 @@ static int tegra_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
if (rc)
return rc;
- val = pwm_readl(pwm, PWM_CSR_0);
+
+ val = pwm_readl(pwm, pc->soc->enable_reg);
val |= PWM_ENABLE;
- pwm_writel(pwm, PWM_CSR_0, val);
+ pwm_writel(pwm, pc->soc->enable_reg, val);
return 0;
}
static void tegra_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
u32 val;
- val = pwm_readl(pwm, PWM_CSR_0);
+ val = pwm_readl(pwm, pc->soc->enable_reg);
val &= ~PWM_ENABLE;
- pwm_writel(pwm, PWM_CSR_0, val);
+ pwm_writel(pwm, pc->soc->enable_reg, val);
pm_runtime_put_sync(pwmchip_parent(chip));
}
@@ -398,10 +403,12 @@ static int __maybe_unused tegra_pwm_runtime_resume(struct device *dev)
static const struct tegra_pwm_soc tegra20_pwm_soc = {
.num_channels = 4,
+ .enable_reg = PWM_CSR_0,
};
static const struct tegra_pwm_soc tegra186_pwm_soc = {
.num_channels = 1,
+ .enable_reg = PWM_CSR_0,
};
static const struct of_device_id tegra_pwm_of_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/7] pwm: tegra: Modify read/write accessors for multi-register channel
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
On Tegra264, each PWM instance has two registers (per channel, of which
there is one). Update the pwm_readl/pwm_writel helper functions to
take channel (as struct pwm_device *) and offset separately.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index 8a330169d531..358c81cea05b 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -57,6 +57,8 @@
#define PWM_SCALE_WIDTH 13
#define PWM_SCALE_SHIFT 0
+#define PWM_CSR_0 0
+
struct tegra_pwm_soc {
unsigned int num_channels;
};
@@ -78,14 +80,18 @@ static inline struct tegra_pwm_chip *to_tegra_pwm_chip(struct pwm_chip *chip)
return pwmchip_get_drvdata(chip);
}
-static inline u32 pwm_readl(struct tegra_pwm_chip *pc, unsigned int offset)
+static inline u32 pwm_readl(struct pwm_device *dev, unsigned int offset)
{
- return readl(pc->regs + (offset << 4));
+ struct tegra_pwm_chip *chip = to_tegra_pwm_chip(dev->chip);
+
+ return readl(chip->regs + (dev->hwpwm * 16) + offset);
}
-static inline void pwm_writel(struct tegra_pwm_chip *pc, unsigned int offset, u32 value)
+static inline void pwm_writel(struct pwm_device *dev, unsigned int offset, u32 value)
{
- writel(value, pc->regs + (offset << 4));
+ struct tegra_pwm_chip *chip = to_tegra_pwm_chip(dev->chip);
+
+ writel(value, chip->regs + (dev->hwpwm * 16) + offset);
}
static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -194,7 +200,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
} else
val |= PWM_ENABLE;
- pwm_writel(pc, pwm->hwpwm, val);
+ pwm_writel(pwm, PWM_CSR_0, val);
/*
* If the PWM is not enabled, turn the clock off again to save power.
@@ -207,7 +213,6 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
static int tegra_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
int rc = 0;
u32 val;
@@ -215,21 +220,20 @@ static int tegra_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
if (rc)
return rc;
- val = pwm_readl(pc, pwm->hwpwm);
+ val = pwm_readl(pwm, PWM_CSR_0);
val |= PWM_ENABLE;
- pwm_writel(pc, pwm->hwpwm, val);
+ pwm_writel(pwm, PWM_CSR_0, val);
return 0;
}
static void tegra_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
u32 val;
- val = pwm_readl(pc, pwm->hwpwm);
+ val = pwm_readl(pwm, PWM_CSR_0);
val &= ~PWM_ENABLE;
- pwm_writel(pc, pwm->hwpwm, val);
+ pwm_writel(pwm, PWM_CSR_0, val);
pm_runtime_put_sync(pwmchip_parent(chip));
}
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/7] pwm: tegra: Avoid hard-coded max clock frequency
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
From: Yi-Wei Wang <yiweiw@nvidia.com>
The clock driving the Tegra PWM IP can be sourced from different parent
clocks. Hence, let dev_pm_opp_set_rate() set the max clock rate based
upon the current parent clock that can be specified via device-tree.
After this, the Tegra194 SoC data becomes redundant, so get rid of it.
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/pwm/pwm-tegra.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index 172063b51d44..8a330169d531 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -59,9 +59,6 @@
struct tegra_pwm_soc {
unsigned int num_channels;
-
- /* Maximum IP frequency for given SoCs */
- unsigned long max_frequency;
};
struct tegra_pwm_chip {
@@ -303,7 +300,7 @@ static int tegra_pwm_probe(struct platform_device *pdev)
return ret;
/* Set maximum frequency of the IP */
- ret = dev_pm_opp_set_rate(&pdev->dev, pc->soc->max_frequency);
+ ret = dev_pm_opp_set_rate(&pdev->dev, ULONG_MAX);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to set max frequency: %d\n", ret);
goto put_pm;
@@ -318,7 +315,7 @@ static int tegra_pwm_probe(struct platform_device *pdev)
/* Set minimum limit of PWM period for the IP */
pc->min_period_ns =
- (NSEC_PER_SEC / (pc->soc->max_frequency >> PWM_DUTY_WIDTH)) + 1;
+ (NSEC_PER_SEC / (pc->clk_rate >> PWM_DUTY_WIDTH)) + 1;
pc->rst = devm_reset_control_get_exclusive(&pdev->dev, "pwm");
if (IS_ERR(pc->rst)) {
@@ -397,23 +394,16 @@ static int __maybe_unused tegra_pwm_runtime_resume(struct device *dev)
static const struct tegra_pwm_soc tegra20_pwm_soc = {
.num_channels = 4,
- .max_frequency = 48000000UL,
};
static const struct tegra_pwm_soc tegra186_pwm_soc = {
.num_channels = 1,
- .max_frequency = 102000000UL,
-};
-
-static const struct tegra_pwm_soc tegra194_pwm_soc = {
- .num_channels = 1,
- .max_frequency = 408000000UL,
};
static const struct of_device_id tegra_pwm_of_match[] = {
{ .compatible = "nvidia,tegra20-pwm", .data = &tegra20_pwm_soc },
{ .compatible = "nvidia,tegra186-pwm", .data = &tegra186_pwm_soc },
- { .compatible = "nvidia,tegra194-pwm", .data = &tegra194_pwm_soc },
+ { .compatible = "nvidia,tegra194-pwm", .data = &tegra186_pwm_soc },
{ }
};
MODULE_DEVICE_TABLE(of, tegra_pwm_of_match);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/7] Tegra264 PWM support
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen, Yi-Wei Wang
Hello,
this adds support for the PWM controller on Tegra264. The controller
is similar to previous generations, but the register fields are
widened, the depth is made configurable, and the enable bit moves
to a different spot.
This series adds only basic support with fixed depth -- configurable
depth will come later.
Patch 1 adds device tree bindings for Tegra264 PWM (compatible
string).
Patches 2 to 6 contain the PWM driver changes.
Patch 7 adds device tree nodes for the PWM controllers on Tegra264.
Thanks,
Mikko
---
Changes in v4:
- Use ULONG_MAX rather than S64_MAX to avoid overflow on 32-bit platforms
- Link to v3: https://lore.kernel.org/r/20260330-t264-pwm-v3-0-5714427d5976@nvidia.com
Changes in v3:
- Fixed device tree binding patch.
- Picked up trailers.
- Link to v2: https://lore.kernel.org/r/20260325-t264-pwm-v2-0-998d885984b3@nvidia.com
Changes in v2:
- Added device tree binding and Tegra264 device tree patches by Thierry.
- Link to v1: https://lore.kernel.org/r/20260323-t264-pwm-v1-0-4c4ff743050f@nvidia.com
---
Mikko Perttunen (4):
pwm: tegra: Modify read/write accessors for multi-register channel
pwm: tegra: Parametrize enable register offset
pwm: tegra: Parametrize duty and scale field widths
pwm: tegra: Add support for Tegra264
Thierry Reding (2):
dt-bindings: pwm: Document Tegra264 controller
arm64: tegra: Add PWM controllers on Tegra264
Yi-Wei Wang (1):
pwm: tegra: Avoid hard-coded max clock frequency
.../bindings/pwm/nvidia,tegra20-pwm.yaml | 1 +
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 72 +++++++++++
drivers/pwm/pwm-tegra.c | 141 ++++++++++++++-------
3 files changed, 171 insertions(+), 43 deletions(-)
---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20260303-t264-pwm-57e10d039df1
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: pwm: Document Tegra264 controller
From: Mikko Perttunen @ 2026-03-31 2:12 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Add a new compatible string for the PWM controller found on Tegra264.
The controller is similar to earlier generations but not compatible
with them.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[mperttunen: Drop extra Tegra194 compatible string]
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
index 41cea4979132..cb2f36e7b5d6 100644
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
@@ -16,6 +16,7 @@ properties:
- enum:
- nvidia,tegra20-pwm
- nvidia,tegra186-pwm
+ - nvidia,tegra264-pwm
- items:
- enum:
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] staging: nvec: validate battery response length before memcpy
From: kernel test robot @ 2026-03-30 23:05 UTC (permalink / raw)
To: Sebastian Josue Alba Vives, gregkh
Cc: oe-kbuild-all, marvin24, linux-staging, ac100, linux-tegra,
linux-kernel, stable, Sebastián Alba Vives
In-Reply-To: <20260330060926.751031-1-sebasjosue84@gmail.com>
Hi Sebastian,
kernel test robot noticed the following build warnings:
[auto build test WARNING on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/Sebastian-Josue-Alba-Vives/staging-nvec-validate-battery-response-length-before-memcpy/20260330-174322
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260330060926.751031-1-sebasjosue84%40gmail.com
patch subject: [PATCH v2] staging: nvec: validate battery response length before memcpy
config: arm64-randconfig-r054-20260331 (https://download.01.org/0day-ci/archive/20260331/202603310649.6iHw5wAQ-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 9.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603310649.6iHw5wAQ-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/202603310649.6iHw5wAQ-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/staging/nvec/nvec_power.c: In function 'nvec_power_bat_notifier':
drivers/staging/nvec/nvec_power.c:237:12: error: invalid storage class for function 'nvec_power_get_property'
237 | static int nvec_power_get_property(struct power_supply *psy,
| ^~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:253:12: error: invalid storage class for function 'nvec_battery_get_property'
253 | static int nvec_battery_get_property(struct power_supply *psy,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:344:18: error: initializer element is not constant
344 | .get_property = nvec_battery_get_property,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:344:18: note: (near initialization for 'nvec_bat_psy_desc.get_property')
drivers/staging/nvec/nvec_power.c:352:18: error: initializer element is not constant
352 | .get_property = nvec_power_get_property,
| ^~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:352:18: note: (near initialization for 'nvec_psy_desc.get_property')
drivers/staging/nvec/nvec_power.c:363:13: error: invalid storage class for function 'nvec_power_poll'
363 | static void nvec_power_poll(struct work_struct *work)
| ^~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:387:12: error: invalid storage class for function 'nvec_power_probe'
387 | static int nvec_power_probe(struct platform_device *pdev)
| ^~~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:434:13: error: invalid storage class for function 'nvec_power_remove'
434 | static void nvec_power_remove(struct platform_device *pdev)
| ^~~~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:450:11: error: initializer element is not constant
450 | .probe = nvec_power_probe,
| ^~~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:450:11: note: (near initialization for 'nvec_power_driver.probe')
drivers/staging/nvec/nvec_power.c:451:12: error: initializer element is not constant
451 | .remove = nvec_power_remove,
| ^~~~~~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:451:12: note: (near initialization for 'nvec_power_driver.remove')
In file included from include/linux/device.h:32,
from include/linux/platform_device.h:13,
from drivers/staging/nvec/nvec_power.c:12:
drivers/staging/nvec/nvec_power.c:457:24: error: invalid storage class for function 'nvec_power_driver_init'
457 | module_platform_driver(nvec_power_driver);
| ^~~~~~~~~~~~~~~~~
include/linux/device/driver.h:267:19: note: in definition of macro 'module_driver'
267 | static int __init __driver##_init(void) \
| ^~~~~~~~
drivers/staging/nvec/nvec_power.c:457:1: note: in expansion of macro 'module_platform_driver'
457 | module_platform_driver(nvec_power_driver);
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/staging/nvec/nvec_power.c:11:
include/linux/module.h:132:42: error: invalid storage class for function '__inittest'
132 | static inline initcall_t __maybe_unused __inittest(void) \
| ^~~~~~~~~~
include/linux/device/driver.h:271:1: note: in expansion of macro 'module_init'
271 | module_init(__driver##_init); \
| ^~~~~~~~~~~
include/linux/platform_device.h:295:2: note: in expansion of macro 'module_driver'
295 | module_driver(__platform_driver, platform_driver_register, \
| ^~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:457:1: note: in expansion of macro 'module_platform_driver'
457 | module_platform_driver(nvec_power_driver);
| ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/staging/nvec/nvec_power.c:457:1: warning: 'alias' attribute ignored [-Wattributes]
In file included from include/linux/device.h:32,
from include/linux/platform_device.h:13,
from drivers/staging/nvec/nvec_power.c:12:
drivers/staging/nvec/nvec_power.c:457:24: error: invalid storage class for function 'nvec_power_driver_exit'
457 | module_platform_driver(nvec_power_driver);
| ^~~~~~~~~~~~~~~~~
include/linux/device/driver.h:272:20: note: in definition of macro 'module_driver'
272 | static void __exit __driver##_exit(void) \
| ^~~~~~~~
drivers/staging/nvec/nvec_power.c:457:1: note: in expansion of macro 'module_platform_driver'
457 | module_platform_driver(nvec_power_driver);
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/staging/nvec/nvec_power.c:11:
include/linux/module.h:140:42: error: invalid storage class for function '__exittest'
140 | static inline exitcall_t __maybe_unused __exittest(void) \
| ^~~~~~~~~~
include/linux/device/driver.h:276:1: note: in expansion of macro 'module_exit'
276 | module_exit(__driver##_exit);
| ^~~~~~~~~~~
include/linux/platform_device.h:295:2: note: in expansion of macro 'module_driver'
295 | module_driver(__platform_driver, platform_driver_register, \
| ^~~~~~~~~~~~~
drivers/staging/nvec/nvec_power.c:457:1: note: in expansion of macro 'module_platform_driver'
457 | module_platform_driver(nvec_power_driver);
| ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/staging/nvec/nvec_power.c:457:1: warning: 'alias' attribute ignored [-Wattributes]
drivers/staging/nvec/nvec_power.c:462:1: error: expected declaration or statement at end of input
462 | MODULE_ALIAS("platform:nvec-power");
| ^~~~~~~~~~~~
vim +/alias +457 drivers/staging/nvec/nvec_power.c
32890b983086136 Marc Dietrich 2011-05-19 456
9891b1ce6276912 Marc Dietrich 2012-06-24 @457 module_platform_driver(nvec_power_driver);
32890b983086136 Marc Dietrich 2011-05-19 458
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Jon Hunter @ 2026-03-30 20:15 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Manivannan Sadhasivam, mark.rutland, bjorn.andersson,
konrad.dybcio, mani, linux-arm-kernel, linux-kernel,
Konrad Dybcio, Konrad Dybcio, Sudeep Holla,
linux-tegra@vger.kernel.org
In-Reply-To: <acJPHGIW1fb7whsu@lpieralisi>
Hi Lorenzo,
On 24/03/2026 08:45, Lorenzo Pieralisi wrote:
...
>>> I wanted to ask what the status of this patch is?
>>>
>>> It turns out that since commit f3ac2ff14834 ("PCI/ASPM: Enable all
>>> ClockPM and ASPM states for devicetree platforms"), this fix is also
>>> need for Tegra platforms that have NVMe devices to ensure that they are
>>> suspended as needed. There is some more background in this thread [0].
>>
>>
>> Any feedback on this? I am not sure if this patch is purposely being
>> ignored, but if so, I would like to understand why.
>
> It fell through the cracks, apologies.
No worries. Do you plan to pick this up?
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 2/3] hte: tegra194: Add Tegra264 GTE support
From: Krzysztof Kozlowski @ 2026-03-30 19:33 UTC (permalink / raw)
To: Dipen Patel, Suneel Garapati, jonathanh, thierry.reding, krzk+dt,
conor+dt, amhetre, sheetal, kkarthik, timestamp, devicetree,
linux-tegra, linux-kernel, robh
In-Reply-To: <42ef5cb5-1db4-4faf-93f5-beefc0d321de@nvidia.com>
On 30/03/2026 21:32, Dipen Patel wrote:
> On 3/30/26 11:39 AM, Krzysztof Kozlowski wrote:
>> On 30/03/2026 20:35, Dipen Patel wrote:
>>>> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
>>
>> Please kindly trim the replies from unnecessary context. It makes it
>> much easier to find new content.
>>
>>> Acked-by: Dipen Patel <dipenp@nvidia.com>
>>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
>>
>> What are you certifying here with SoB?
> I was preemptively adding my SoB since I had to integrate this patch into my HTE
> subsystem tree. But for now, please ignore my SoB.
So you wanted to say that you applied a patch? Why not sending ty
letters with b4?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] hte: tegra194: Add Tegra264 GTE support
From: Dipen Patel @ 2026-03-30 19:32 UTC (permalink / raw)
To: Krzysztof Kozlowski, Suneel Garapati, jonathanh, thierry.reding,
krzk+dt, conor+dt, amhetre, sheetal, kkarthik, timestamp,
devicetree, linux-tegra, linux-kernel, robh
In-Reply-To: <3f88abb3-fcc4-4d73-b003-84fc0bd28306@kernel.org>
On 3/30/26 11:39 AM, Krzysztof Kozlowski wrote:
> On 30/03/2026 20:35, Dipen Patel wrote:
>>> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
>
> Please kindly trim the replies from unnecessary context. It makes it
> much easier to find new content.
>
>> Acked-by: Dipen Patel <dipenp@nvidia.com>
>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
>
> What are you certifying here with SoB?
I was preemptively adding my SoB since I had to integrate this patch into my HTE
subsystem tree. But for now, please ignore my SoB.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] hte: tegra194: Add Tegra264 GTE support
From: Krzysztof Kozlowski @ 2026-03-30 18:39 UTC (permalink / raw)
To: Dipen Patel, Suneel Garapati, jonathanh, thierry.reding, krzk+dt,
conor+dt, amhetre, sheetal, kkarthik, timestamp, devicetree,
linux-tegra, linux-kernel, robh
In-Reply-To: <6bbff5d0-c75d-42ef-8877-de60e7113db4@nvidia.com>
On 30/03/2026 20:35, Dipen Patel wrote:
>> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
Please kindly trim the replies from unnecessary context. It makes it
much easier to find new content.
> Acked-by: Dipen Patel <dipenp@nvidia.com>
> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
What are you certifying here with SoB?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] hte: tegra194: Add Tegra264 GTE support
From: Dipen Patel @ 2026-03-30 18:35 UTC (permalink / raw)
To: Suneel Garapati, jonathanh, thierry.reding, krzk+dt, conor+dt,
amhetre, sheetal, kkarthik, timestamp, devicetree, linux-tegra,
linux-kernel, robh
In-Reply-To: <20260330170657.185854-3-suneelg@nvidia.com>
On 3/30/26 10:06 AM, Suneel Garapati wrote:
> Add AON-GTE mapping and LIC GTE instance support for the Tegra264.
> Move TSC clock parameters from macros to members of SoC data
> as values differ for Tegra264 chip.
>
> Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
> ---
> drivers/hte/hte-tegra194.c | 133 +++++++++++++++++++++++++++++++++++--
> 1 file changed, 128 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
> index 690eb9be30fb..4a7702b32b24 100644
> --- a/drivers/hte/hte-tegra194.c
> +++ b/drivers/hte/hte-tegra194.c
> @@ -20,10 +20,11 @@
>
> #define HTE_SUSPEND 0
>
> -/* HTE source clock TSC is 31.25MHz */
> +/* HTE source clock TSC is 1GHz for T264 and 31.25MHz for others */
> #define HTE_TS_CLK_RATE_HZ 31250000ULL
> +#define HTE_TS_CLK_RATE_1G 1000000000ULL
> #define HTE_CLK_RATE_NS 32
> -#define HTE_TS_NS_SHIFT __builtin_ctz(HTE_CLK_RATE_NS)
> +#define HTE_CLK_RATE_NS_1G 1
>
> #define NV_AON_SLICE_INVALID -1
> #define NV_LINES_IN_SLICE 32
> @@ -120,6 +121,8 @@ struct tegra_hte_data {
> u32 slices;
> u32 map_sz;
> u32 sec_map_sz;
> + u64 tsc_clkrate_hz;
> + u32 tsc_clkrate_ns;
> const struct tegra_hte_line_mapped *map;
> const struct tegra_hte_line_mapped *sec_map;
> };
> @@ -317,6 +320,94 @@ static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
> [40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> };
>
> +static const struct tegra_hte_line_mapped tegra264_aon_gpio_map[] = {
> + /* gpio, slice, bit_index */
> + /* AA port */
> + [0] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
> + [1] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
> + [2] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
> + [3] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
> + [4] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
> + [5] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
> + [6] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> + [7] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
> + /* BB port */
> + [8] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
> + [9] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
> + /* CC port */
> + [10] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
> + [11] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
> + [12] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
> + [13] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
> + [14] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
> + [15] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
> + [16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
> + [17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
> + /* DD port */
> + [18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
> + [19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
> + [20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
> + [21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
> + [22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
> + [23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
> + [24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
> + [25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
> + /* EE port */
> + [26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
> + [27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
> + [28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
> + [29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
> +};
> +
> +static const struct tegra_hte_line_mapped tegra264_aon_gpio_sec_map[] = {
> + /* gpio, slice, bit_index */
> + /* AA port */
> + [0] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
> + [1] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
> + [2] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
> + [3] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
> + [4] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
> + [5] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
> + [6] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> + [7] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
> + /* BB port */
> + [8] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
> + [9] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
> + [10] = {NV_AON_SLICE_INVALID, 0},
> + [11] = {NV_AON_SLICE_INVALID, 0},
> + [12] = {NV_AON_SLICE_INVALID, 0},
> + [13] = {NV_AON_SLICE_INVALID, 0},
> + [14] = {NV_AON_SLICE_INVALID, 0},
> + [15] = {NV_AON_SLICE_INVALID, 0},
> + /* CC port */
> + [16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
> + [17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
> + [18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
> + [19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
> + [20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
> + [21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
> + [22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
> + [23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
> + /* DD port */
> + [24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
> + [25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
> + [26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
> + [27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
> + [28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
> + [29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
> + [30] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
> + [31] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
> + /* EE port */
> + [32] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
> + [33] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
> + [34] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
> + [35] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
> + [36] = {NV_AON_SLICE_INVALID, 0},
> + [37] = {NV_AON_SLICE_INVALID, 0},
> + [38] = {NV_AON_SLICE_INVALID, 0},
> + [39] = {NV_AON_SLICE_INVALID, 0},
> +};
> +
> static const struct tegra_hte_data t194_aon_hte = {
> .map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
> .map = tegra194_aon_gpio_map,
> @@ -324,6 +415,8 @@ static const struct tegra_hte_data t194_aon_hte = {
> .sec_map = tegra194_aon_gpio_sec_map,
> .type = HTE_TEGRA_TYPE_GPIO,
> .slices = 3,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> };
>
> static const struct tegra_hte_data t234_aon_hte = {
> @@ -333,6 +426,19 @@ static const struct tegra_hte_data t234_aon_hte = {
> .sec_map = tegra234_aon_gpio_sec_map,
> .type = HTE_TEGRA_TYPE_GPIO,
> .slices = 3,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> +};
> +
> +static const struct tegra_hte_data t264_aon_hte = {
> + .map_sz = ARRAY_SIZE(tegra264_aon_gpio_map),
> + .map = tegra264_aon_gpio_map,
> + .sec_map_sz = ARRAY_SIZE(tegra264_aon_gpio_sec_map),
> + .sec_map = tegra264_aon_gpio_sec_map,
> + .type = HTE_TEGRA_TYPE_GPIO,
> + .slices = 4,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
> };
>
> static const struct tegra_hte_data t194_lic_hte = {
> @@ -340,6 +446,8 @@ static const struct tegra_hte_data t194_lic_hte = {
> .map = NULL,
> .type = HTE_TEGRA_TYPE_LIC,
> .slices = 11,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> };
>
> static const struct tegra_hte_data t234_lic_hte = {
> @@ -347,6 +455,17 @@ static const struct tegra_hte_data t234_lic_hte = {
> .map = NULL,
> .type = HTE_TEGRA_TYPE_LIC,
> .slices = 17,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> +};
> +
> +static const struct tegra_hte_data t264_lic_hte = {
> + .map_sz = 0,
> + .map = NULL,
> + .type = HTE_TEGRA_TYPE_LIC,
> + .slices = 10,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
> };
>
> static inline u32 tegra_hte_readl(struct tegra_hte_soc *hte, u32 reg)
> @@ -574,12 +693,12 @@ static int tegra_hte_release(struct hte_chip *chip, struct hte_ts_desc *desc,
> static int tegra_hte_clk_src_info(struct hte_chip *chip,
> struct hte_clk_info *ci)
> {
> - (void)chip;
> + struct tegra_hte_soc *hte_dev = chip->data;
>
> if (!ci)
> return -EINVAL;
>
> - ci->hz = HTE_TS_CLK_RATE_HZ;
> + ci->hz = hte_dev->prov_data->tsc_clkrate_hz;
> ci->type = CLOCK_MONOTONIC;
>
> return 0;
> @@ -602,8 +721,10 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
> {
> u32 tsh, tsl, src, pv, cv, acv, slice, bit_index, line_id;
> u64 tsc;
> + u8 tsc_ns_shift;
> struct hte_ts_data el;
>
> + tsc_ns_shift = __builtin_ctz(gs->prov_data->tsc_clkrate_ns);
> while ((tegra_hte_readl(gs, HTE_TESTATUS) >>
> HTE_TESTATUS_OCCUPANCY_SHIFT) &
> HTE_TESTATUS_OCCUPANCY_MASK) {
> @@ -621,7 +742,7 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
> while (acv) {
> bit_index = __builtin_ctz(acv);
> line_id = bit_index + (slice << 5);
> - el.tsc = tsc << HTE_TS_NS_SHIFT;
> + el.tsc = tsc << tsc_ns_shift;
> el.raw_level = tegra_hte_get_level(gs, line_id);
> hte_push_ts_ns(gs->chip, line_id, &el);
> acv &= ~BIT(bit_index);
> @@ -656,6 +777,8 @@ static const struct of_device_id tegra_hte_of_match[] = {
> { .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
> { .compatible = "nvidia,tegra234-gte-lic", .data = &t234_lic_hte},
> { .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
> + { .compatible = "nvidia,tegra264-gte-lic", .data = &t264_lic_hte},
> + { .compatible = "nvidia,tegra264-gte-aon", .data = &t264_aon_hte},
> { }
> };
> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
Acked-by: Dipen Patel <dipenp@nvidia.com>
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
^ permalink raw reply
* Re: [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Akhil R @ 2026-03-30 18:20 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, akhilrajeev, conor+dt, devicetree, dmaengine, jonathanh,
krzk+dt, ldewangan, linux-kernel, linux-tegra, p.zabel, robh,
thierry.reding, vkoul
In-Reply-To: <acq9z3-lqBHY78v3@lizhi-Precision-Tower-5810>
On Mon, 30 Mar 2026 14:15:43 -0400, Frank Li wrote:
> On Mon, Mar 30, 2026 at 11:32:40PM +0530, Akhil R wrote:
>> On Mon, 30 Mar 2026 12:47:24 -0400, Frank Li wrote:
>> > On Mon, Mar 30, 2026 at 08:14:54PM +0530, Akhil R wrote:
>> >> Use 'iommu-map', when provided, to get the stream ID to be programmed
>> >> for each channel. Iterate over the channels registered and configure
>> >> each channel device separately using of_dma_configure_id() to allow
>> >> it to use a separate IOMMU domain for the transfer. However, do this
>> >> in a second loop since the first loop populates the DMA device channels
>> >> list and async_device_register() registers the channels. Both are
>> >> prerequisites for using the channel device in the next loop.
>> >>
>> >> Channels will continue to use the same global stream ID if the
>> >> 'iommu-map' property is not present in the device tree.
>> >>
>> >> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> >> ---
>> > ...
>> >>
>> >> + /*
>> >> + * Configure stream ID for each channel from the channels registered
>> >> + * above. This is done in a separate iteration to ensure that only
>> >> + * the channels available and registered for the DMA device are used.
>> >> + */
>> >> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
>> >> + chdev = &chan->dev->device;
>> >> + tdc = to_tegra_dma_chan(chan);
>> >> +
>> >> + if (use_iommu_map) {
>> >> + chdev->bus = pdev->dev.bus;
>> >> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
>> >> +
>> >> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
>> >> + true, &tdc->id);
>> >> + if (ret)
>> >> + return dev_err_probe(chdev, ret,
>> >> + "Failed to configure IOMMU for channel %d", tdc->id);
>> >> +
>> >> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
>> >> + dev_err(chdev, "Failed to get stream ID for channel %d\n",
>> >> + tdc->id);
>> >> + return -EINVAL;
>> >
>> > Can you check similar problem before post patch, here also can use
>> > return dev_err_probe()
>>
>> I did notice that, but I thought dev_err_probe is to handle -EPROBE_DEFER
>> and we do not use it when we return a fixed value. It returns -EINVAL here
>> directly.
>
> even that, still can use return dev_err_probe(chddev, -EINVAL, ...) to
> short your code.
I just saw in the dev_err_probe() description that it is not limited to
-EPROBE_DEFER. Thanks for pointing. I will update the patch.
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Frank Li @ 2026-03-30 18:15 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, conor+dt, devicetree, dmaengine, jonathanh, krzk+dt,
ldewangan, linux-kernel, linux-tegra, p.zabel, robh,
thierry.reding, vkoul
In-Reply-To: <20260330180240.29906-1-akhilrajeev@nvidia.com>
On Mon, Mar 30, 2026 at 11:32:40PM +0530, Akhil R wrote:
> On Mon, 30 Mar 2026 12:47:24 -0400, Frank Li wrote:
> > On Mon, Mar 30, 2026 at 08:14:54PM +0530, Akhil R wrote:
> >> Use 'iommu-map', when provided, to get the stream ID to be programmed
> >> for each channel. Iterate over the channels registered and configure
> >> each channel device separately using of_dma_configure_id() to allow
> >> it to use a separate IOMMU domain for the transfer. However, do this
> >> in a second loop since the first loop populates the DMA device channels
> >> list and async_device_register() registers the channels. Both are
> >> prerequisites for using the channel device in the next loop.
> >>
> >> Channels will continue to use the same global stream ID if the
> >> 'iommu-map' property is not present in the device tree.
> >>
> >> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> >> ---
> > ...
> >>
> >> + /*
> >> + * Configure stream ID for each channel from the channels registered
> >> + * above. This is done in a separate iteration to ensure that only
> >> + * the channels available and registered for the DMA device are used.
> >> + */
> >> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
> >> + chdev = &chan->dev->device;
> >> + tdc = to_tegra_dma_chan(chan);
> >> +
> >> + if (use_iommu_map) {
> >> + chdev->bus = pdev->dev.bus;
> >> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
> >> +
> >> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
> >> + true, &tdc->id);
> >> + if (ret)
> >> + return dev_err_probe(chdev, ret,
> >> + "Failed to configure IOMMU for channel %d", tdc->id);
> >> +
> >> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
> >> + dev_err(chdev, "Failed to get stream ID for channel %d\n",
> >> + tdc->id);
> >> + return -EINVAL;
> >
> > Can you check similar problem before post patch, here also can use
> > return dev_err_probe()
>
> I did notice that, but I thought dev_err_probe is to handle -EPROBE_DEFER
> and we do not use it when we return a fixed value. It returns -EINVAL here
> directly.
even that, still can use return dev_err_probe(chddev, -EINVAL, ...) to
short your code.
Frank
>
> Best Regards,
> Akhil
^ permalink raw reply
* Re: [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Akhil R @ 2026-03-30 18:02 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, akhilrajeev, conor+dt, devicetree, dmaengine, jonathanh,
krzk+dt, ldewangan, linux-kernel, linux-tegra, p.zabel, robh,
thierry.reding, vkoul
In-Reply-To: <acqpHJM3eilwyMMy@lizhi-Precision-Tower-5810>
On Mon, 30 Mar 2026 12:47:24 -0400, Frank Li wrote:
> On Mon, Mar 30, 2026 at 08:14:54PM +0530, Akhil R wrote:
>> Use 'iommu-map', when provided, to get the stream ID to be programmed
>> for each channel. Iterate over the channels registered and configure
>> each channel device separately using of_dma_configure_id() to allow
>> it to use a separate IOMMU domain for the transfer. However, do this
>> in a second loop since the first loop populates the DMA device channels
>> list and async_device_register() registers the channels. Both are
>> prerequisites for using the channel device in the next loop.
>>
>> Channels will continue to use the same global stream ID if the
>> 'iommu-map' property is not present in the device tree.
>>
>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> ---
> ...
>>
>> + /*
>> + * Configure stream ID for each channel from the channels registered
>> + * above. This is done in a separate iteration to ensure that only
>> + * the channels available and registered for the DMA device are used.
>> + */
>> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
>> + chdev = &chan->dev->device;
>> + tdc = to_tegra_dma_chan(chan);
>> +
>> + if (use_iommu_map) {
>> + chdev->bus = pdev->dev.bus;
>> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
>> +
>> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
>> + true, &tdc->id);
>> + if (ret)
>> + return dev_err_probe(chdev, ret,
>> + "Failed to configure IOMMU for channel %d", tdc->id);
>> +
>> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
>> + dev_err(chdev, "Failed to get stream ID for channel %d\n",
>> + tdc->id);
>> + return -EINVAL;
>
> Can you check similar problem before post patch, here also can use
> return dev_err_probe()
I did notice that, but I thought dev_err_probe is to handle -EPROBE_DEFER
and we do not use it when we return a fixed value. It returns -EINVAL here
directly.
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Frank Li @ 2026-03-30 16:47 UTC (permalink / raw)
To: Akhil R
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260330144456.13551-9-akhilrajeev@nvidia.com>
On Mon, Mar 30, 2026 at 08:14:54PM +0530, Akhil R wrote:
> Use 'iommu-map', when provided, to get the stream ID to be programmed
> for each channel. Iterate over the channels registered and configure
> each channel device separately using of_dma_configure_id() to allow
> it to use a separate IOMMU domain for the transfer. However, do this
> in a second loop since the first loop populates the DMA device channels
> list and async_device_register() registers the channels. Both are
> prerequisites for using the channel device in the next loop.
>
> Channels will continue to use the same global stream ID if the
> 'iommu-map' property is not present in the device tree.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
...
>
> + /*
> + * Configure stream ID for each channel from the channels registered
> + * above. This is done in a separate iteration to ensure that only
> + * the channels available and registered for the DMA device are used.
> + */
> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
> + chdev = &chan->dev->device;
> + tdc = to_tegra_dma_chan(chan);
> +
> + if (use_iommu_map) {
> + chdev->bus = pdev->dev.bus;
> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
> +
> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
> + true, &tdc->id);
> + if (ret)
> + return dev_err_probe(chdev, ret,
> + "Failed to configure IOMMU for channel %d", tdc->id);
> +
> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
> + dev_err(chdev, "Failed to get stream ID for channel %d\n",
> + tdc->id);
> + return -EINVAL;
Can you check similar problem before post patch, here also can use
return dev_err_probe()
Frank
> + }
> +
> + chan->dev->chan_dma_dev = true;
> + }
> +
> + /* program stream-id for this channel */
> + tegra_dma_program_sid(tdc, stream_id);
> + tdc->stream_id = stream_id;
> + }
> +
> ret = devm_of_dma_controller_register(&pdev->dev, pdev->dev.of_node,
> tegra_dma_of_xlate, tdma);
> if (ret < 0) {
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH v3] staging: nvec: validate battery response length before memcpy
From: Greg KH @ 2026-03-30 15:51 UTC (permalink / raw)
To: Sebastian Josue Alba Vives
Cc: marvin24, linux-staging, linux-tegra, linux-kernel, stable,
kernel test robot
In-Reply-To: <20260330125200.820693-1-sebasjosue84@gmail.com>
On Mon, Mar 30, 2026 at 06:52:00AM -0600, Sebastian Josue Alba Vives wrote:
> From: Sebastián Alba Vives <sebasjosue84@gmail.com>
>
> In nvec_power_notifier(), the response length from the embedded
> controller is used directly as the size argument to memcpy() when
> copying battery manufacturer, model, and type strings. The
> destination buffers (bat_manu, bat_model, bat_type) are fixed at
> 30 bytes, but res->length is a u8 that can be up to 255, allowing
> a heap buffer overflow.
How can the embedded controller send data that is not correct? It is
trusted, right?
> Additionally, if res->length is less than 2, the subtraction
> res->length - 2 wraps around as an unsigned value, resulting in a
> large copy that corrupts kernel heap memory.
>
> Introduce NVEC_BAT_STRING_SIZE to replace the hardcoded buffer
> size, store res->length - 2 in a local copy_len variable for
> clarity, and add bounds checks before each memcpy to ensure the
> copy length does not exceed the destination buffer and that
> res->length is at least 2 to prevent unsigned integer underflow.
Is this the only data that needs to be validated from the controller?
> Reported-by: kernel test robot <lkp@intel.com>
The kernel test robot did not report these buffer size issues :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: nvec: fix comment formatting
From: Greg Kroah-Hartman @ 2026-03-30 15:50 UTC (permalink / raw)
To: Cameron Pinchin
Cc: Marc Dietrich,
moderated list:STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER...,
open list:STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER...,
open list:STAGING SUBSYSTEM, open list, CameronPinchin
In-Reply-To: <20260322023346.100296-1-c.w.pinchin@gmail.com>
On Sat, Mar 21, 2026 at 10:33:46PM -0400, Cameron Pinchin wrote:
> From: CameronPinchin <cameronpinchin@cmail.carleton.ca>
>
> Fix comment formatting to align with kernel-doc guidelines.
>
> No functional changes.
>
> Signed-off-by: Cameron Pinchin <cameronpinchin@cmail.carleton.ca>
> ---
> 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 e9af66a08..0e655f79e 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
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- Your patch did not apply to any known trees that Greg is in control
of. Possibly this is because you made it against Linus's tree, not
the linux-next tree, which is where all of the development for the
next version of the kernel is at. Please refresh your patch against
the linux-next tree, or even better yet, the development tree
specified in the MAINTAINERS file for the subsystem you are submitting
a patch for, and resend it.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH] staging: nvec: fix block comment formatting
From: Greg KH @ 2026-03-30 15:49 UTC (permalink / raw)
To: Hüseyin Can Erdem
Cc: marvin24, ac100, linux-tegra, linux-staging, linux-kernel
In-Reply-To: <20260318170604.10254-1-erdemhuseyincan09@gmail.com>
On Wed, Mar 18, 2026 at 08:06:04PM +0300, Hüseyin Can Erdem wrote:
> The block comment in nvec_interrupt() does not follow the kernel
> coding style. Multi-line block comments should have a * at the
> beginning of each line, and the closing */ should be on its own
> separate line.
>
> Signed-off-by: Hüseyin Can Erdem <erdemhuseyincan09@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 e9af66a08..0e655f79e 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.47.3
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- Your patch did not apply to any known trees that Greg is in control
of. Possibly this is because you made it against Linus's tree, not
the linux-next tree, which is where all of the development for the
next version of the kernel is at. Please refresh your patch against
the linux-next tree, or even better yet, the development tree
specified in the MAINTAINERS file for the subsystem you are submitting
a patch for, and resend it.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH v2 2/7] pwm: tegra: Avoid hard-coded max clock frequency
From: kernel test robot @ 2026-03-30 14:47 UTC (permalink / raw)
To: Mikko Perttunen, Thierry Reding, Uwe Kleine-König,
Jonathan Hunter, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: oe-kbuild-all, linux-pwm, linux-tegra, linux-kernel, devicetree,
Yi-Wei Wang, Mikko Perttunen
In-Reply-To: <20260325-t264-pwm-v2-2-998d885984b3@nvidia.com>
Hi Mikko,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 11439c4635edd669ae435eec308f4ab8a0804808]
url: https://github.com/intel-lab-lkp/linux/commits/Mikko-Perttunen/dt-bindings-pwm-Document-Tegra194-and-Tegra264-controllers/20260329-233356
base: 11439c4635edd669ae435eec308f4ab8a0804808
patch link: https://lore.kernel.org/r/20260325-t264-pwm-v2-2-998d885984b3%40nvidia.com
patch subject: [PATCH v2 2/7] pwm: tegra: Avoid hard-coded max clock frequency
config: hexagon-randconfig-r113-20260330 (https://download.01.org/0day-ci/archive/20260330/202603302251.AFXspVqF-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 2cd67b8b69f78e3f95918204320c3075a74ba16c)
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260330/202603302251.AFXspVqF-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/202603302251.AFXspVqF-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/pwm/pwm-tegra.c:303:47: sparse: sparse: cast truncates bits from constant value (7fffffffffffffff becomes ffffffff)
vim +303 drivers/pwm/pwm-tegra.c
266
267 static int tegra_pwm_probe(struct platform_device *pdev)
268 {
269 struct pwm_chip *chip;
270 struct tegra_pwm_chip *pc;
271 const struct tegra_pwm_soc *soc;
272 int ret;
273
274 soc = of_device_get_match_data(&pdev->dev);
275
276 chip = devm_pwmchip_alloc(&pdev->dev, soc->num_channels, sizeof(*pc));
277 if (IS_ERR(chip))
278 return PTR_ERR(chip);
279 pc = to_tegra_pwm_chip(chip);
280
281 pc->soc = soc;
282
283 pc->regs = devm_platform_ioremap_resource(pdev, 0);
284 if (IS_ERR(pc->regs))
285 return PTR_ERR(pc->regs);
286
287 platform_set_drvdata(pdev, chip);
288
289 pc->clk = devm_clk_get(&pdev->dev, NULL);
290 if (IS_ERR(pc->clk))
291 return PTR_ERR(pc->clk);
292
293 ret = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
294 if (ret)
295 return ret;
296
297 pm_runtime_enable(&pdev->dev);
298 ret = pm_runtime_resume_and_get(&pdev->dev);
299 if (ret)
300 return ret;
301
302 /* Set maximum frequency of the IP */
> 303 ret = dev_pm_opp_set_rate(&pdev->dev, S64_MAX);
304 if (ret < 0) {
305 dev_err(&pdev->dev, "Failed to set max frequency: %d\n", ret);
306 goto put_pm;
307 }
308
309 /*
310 * The requested and configured frequency may differ due to
311 * clock register resolutions. Get the configured frequency
312 * so that PWM period can be calculated more accurately.
313 */
314 pc->clk_rate = clk_get_rate(pc->clk);
315
316 /* Set minimum limit of PWM period for the IP */
317 pc->min_period_ns =
318 (NSEC_PER_SEC / (pc->clk_rate >> PWM_DUTY_WIDTH)) + 1;
319
320 pc->rst = devm_reset_control_get_exclusive(&pdev->dev, "pwm");
321 if (IS_ERR(pc->rst)) {
322 ret = PTR_ERR(pc->rst);
323 dev_err(&pdev->dev, "Reset control is not found: %d\n", ret);
324 goto put_pm;
325 }
326
327 reset_control_deassert(pc->rst);
328
329 chip->ops = &tegra_pwm_ops;
330
331 ret = pwmchip_add(chip);
332 if (ret < 0) {
333 dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
334 reset_control_assert(pc->rst);
335 goto put_pm;
336 }
337
338 pm_runtime_put(&pdev->dev);
339
340 return 0;
341 put_pm:
342 pm_runtime_put_sync_suspend(&pdev->dev);
343 pm_runtime_force_suspend(&pdev->dev);
344 return ret;
345 }
346
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v5 10/10] arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
From: Akhil R @ 2026-03-30 14:44 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
Cc: Akhil R
In-Reply-To: <20260330144456.13551-1-akhilrajeev@nvidia.com>
Enable GPCDMA in Tegra264 and add the iommu-map property so that each
channel uses a separate stream ID and gets its own IOMMU domain for
memory.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 4 ++++
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi b/arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi
index 7e2c3e66c2ab..58cd81bc33d7 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi
@@ -9,6 +9,10 @@ aliases {
};
bus@0 {
+ dma-controller@8400000 {
+ status = "okay";
+ };
+
serial@c4e0000 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index af077420d7d9..b2f20d4b567a 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3244,6 +3244,7 @@ gpcdma: dma-controller@8400000 {
<GIC_SPI 615 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <1>;
iommus = <&smmu1 0x00000800>;
+ iommu-map = <1 &smmu1 0x801 31>;
dma-coherent;
dma-channel-mask = <0xfffffffe>;
status = "disabled";
--
2.50.1
^ permalink raw reply related
* [PATCH v5 09/10] dmaengine: tegra: Add Tegra264 support
From: Akhil R @ 2026-03-30 14:44 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
Cc: Akhil R, Frank Li
In-Reply-To: <20260330144456.13551-1-akhilrajeev@nvidia.com>
Add compatible and chip data to support GPCDMA in Tegra264, which has
differences in register layout and address bits compared to previous
versions.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
drivers/dma/tegra186-gpc-dma.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
index 64743d852dda..0b7faf8bb80b 100644
--- a/drivers/dma/tegra186-gpc-dma.c
+++ b/drivers/dma/tegra186-gpc-dma.c
@@ -1319,6 +1319,23 @@ static const struct tegra_dma_channel_regs tegra186_reg_offsets = {
.fixed_pattern = 0x34,
};
+static const struct tegra_dma_channel_regs tegra264_reg_offsets = {
+ .csr = 0x0,
+ .status = 0x4,
+ .csre = 0x8,
+ .src = 0xc,
+ .dst = 0x10,
+ .src_high = 0x14,
+ .dst_high = 0x18,
+ .mc_seq = 0x1c,
+ .mmio_seq = 0x20,
+ .wcount = 0x24,
+ .wxfer = 0x28,
+ .wstatus = 0x2c,
+ .err_status = 0x34,
+ .fixed_pattern = 0x38,
+};
+
static const struct tegra_dma_chip_data tegra186_dma_chip_data = {
.nr_channels = 32,
.addr_bits = 39,
@@ -1349,6 +1366,16 @@ static const struct tegra_dma_chip_data tegra234_dma_chip_data = {
.terminate = tegra_dma_pause_noerr,
};
+static const struct tegra_dma_chip_data tegra264_dma_chip_data = {
+ .nr_channels = 32,
+ .addr_bits = 41,
+ .channel_reg_size = SZ_64K,
+ .max_dma_count = SZ_1G,
+ .hw_support_pause = true,
+ .channel_regs = &tegra264_reg_offsets,
+ .terminate = tegra_dma_pause_noerr,
+};
+
static const struct of_device_id tegra_dma_of_match[] = {
{
.compatible = "nvidia,tegra186-gpcdma",
@@ -1359,6 +1386,9 @@ static const struct of_device_id tegra_dma_of_match[] = {
}, {
.compatible = "nvidia,tegra234-gpcdma",
.data = &tegra234_dma_chip_data,
+ }, {
+ .compatible = "nvidia,tegra264-gpcdma",
+ .data = &tegra264_dma_chip_data,
}, {
},
};
--
2.50.1
^ permalink raw reply related
* [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Akhil R @ 2026-03-30 14:44 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
Cc: Akhil R
In-Reply-To: <20260330144456.13551-1-akhilrajeev@nvidia.com>
Use 'iommu-map', when provided, to get the stream ID to be programmed
for each channel. Iterate over the channels registered and configure
each channel device separately using of_dma_configure_id() to allow
it to use a separate IOMMU domain for the transfer. However, do this
in a second loop since the first loop populates the DMA device channels
list and async_device_register() registers the channels. Both are
prerequisites for using the channel device in the next loop.
Channels will continue to use the same global stream ID if the
'iommu-map' property is not present in the device tree.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/dma/tegra186-gpc-dma.c | 57 ++++++++++++++++++++++++++++------
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
index 9bea2ffb3b9e..64743d852dda 100644
--- a/drivers/dma/tegra186-gpc-dma.c
+++ b/drivers/dma/tegra186-gpc-dma.c
@@ -15,6 +15,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_dma.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/reset.h>
#include <linux/slab.h>
@@ -1380,9 +1381,13 @@ static int tegra_dma_program_sid(struct tegra_dma_channel *tdc, int stream_id)
static int tegra_dma_probe(struct platform_device *pdev)
{
const struct tegra_dma_chip_data *cdata = NULL;
+ struct tegra_dma_channel *tdc;
+ struct tegra_dma *tdma;
+ struct dma_chan *chan;
+ struct device *chdev;
+ bool use_iommu_map = false;
unsigned int i;
u32 stream_id;
- struct tegra_dma *tdma;
int ret;
cdata = of_device_get_match_data(&pdev->dev);
@@ -1410,9 +1415,12 @@ static int tegra_dma_probe(struct platform_device *pdev)
tdma->dma_dev.dev = &pdev->dev;
- if (!tegra_dev_iommu_get_stream_id(&pdev->dev, &stream_id)) {
- dev_err(&pdev->dev, "Missing iommu stream-id\n");
- return -EINVAL;
+ use_iommu_map = of_property_present(pdev->dev.of_node, "iommu-map");
+ if (!use_iommu_map) {
+ if (!tegra_dev_iommu_get_stream_id(&pdev->dev, &stream_id)) {
+ dev_err(&pdev->dev, "Missing iommu stream-id\n");
+ return -EINVAL;
+ }
}
ret = device_property_read_u32(&pdev->dev, "dma-channel-mask",
@@ -1424,9 +1432,10 @@ static int tegra_dma_probe(struct platform_device *pdev)
tdma->chan_mask = TEGRA_GPCDMA_DEFAULT_CHANNEL_MASK;
}
+ /* Initialize vchan for each channel and populate the channels list */
INIT_LIST_HEAD(&tdma->dma_dev.channels);
for (i = 0; i < cdata->nr_channels; i++) {
- struct tegra_dma_channel *tdc = &tdma->channels[i];
+ tdc = &tdma->channels[i];
/* Check for channel mask */
if (!(tdma->chan_mask & BIT(i)))
@@ -1446,10 +1455,6 @@ static int tegra_dma_probe(struct platform_device *pdev)
vchan_init(&tdc->vc, &tdma->dma_dev);
tdc->vc.desc_free = tegra_dma_desc_free;
-
- /* program stream-id for this channel */
- tegra_dma_program_sid(tdc, stream_id);
- tdc->stream_id = stream_id;
}
dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(cdata->addr_bits));
@@ -1483,6 +1488,7 @@ static int tegra_dma_probe(struct platform_device *pdev)
tdma->dma_dev.device_synchronize = tegra_dma_chan_synchronize;
tdma->dma_dev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+ /* Register the DMA device and the channels */
ret = dmaenginem_async_device_register(&tdma->dma_dev);
if (ret < 0) {
dev_err_probe(&pdev->dev, ret,
@@ -1490,6 +1496,39 @@ static int tegra_dma_probe(struct platform_device *pdev)
return ret;
}
+ /*
+ * Configure stream ID for each channel from the channels registered
+ * above. This is done in a separate iteration to ensure that only
+ * the channels available and registered for the DMA device are used.
+ */
+ list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
+ chdev = &chan->dev->device;
+ tdc = to_tegra_dma_chan(chan);
+
+ if (use_iommu_map) {
+ chdev->bus = pdev->dev.bus;
+ dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
+
+ ret = of_dma_configure_id(chdev, pdev->dev.of_node,
+ true, &tdc->id);
+ if (ret)
+ return dev_err_probe(chdev, ret,
+ "Failed to configure IOMMU for channel %d", tdc->id);
+
+ if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
+ dev_err(chdev, "Failed to get stream ID for channel %d\n",
+ tdc->id);
+ return -EINVAL;
+ }
+
+ chan->dev->chan_dma_dev = true;
+ }
+
+ /* program stream-id for this channel */
+ tegra_dma_program_sid(tdc, stream_id);
+ tdc->stream_id = stream_id;
+ }
+
ret = devm_of_dma_controller_register(&pdev->dev, pdev->dev.of_node,
tegra_dma_of_xlate, tdma);
if (ret < 0) {
--
2.50.1
^ permalink raw reply related
* [PATCH v5 07/10] dmaengine: tegra: Use managed DMA controller registration
From: Akhil R @ 2026-03-30 14:44 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
Cc: Akhil R, Frank Li
In-Reply-To: <20260330144456.13551-1-akhilrajeev@nvidia.com>
Switch to managed registration in probe. This simplifies the error
paths in the probe and also removes the requirement of the driver
remove function.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Suggested-by: Frank Li <frank.li@nxp.com>
---
drivers/dma/tegra186-gpc-dma.c | 19 ++++---------------
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
index 3ac43ad19ed6..9bea2ffb3b9e 100644
--- a/drivers/dma/tegra186-gpc-dma.c
+++ b/drivers/dma/tegra186-gpc-dma.c
@@ -1483,37 +1483,27 @@ static int tegra_dma_probe(struct platform_device *pdev)
tdma->dma_dev.device_synchronize = tegra_dma_chan_synchronize;
tdma->dma_dev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
- ret = dma_async_device_register(&tdma->dma_dev);
+ ret = dmaenginem_async_device_register(&tdma->dma_dev);
if (ret < 0) {
dev_err_probe(&pdev->dev, ret,
"GPC DMA driver registration failed\n");
return ret;
}
- ret = of_dma_controller_register(pdev->dev.of_node,
- tegra_dma_of_xlate, tdma);
+ ret = devm_of_dma_controller_register(&pdev->dev, pdev->dev.of_node,
+ tegra_dma_of_xlate, tdma);
if (ret < 0) {
dev_err_probe(&pdev->dev, ret,
"GPC DMA OF registration failed\n");
-
- dma_async_device_unregister(&tdma->dma_dev);
return ret;
}
- dev_info(&pdev->dev, "GPC DMA driver register %lu channels\n",
+ dev_info(&pdev->dev, "GPC DMA driver registered %lu channels\n",
hweight_long(tdma->chan_mask));
return 0;
}
-static void tegra_dma_remove(struct platform_device *pdev)
-{
- struct tegra_dma *tdma = platform_get_drvdata(pdev);
-
- of_dma_controller_free(pdev->dev.of_node);
- dma_async_device_unregister(&tdma->dma_dev);
-}
-
static int __maybe_unused tegra_dma_pm_suspend(struct device *dev)
{
struct tegra_dma *tdma = dev_get_drvdata(dev);
@@ -1564,7 +1554,6 @@ static struct platform_driver tegra_dma_driver = {
.of_match_table = tegra_dma_of_match,
},
.probe = tegra_dma_probe,
- .remove = tegra_dma_remove,
};
module_platform_driver(tegra_dma_driver);
--
2.50.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox