* [PATCH v6 05/10] dmaengine: tegra: Use struct for register offsets
From: Akhil R @ 2026-03-31 10:22 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: <20260331102303.33181-1-akhilrajeev@nvidia.com>
Repurpose the struct tegra_dma_channel_regs to define offsets for all the
channel registers. Previously, the struct only held the register values
for each transfer and was wrapped within tegra_dma_sg_req. Move the
values directly into tegra_dma_sg_req and use channel_regs for
storing the register offsets. Update all register reads/writes to use
the struct channel_regs. This prepares for the register offset change
in Tegra264.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
drivers/dma/tegra186-gpc-dma.c | 282 +++++++++++++++++----------------
1 file changed, 142 insertions(+), 140 deletions(-)
diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
index a0522a992ebc..b213c4ae07d2 100644
--- a/drivers/dma/tegra186-gpc-dma.c
+++ b/drivers/dma/tegra186-gpc-dma.c
@@ -22,7 +22,6 @@
#include "virt-dma.h"
/* CSR register */
-#define TEGRA_GPCDMA_CHAN_CSR 0x00
#define TEGRA_GPCDMA_CSR_ENB BIT(31)
#define TEGRA_GPCDMA_CSR_IE_EOC BIT(30)
#define TEGRA_GPCDMA_CSR_ONCE BIT(27)
@@ -58,7 +57,6 @@
#define TEGRA_GPCDMA_CSR_WEIGHT GENMASK(13, 10)
/* STATUS register */
-#define TEGRA_GPCDMA_CHAN_STATUS 0x004
#define TEGRA_GPCDMA_STATUS_BUSY BIT(31)
#define TEGRA_GPCDMA_STATUS_ISE_EOC BIT(30)
#define TEGRA_GPCDMA_STATUS_PING_PONG BIT(28)
@@ -70,22 +68,13 @@
#define TEGRA_GPCDMA_STATUS_IRQ_STA BIT(21)
#define TEGRA_GPCDMA_STATUS_IRQ_TRIG_STA BIT(20)
-#define TEGRA_GPCDMA_CHAN_CSRE 0x008
#define TEGRA_GPCDMA_CHAN_CSRE_PAUSE BIT(31)
-/* Source address */
-#define TEGRA_GPCDMA_CHAN_SRC_PTR 0x00C
-
-/* Destination address */
-#define TEGRA_GPCDMA_CHAN_DST_PTR 0x010
-
/* High address pointer */
-#define TEGRA_GPCDMA_CHAN_HIGH_ADDR_PTR 0x014
#define TEGRA_GPCDMA_HIGH_ADDR_SRC_PTR GENMASK(7, 0)
#define TEGRA_GPCDMA_HIGH_ADDR_DST_PTR GENMASK(23, 16)
/* MC sequence register */
-#define TEGRA_GPCDMA_CHAN_MCSEQ 0x18
#define TEGRA_GPCDMA_MCSEQ_DATA_SWAP BIT(31)
#define TEGRA_GPCDMA_MCSEQ_REQ_COUNT GENMASK(30, 25)
#define TEGRA_GPCDMA_MCSEQ_BURST GENMASK(24, 23)
@@ -101,7 +90,6 @@
#define TEGRA_GPCDMA_MCSEQ_STREAM_ID0_MASK GENMASK(6, 0)
/* MMIO sequence register */
-#define TEGRA_GPCDMA_CHAN_MMIOSEQ 0x01c
#define TEGRA_GPCDMA_MMIOSEQ_DBL_BUF BIT(31)
#define TEGRA_GPCDMA_MMIOSEQ_BUS_WIDTH GENMASK(30, 28)
#define TEGRA_GPCDMA_MMIOSEQ_BUS_WIDTH_8 \
@@ -120,17 +108,7 @@
#define TEGRA_GPCDMA_MMIOSEQ_WRAP_WORD GENMASK(18, 16)
#define TEGRA_GPCDMA_MMIOSEQ_MMIO_PROT GENMASK(8, 7)
-/* Channel WCOUNT */
-#define TEGRA_GPCDMA_CHAN_WCOUNT 0x20
-
-/* Transfer count */
-#define TEGRA_GPCDMA_CHAN_XFER_COUNT 0x24
-
-/* DMA byte count status */
-#define TEGRA_GPCDMA_CHAN_DMA_BYTE_STATUS 0x28
-
/* Error Status Register */
-#define TEGRA_GPCDMA_CHAN_ERR_STATUS 0x30
#define TEGRA_GPCDMA_CHAN_ERR_TYPE_SHIFT 8
#define TEGRA_GPCDMA_CHAN_ERR_TYPE_MASK 0xF
#define TEGRA_GPCDMA_CHAN_ERR_TYPE(err) ( \
@@ -143,16 +121,6 @@
#define TEGRA_DMA_MC_SLAVE_ERR 0xB
#define TEGRA_DMA_MMIO_SLAVE_ERR 0xA
-/* Fixed Pattern */
-#define TEGRA_GPCDMA_CHAN_FIXED_PATTERN 0x34
-
-#define TEGRA_GPCDMA_CHAN_TZ 0x38
-#define TEGRA_GPCDMA_CHAN_TZ_MMIO_PROT_1 BIT(0)
-#define TEGRA_GPCDMA_CHAN_TZ_MC_PROT_1 BIT(1)
-
-#define TEGRA_GPCDMA_CHAN_SPARE 0x3c
-#define TEGRA_GPCDMA_CHAN_SPARE_EN_LEGACY_FC BIT(16)
-
/*
* If any burst is in flight and DMA paused then this is the time to complete
* on-flight burst and update DMA status register.
@@ -181,18 +149,24 @@ struct tegra_dma_chip_data {
unsigned int nr_channels;
unsigned int channel_reg_size;
unsigned int max_dma_count;
+ const struct tegra_dma_channel_regs *channel_regs;
int (*terminate)(struct tegra_dma_channel *tdc);
};
/* DMA channel registers */
struct tegra_dma_channel_regs {
u32 csr;
- u32 src_ptr;
- u32 dst_ptr;
- u32 high_addr_ptr;
+ u32 status;
+ u32 csre;
+ u32 src;
+ u32 dst;
+ u32 high_addr;
u32 mc_seq;
u32 mmio_seq;
u32 wcount;
+ u32 wxfer;
+ u32 wstatus;
+ u32 err_status;
u32 fixed_pattern;
};
@@ -205,7 +179,14 @@ struct tegra_dma_channel_regs {
*/
struct tegra_dma_sg_req {
unsigned int len;
- struct tegra_dma_channel_regs ch_regs;
+ u32 csr;
+ u32 src;
+ u32 dst;
+ u32 high_addr;
+ u32 mc_seq;
+ u32 mmio_seq;
+ u32 wcount;
+ u32 fixed_pattern;
};
/*
@@ -228,19 +209,20 @@ struct tegra_dma_desc {
* tegra_dma_channel: Channel specific information
*/
struct tegra_dma_channel {
- bool config_init;
- char name[30];
- enum dma_transfer_direction sid_dir;
- enum dma_status status;
- int id;
- int irq;
- int slave_id;
+ const struct tegra_dma_channel_regs *regs;
struct tegra_dma *tdma;
struct virt_dma_chan vc;
struct tegra_dma_desc *dma_desc;
struct dma_slave_config dma_sconfig;
+ enum dma_transfer_direction sid_dir;
+ enum dma_status status;
unsigned int stream_id;
unsigned long chan_base_offset;
+ bool config_init;
+ char name[30];
+ int id;
+ int irq;
+ int slave_id;
};
/*
@@ -288,22 +270,22 @@ static void tegra_dma_dump_chan_regs(struct tegra_dma_channel *tdc)
{
dev_dbg(tdc2dev(tdc), "DMA Channel %d name %s register dump:\n",
tdc->id, tdc->name);
- dev_dbg(tdc2dev(tdc), "CSR %x STA %x CSRE %x SRC %x DST %x\n",
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_CSR),
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_STATUS),
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_CSRE),
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_SRC_PTR),
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_DST_PTR)
- );
- dev_dbg(tdc2dev(tdc), "MCSEQ %x IOSEQ %x WCNT %x XFER %x BSTA %x\n",
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_MCSEQ),
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_MMIOSEQ),
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_WCOUNT),
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_XFER_COUNT),
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_DMA_BYTE_STATUS)
- );
+ dev_dbg(tdc2dev(tdc), "CSR %x STA %x CSRE %x\n",
+ tdc_read(tdc, tdc->regs->csr),
+ tdc_read(tdc, tdc->regs->status),
+ tdc_read(tdc, tdc->regs->csre));
+ dev_dbg(tdc2dev(tdc), "SRC %x DST %x HI ADDR %x\n",
+ tdc_read(tdc, tdc->regs->src),
+ tdc_read(tdc, tdc->regs->dst),
+ tdc_read(tdc, tdc->regs->high_addr));
+ dev_dbg(tdc2dev(tdc), "MCSEQ %x IOSEQ %x WCNT %x XFER %x WSTA %x\n",
+ tdc_read(tdc, tdc->regs->mc_seq),
+ tdc_read(tdc, tdc->regs->mmio_seq),
+ tdc_read(tdc, tdc->regs->wcount),
+ tdc_read(tdc, tdc->regs->wxfer),
+ tdc_read(tdc, tdc->regs->wstatus));
dev_dbg(tdc2dev(tdc), "DMA ERR_STA %x\n",
- tdc_read(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS));
+ tdc_read(tdc, tdc->regs->err_status));
}
static int tegra_dma_sid_reserve(struct tegra_dma_channel *tdc,
@@ -377,13 +359,13 @@ static int tegra_dma_pause(struct tegra_dma_channel *tdc)
int ret;
u32 val;
- val = tdc_read(tdc, TEGRA_GPCDMA_CHAN_CSRE);
+ val = tdc_read(tdc, tdc->regs->csre);
val |= TEGRA_GPCDMA_CHAN_CSRE_PAUSE;
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSRE, val);
+ tdc_write(tdc, tdc->regs->csre, val);
/* Wait until busy bit is de-asserted */
ret = readl_relaxed_poll_timeout_atomic(tdc->tdma->base_addr +
- tdc->chan_base_offset + TEGRA_GPCDMA_CHAN_STATUS,
+ tdc->chan_base_offset + tdc->regs->status,
val,
!(val & TEGRA_GPCDMA_STATUS_BUSY),
TEGRA_GPCDMA_BURST_COMPLETE_TIME,
@@ -419,9 +401,9 @@ static void tegra_dma_resume(struct tegra_dma_channel *tdc)
{
u32 val;
- val = tdc_read(tdc, TEGRA_GPCDMA_CHAN_CSRE);
+ val = tdc_read(tdc, tdc->regs->csre);
val &= ~TEGRA_GPCDMA_CHAN_CSRE_PAUSE;
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSRE, val);
+ tdc_write(tdc, tdc->regs->csre, val);
tdc->status = DMA_IN_PROGRESS;
}
@@ -456,27 +438,27 @@ static void tegra_dma_disable(struct tegra_dma_channel *tdc)
{
u32 csr, status;
- csr = tdc_read(tdc, TEGRA_GPCDMA_CHAN_CSR);
+ csr = tdc_read(tdc, tdc->regs->csr);
/* Disable interrupts */
csr &= ~TEGRA_GPCDMA_CSR_IE_EOC;
/* Disable DMA */
csr &= ~TEGRA_GPCDMA_CSR_ENB;
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSR, csr);
+ tdc_write(tdc, tdc->regs->csr, csr);
/* Clear interrupt status if it is there */
- status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_STATUS);
+ status = tdc_read(tdc, tdc->regs->status);
if (status & TEGRA_GPCDMA_STATUS_ISE_EOC) {
dev_dbg(tdc2dev(tdc), "%s():clearing interrupt\n", __func__);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_STATUS, status);
+ tdc_write(tdc, tdc->regs->status, status);
}
}
static void tegra_dma_configure_next_sg(struct tegra_dma_channel *tdc)
{
struct tegra_dma_desc *dma_desc = tdc->dma_desc;
- struct tegra_dma_channel_regs *ch_regs;
+ struct tegra_dma_sg_req *sg_req;
int ret;
u32 val;
@@ -488,29 +470,29 @@ static void tegra_dma_configure_next_sg(struct tegra_dma_channel *tdc)
/* Configure next transfer immediately after DMA is busy */
ret = readl_relaxed_poll_timeout_atomic(tdc->tdma->base_addr +
- tdc->chan_base_offset + TEGRA_GPCDMA_CHAN_STATUS,
+ tdc->chan_base_offset + tdc->regs->status,
val,
(val & TEGRA_GPCDMA_STATUS_BUSY), 0,
TEGRA_GPCDMA_BURST_COMPLETION_TIMEOUT);
if (ret)
return;
- ch_regs = &dma_desc->sg_req[dma_desc->sg_idx].ch_regs;
+ sg_req = &dma_desc->sg_req[dma_desc->sg_idx];
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_WCOUNT, ch_regs->wcount);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_SRC_PTR, ch_regs->src_ptr);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_DST_PTR, ch_regs->dst_ptr);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_HIGH_ADDR_PTR, ch_regs->high_addr_ptr);
+ tdc_write(tdc, tdc->regs->wcount, sg_req->wcount);
+ tdc_write(tdc, tdc->regs->src, sg_req->src);
+ tdc_write(tdc, tdc->regs->dst, sg_req->dst);
+ tdc_write(tdc, tdc->regs->high_addr, sg_req->high_addr);
/* Start DMA */
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSR,
- ch_regs->csr | TEGRA_GPCDMA_CSR_ENB);
+ tdc_write(tdc, tdc->regs->csr,
+ sg_req->csr | TEGRA_GPCDMA_CSR_ENB);
}
static void tegra_dma_start(struct tegra_dma_channel *tdc)
{
struct tegra_dma_desc *dma_desc = tdc->dma_desc;
- struct tegra_dma_channel_regs *ch_regs;
+ struct tegra_dma_sg_req *sg_req;
struct virt_dma_desc *vdesc;
if (!dma_desc) {
@@ -526,21 +508,21 @@ static void tegra_dma_start(struct tegra_dma_channel *tdc)
tegra_dma_resume(tdc);
}
- ch_regs = &dma_desc->sg_req[dma_desc->sg_idx].ch_regs;
+ sg_req = &dma_desc->sg_req[dma_desc->sg_idx];
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_WCOUNT, ch_regs->wcount);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSR, 0);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_SRC_PTR, ch_regs->src_ptr);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_DST_PTR, ch_regs->dst_ptr);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_HIGH_ADDR_PTR, ch_regs->high_addr_ptr);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_FIXED_PATTERN, ch_regs->fixed_pattern);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_MMIOSEQ, ch_regs->mmio_seq);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_MCSEQ, ch_regs->mc_seq);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSR, ch_regs->csr);
+ tdc_write(tdc, tdc->regs->wcount, sg_req->wcount);
+ tdc_write(tdc, tdc->regs->csr, 0);
+ tdc_write(tdc, tdc->regs->src, sg_req->src);
+ tdc_write(tdc, tdc->regs->dst, sg_req->dst);
+ tdc_write(tdc, tdc->regs->high_addr, sg_req->high_addr);
+ tdc_write(tdc, tdc->regs->fixed_pattern, sg_req->fixed_pattern);
+ tdc_write(tdc, tdc->regs->mmio_seq, sg_req->mmio_seq);
+ tdc_write(tdc, tdc->regs->mc_seq, sg_req->mc_seq);
+ tdc_write(tdc, tdc->regs->csr, sg_req->csr);
/* Start DMA */
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSR,
- ch_regs->csr | TEGRA_GPCDMA_CSR_ENB);
+ tdc_write(tdc, tdc->regs->csr,
+ sg_req->csr | TEGRA_GPCDMA_CSR_ENB);
}
static void tegra_dma_xfer_complete(struct tegra_dma_channel *tdc)
@@ -601,19 +583,19 @@ static irqreturn_t tegra_dma_isr(int irq, void *dev_id)
u32 status;
/* Check channel error status register */
- status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS);
+ status = tdc_read(tdc, tdc->regs->err_status);
if (status) {
tegra_dma_chan_decode_error(tdc, status);
tegra_dma_dump_chan_regs(tdc);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS, 0xFFFFFFFF);
+ tdc_write(tdc, tdc->regs->err_status, 0xFFFFFFFF);
}
spin_lock(&tdc->vc.lock);
- status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_STATUS);
+ status = tdc_read(tdc, tdc->regs->status);
if (!(status & TEGRA_GPCDMA_STATUS_ISE_EOC))
goto irq_done;
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_STATUS,
+ tdc_write(tdc, tdc->regs->status,
TEGRA_GPCDMA_STATUS_ISE_EOC);
if (!dma_desc)
@@ -673,10 +655,10 @@ static int tegra_dma_stop_client(struct tegra_dma_channel *tdc)
* to stop DMA engine from starting any more bursts for
* the given client and wait for in flight bursts to complete
*/
- csr = tdc_read(tdc, TEGRA_GPCDMA_CHAN_CSR);
+ csr = tdc_read(tdc, tdc->regs->csr);
csr &= ~(TEGRA_GPCDMA_CSR_REQ_SEL_MASK);
csr |= TEGRA_GPCDMA_CSR_REQ_SEL_UNUSED;
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_CSR, csr);
+ tdc_write(tdc, tdc->regs->csr, csr);
/* Wait for in flight data transfer to finish */
udelay(TEGRA_GPCDMA_BURST_COMPLETE_TIME);
@@ -687,7 +669,7 @@ static int tegra_dma_stop_client(struct tegra_dma_channel *tdc)
ret = readl_relaxed_poll_timeout_atomic(tdc->tdma->base_addr +
tdc->chan_base_offset +
- TEGRA_GPCDMA_CHAN_STATUS,
+ tdc->regs->status,
status,
!(status & (TEGRA_GPCDMA_STATUS_CHANNEL_TX |
TEGRA_GPCDMA_STATUS_CHANNEL_RX)),
@@ -739,14 +721,14 @@ static int tegra_dma_get_residual(struct tegra_dma_channel *tdc)
unsigned int bytes_xfer, residual;
u32 wcount = 0, status;
- wcount = tdc_read(tdc, TEGRA_GPCDMA_CHAN_XFER_COUNT);
+ wcount = tdc_read(tdc, tdc->regs->wxfer);
/*
* Set wcount = 0 if EOC bit is set. The transfer would have
* already completed and the CHAN_XFER_COUNT could have updated
* for the next transfer, specifically in case of cyclic transfers.
*/
- status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_STATUS);
+ status = tdc_read(tdc, tdc->regs->status);
if (status & TEGRA_GPCDMA_STATUS_ISE_EOC)
wcount = 0;
@@ -893,7 +875,7 @@ tegra_dma_prep_dma_memset(struct dma_chan *dc, dma_addr_t dest, int value,
/* Configure default priority weight for the channel */
csr |= FIELD_PREP(TEGRA_GPCDMA_CSR_WEIGHT, 1);
- mc_seq = tdc_read(tdc, TEGRA_GPCDMA_CHAN_MCSEQ);
+ mc_seq = tdc_read(tdc, tdc->regs->mc_seq);
/* retain stream-id and clean rest */
mc_seq &= TEGRA_GPCDMA_MCSEQ_STREAM_ID0_MASK;
@@ -916,16 +898,16 @@ tegra_dma_prep_dma_memset(struct dma_chan *dc, dma_addr_t dest, int value,
dma_desc->sg_count = 1;
sg_req = dma_desc->sg_req;
- sg_req[0].ch_regs.src_ptr = 0;
- sg_req[0].ch_regs.dst_ptr = dest;
- sg_req[0].ch_regs.high_addr_ptr =
+ sg_req[0].src = 0;
+ sg_req[0].dst = dest;
+ sg_req[0].high_addr =
FIELD_PREP(TEGRA_GPCDMA_HIGH_ADDR_DST_PTR, (dest >> 32));
- sg_req[0].ch_regs.fixed_pattern = value;
+ sg_req[0].fixed_pattern = value;
/* Word count reg takes value as (N +1) words */
- sg_req[0].ch_regs.wcount = ((len - 4) >> 2);
- sg_req[0].ch_regs.csr = csr;
- sg_req[0].ch_regs.mmio_seq = 0;
- sg_req[0].ch_regs.mc_seq = mc_seq;
+ sg_req[0].wcount = ((len - 4) >> 2);
+ sg_req[0].csr = csr;
+ sg_req[0].mmio_seq = 0;
+ sg_req[0].mc_seq = mc_seq;
sg_req[0].len = len;
dma_desc->cyclic = false;
@@ -961,7 +943,7 @@ tegra_dma_prep_dma_memcpy(struct dma_chan *dc, dma_addr_t dest,
/* Configure default priority weight for the channel */
csr |= FIELD_PREP(TEGRA_GPCDMA_CSR_WEIGHT, 1);
- mc_seq = tdc_read(tdc, TEGRA_GPCDMA_CHAN_MCSEQ);
+ mc_seq = tdc_read(tdc, tdc->regs->mc_seq);
/* retain stream-id and clean rest */
mc_seq &= (TEGRA_GPCDMA_MCSEQ_STREAM_ID0_MASK) |
(TEGRA_GPCDMA_MCSEQ_STREAM_ID1_MASK);
@@ -985,17 +967,17 @@ tegra_dma_prep_dma_memcpy(struct dma_chan *dc, dma_addr_t dest,
dma_desc->sg_count = 1;
sg_req = dma_desc->sg_req;
- sg_req[0].ch_regs.src_ptr = src;
- sg_req[0].ch_regs.dst_ptr = dest;
- sg_req[0].ch_regs.high_addr_ptr =
+ sg_req[0].src = src;
+ sg_req[0].dst = dest;
+ sg_req[0].high_addr =
FIELD_PREP(TEGRA_GPCDMA_HIGH_ADDR_SRC_PTR, (src >> 32));
- sg_req[0].ch_regs.high_addr_ptr |=
+ sg_req[0].high_addr |=
FIELD_PREP(TEGRA_GPCDMA_HIGH_ADDR_DST_PTR, (dest >> 32));
/* Word count reg takes value as (N +1) words */
- sg_req[0].ch_regs.wcount = ((len - 4) >> 2);
- sg_req[0].ch_regs.csr = csr;
- sg_req[0].ch_regs.mmio_seq = 0;
- sg_req[0].ch_regs.mc_seq = mc_seq;
+ sg_req[0].wcount = ((len - 4) >> 2);
+ sg_req[0].csr = csr;
+ sg_req[0].mmio_seq = 0;
+ sg_req[0].mc_seq = mc_seq;
sg_req[0].len = len;
dma_desc->cyclic = false;
@@ -1049,7 +1031,7 @@ tegra_dma_prep_slave_sg(struct dma_chan *dc, struct scatterlist *sgl,
if (flags & DMA_PREP_INTERRUPT)
csr |= TEGRA_GPCDMA_CSR_IE_EOC;
- mc_seq = tdc_read(tdc, TEGRA_GPCDMA_CHAN_MCSEQ);
+ mc_seq = tdc_read(tdc, tdc->regs->mc_seq);
/* retain stream-id and clean rest */
mc_seq &= TEGRA_GPCDMA_MCSEQ_STREAM_ID0_MASK;
@@ -1096,14 +1078,14 @@ tegra_dma_prep_slave_sg(struct dma_chan *dc, struct scatterlist *sgl,
dma_desc->bytes_req += len;
if (direction == DMA_MEM_TO_DEV) {
- sg_req[i].ch_regs.src_ptr = mem;
- sg_req[i].ch_regs.dst_ptr = apb_ptr;
- sg_req[i].ch_regs.high_addr_ptr =
+ sg_req[i].src = mem;
+ sg_req[i].dst = apb_ptr;
+ sg_req[i].high_addr =
FIELD_PREP(TEGRA_GPCDMA_HIGH_ADDR_SRC_PTR, (mem >> 32));
} else if (direction == DMA_DEV_TO_MEM) {
- sg_req[i].ch_regs.src_ptr = apb_ptr;
- sg_req[i].ch_regs.dst_ptr = mem;
- sg_req[i].ch_regs.high_addr_ptr =
+ sg_req[i].src = apb_ptr;
+ sg_req[i].dst = mem;
+ sg_req[i].high_addr =
FIELD_PREP(TEGRA_GPCDMA_HIGH_ADDR_DST_PTR, (mem >> 32));
}
@@ -1111,10 +1093,10 @@ tegra_dma_prep_slave_sg(struct dma_chan *dc, struct scatterlist *sgl,
* Word count register takes input in words. Writing a value
* of N into word count register means a req of (N+1) words.
*/
- sg_req[i].ch_regs.wcount = ((len - 4) >> 2);
- sg_req[i].ch_regs.csr = csr;
- sg_req[i].ch_regs.mmio_seq = mmio_seq;
- sg_req[i].ch_regs.mc_seq = mc_seq;
+ sg_req[i].wcount = ((len - 4) >> 2);
+ sg_req[i].csr = csr;
+ sg_req[i].mmio_seq = mmio_seq;
+ sg_req[i].mc_seq = mc_seq;
sg_req[i].len = len;
}
@@ -1186,7 +1168,7 @@ tegra_dma_prep_dma_cyclic(struct dma_chan *dc, dma_addr_t buf_addr, size_t buf_l
mmio_seq |= FIELD_PREP(TEGRA_GPCDMA_MMIOSEQ_WRAP_WORD, 1);
- mc_seq = tdc_read(tdc, TEGRA_GPCDMA_CHAN_MCSEQ);
+ mc_seq = tdc_read(tdc, tdc->regs->mc_seq);
/* retain stream-id and clean rest */
mc_seq &= TEGRA_GPCDMA_MCSEQ_STREAM_ID0_MASK;
@@ -1217,24 +1199,24 @@ tegra_dma_prep_dma_cyclic(struct dma_chan *dc, dma_addr_t buf_addr, size_t buf_l
for (i = 0; i < period_count; i++) {
mmio_seq |= get_burst_size(tdc, burst_size, slave_bw, len);
if (direction == DMA_MEM_TO_DEV) {
- sg_req[i].ch_regs.src_ptr = mem;
- sg_req[i].ch_regs.dst_ptr = apb_ptr;
- sg_req[i].ch_regs.high_addr_ptr =
+ sg_req[i].src = mem;
+ sg_req[i].dst = apb_ptr;
+ sg_req[i].high_addr =
FIELD_PREP(TEGRA_GPCDMA_HIGH_ADDR_SRC_PTR, (mem >> 32));
} else if (direction == DMA_DEV_TO_MEM) {
- sg_req[i].ch_regs.src_ptr = apb_ptr;
- sg_req[i].ch_regs.dst_ptr = mem;
- sg_req[i].ch_regs.high_addr_ptr =
+ sg_req[i].src = apb_ptr;
+ sg_req[i].dst = mem;
+ sg_req[i].high_addr =
FIELD_PREP(TEGRA_GPCDMA_HIGH_ADDR_DST_PTR, (mem >> 32));
}
/*
* Word count register takes input in words. Writing a value
* of N into word count register means a req of (N+1) words.
*/
- sg_req[i].ch_regs.wcount = ((len - 4) >> 2);
- sg_req[i].ch_regs.csr = csr;
- sg_req[i].ch_regs.mmio_seq = mmio_seq;
- sg_req[i].ch_regs.mc_seq = mc_seq;
+ sg_req[i].wcount = ((len - 4) >> 2);
+ sg_req[i].csr = csr;
+ sg_req[i].mmio_seq = mmio_seq;
+ sg_req[i].mc_seq = mc_seq;
sg_req[i].len = len;
mem += len;
@@ -1304,11 +1286,28 @@ static struct dma_chan *tegra_dma_of_xlate(struct of_phandle_args *dma_spec,
return chan;
}
+static const struct tegra_dma_channel_regs tegra186_reg_offsets = {
+ .csr = 0x0,
+ .status = 0x4,
+ .csre = 0x8,
+ .src = 0xc,
+ .dst = 0x10,
+ .high_addr = 0x14,
+ .mc_seq = 0x18,
+ .mmio_seq = 0x1c,
+ .wcount = 0x20,
+ .wxfer = 0x24,
+ .wstatus = 0x28,
+ .err_status = 0x30,
+ .fixed_pattern = 0x34,
+};
+
static const struct tegra_dma_chip_data tegra186_dma_chip_data = {
.nr_channels = 32,
.channel_reg_size = SZ_64K,
.max_dma_count = SZ_1G,
.hw_support_pause = false,
+ .channel_regs = &tegra186_reg_offsets,
.terminate = tegra_dma_stop_client,
};
@@ -1317,6 +1316,7 @@ static const struct tegra_dma_chip_data tegra194_dma_chip_data = {
.channel_reg_size = SZ_64K,
.max_dma_count = SZ_1G,
.hw_support_pause = true,
+ .channel_regs = &tegra186_reg_offsets,
.terminate = tegra_dma_pause,
};
@@ -1325,6 +1325,7 @@ static const struct tegra_dma_chip_data tegra234_dma_chip_data = {
.channel_reg_size = SZ_64K,
.max_dma_count = SZ_1G,
.hw_support_pause = true,
+ .channel_regs = &tegra186_reg_offsets,
.terminate = tegra_dma_pause_noerr,
};
@@ -1345,7 +1346,7 @@ MODULE_DEVICE_TABLE(of, tegra_dma_of_match);
static int tegra_dma_program_sid(struct tegra_dma_channel *tdc, int stream_id)
{
- unsigned int reg_val = tdc_read(tdc, TEGRA_GPCDMA_CHAN_MCSEQ);
+ unsigned int reg_val = tdc_read(tdc, tdc->regs->mc_seq);
reg_val &= ~(TEGRA_GPCDMA_MCSEQ_STREAM_ID0_MASK);
reg_val &= ~(TEGRA_GPCDMA_MCSEQ_STREAM_ID1_MASK);
@@ -1353,7 +1354,7 @@ static int tegra_dma_program_sid(struct tegra_dma_channel *tdc, int stream_id)
reg_val |= FIELD_PREP(TEGRA_GPCDMA_MCSEQ_STREAM_ID0_MASK, stream_id);
reg_val |= FIELD_PREP(TEGRA_GPCDMA_MCSEQ_STREAM_ID1_MASK, stream_id);
- tdc_write(tdc, TEGRA_GPCDMA_CHAN_MCSEQ, reg_val);
+ tdc_write(tdc, tdc->regs->mc_seq, reg_val);
return 0;
}
@@ -1419,6 +1420,7 @@ static int tegra_dma_probe(struct platform_device *pdev)
tdc->chan_base_offset = TEGRA_GPCDMA_CHANNEL_BASE_ADDR_OFFSET +
i * cdata->channel_reg_size;
snprintf(tdc->name, sizeof(tdc->name), "gpcdma.%d", i);
+ tdc->regs = cdata->channel_regs;
tdc->tdma = tdma;
tdc->id = i;
tdc->slave_id = -1;
--
2.50.1
^ permalink raw reply related
* [PATCH v6 03/10] dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property
From: Akhil R @ 2026-03-31 10:22 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: <20260331102303.33181-1-akhilrajeev@nvidia.com>
Add iommu-map property to specify separate stream IDs for each DMA
channel. This enables each channel to be in its own IOMMU domain,
keeping memory isolated from other devices sharing the same DMA
controller.
Define the constraints such that if the channel and stream IDs are
contiguous, a single entry can map all the channels, but if the
channels or stream IDs are non-contiguous support multiple entries.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
index 64f1e9d9896d..bc093c783d98 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
@@ -14,6 +14,7 @@ description: |
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Rajesh Gumasta <rgumasta@nvidia.com>
+ - Akhil R <akhilrajeev@nvidia.com>
properties:
compatible:
@@ -49,6 +50,14 @@ properties:
iommus:
maxItems: 1
+ iommu-map:
+ description:
+ Maps DMA channel numbers to IOMMU stream IDs. A single entry can map all
+ channels when stream IDs are contiguous. In systems where the channels or
+ stream IDs are not contiguous, multiple entries may be needed.
+ minItems: 1
+ maxItems: 32
+
dma-coherent: true
dma-channel-mask:
--
2.50.1
^ permalink raw reply related
* [PATCH v6 04/10] dmaengine: tegra: Make reset control optional
From: Akhil R @ 2026-03-31 10:22 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: <20260331102303.33181-1-akhilrajeev@nvidia.com>
On Tegra264, reset is not available for the driver to control as
this is handled by the boot firmware. Hence make the reset control
optional and update the error message to reflect the correct error.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
drivers/dma/tegra186-gpc-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
index 5948fbf32c21..a0522a992ebc 100644
--- a/drivers/dma/tegra186-gpc-dma.c
+++ b/drivers/dma/tegra186-gpc-dma.c
@@ -1381,10 +1381,10 @@ static int tegra_dma_probe(struct platform_device *pdev)
if (IS_ERR(tdma->base_addr))
return PTR_ERR(tdma->base_addr);
- tdma->rst = devm_reset_control_get_exclusive(&pdev->dev, "gpcdma");
+ tdma->rst = devm_reset_control_get_optional_exclusive(&pdev->dev, "gpcdma");
if (IS_ERR(tdma->rst)) {
return dev_err_probe(&pdev->dev, PTR_ERR(tdma->rst),
- "Missing controller reset\n");
+ "Failed to get controller reset\n");
}
reset_control_reset(tdma->rst);
--
2.50.1
^ permalink raw reply related
* [PATCH v6 02/10] arm64: tegra: Remove fallback compatible for GPCDMA
From: Akhil R @ 2026-03-31 10:22 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: <20260331102303.33181-1-akhilrajeev@nvidia.com>
Remove the fallback compatible string "nvidia,tegra186-gpcdma" for GPCDMA
in Tegra264. Tegra186 compatible cannot work on Tegra264 because of the
register offset changes and absence of the reset property.
Fixes: 65ef237e4810 ("arm64: tegra: Add Tegra264 support")
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 24cc2c51a272..af077420d7d9 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3208,7 +3208,7 @@ agic_page5: interrupt-controller@99b0000 {
};
gpcdma: dma-controller@8400000 {
- compatible = "nvidia,tegra264-gpcdma", "nvidia,tegra186-gpcdma";
+ compatible = "nvidia,tegra264-gpcdma";
reg = <0x0 0x08400000 0x0 0x210000>;
interrupts = <GIC_SPI 584 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 585 IRQ_TYPE_LEVEL_HIGH>,
--
2.50.1
^ permalink raw reply related
* [PATCH v6 01/10] dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional
From: Akhil R @ 2026-03-31 10:22 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: <20260331102303.33181-1-akhilrajeev@nvidia.com>
On Tegra264, GPCDMA reset control is not exposed to Linux and is handled
by the boot firmware.
Although reset was not exposed in Tegra234 as well, the firmware supported
a dummy reset which just returns success on reset without doing an actual
reset. This is also not supported in Tegra264 BPMP. Therefore mark 'reset'
and 'reset-names' properties as required only for devices prior to
Tegra264.
This also necessitates that the Tegra264 compatible be standalone and
cannot have the fallback compatible of Tegra186. Since there is no
functional impact, we keep reset as required for Tegra234 to avoid
breaking the ABI.
Fixes: bb8c97571db5 ("dt-bindings: dma: Add Tegra264 compatible string")
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 23 +++++++++++++------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
index 0dabe9bbb219..64f1e9d9896d 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
@@ -15,16 +15,14 @@ maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Rajesh Gumasta <rgumasta@nvidia.com>
-allOf:
- - $ref: dma-controller.yaml#
-
properties:
compatible:
oneOf:
- - const: nvidia,tegra186-gpcdma
+ - enum:
+ - nvidia,tegra264-gpcdma
+ - nvidia,tegra186-gpcdma
- items:
- enum:
- - nvidia,tegra264-gpcdma
- nvidia,tegra234-gpcdma
- nvidia,tegra194-gpcdma
- const: nvidia,tegra186-gpcdma
@@ -60,12 +58,23 @@ required:
- compatible
- reg
- interrupts
- - resets
- - reset-names
- "#dma-cells"
- iommus
- dma-channel-mask
+allOf:
+ - $ref: dma-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-gpcdma
+ then:
+ required:
+ - resets
+ - reset-names
+
additionalProperties: false
examples:
--
2.50.1
^ permalink raw reply related
* [PATCH v6 00/10] Add GPCDMA support in Tegra264
From: Akhil R @ 2026-03-31 10:22 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
This series adds support for GPCDMA in Tegra264 with additional
support for separate stream ID for each channel. Tegra264 GPCDMA
controller has changes in the register offsets and uses 41-bit
addressing for memory. Add changes in the tegra186-gpc-dma driver
to support these.
v5->v6:
- Replace dev_err() with dev_err_probe() in the probe function for fixed
return values also.
v4->v5:
- Use dev_err_probe() when returning error from the probe function.
- Remove tegra194 and tegra234 compatible from the reset 'if' condition
in the bindings as suggested in v2 (which I missed).
v3->v4:
- Split device tree changes to two patches.
- Reordered patches to have fixes first.
- Added fixes tag to dt-bindings and device tree changes.
v2->v3:
- Add description for iommu-map property and update commit descriptions.
- Use enum for compatible string instead of const.
- Remove unused registers from struct tegra_dma_channel_regs.
- Use devm_of_dma_controller_register() to register the DMA controller.
- Remove return value check for mask setting in the driver as the bitmask
value is always greater than 32.
v1->v2:
- Fix dt_bindings_check warnings
- Drop fallback compatible "nvidia,tegra186-gpcdma" from Tegra264 DT
- Use dma_addr_t for sg_req src/dst fields and drop separate high_add
variable and check for the addr_bits only when programming the
registers.
- Update address width to 39 bits for Tegra234 and before since the SMMU
supports only up to 39 bits till Tegra234.
- Add a patch to do managed DMA controller registration.
- Describe the second iteration in the probe.
- Update commit descriptions.
Akhil R (10):
dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional
arm64: tegra: Remove fallback compatible for GPCDMA
dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property
dmaengine: tegra: Make reset control optional
dmaengine: tegra: Use struct for register offsets
dmaengine: tegra: Support address width > 39 bits
dmaengine: tegra: Use managed DMA controller registration
dmaengine: tegra: Use iommu-map for stream ID
dmaengine: tegra: Add Tegra264 support
arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
.../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 32 +-
.../arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 4 +
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 3 +-
drivers/dma/tegra186-gpc-dma.c | 429 +++++++++++-------
4 files changed, 284 insertions(+), 184 deletions(-)
--
2.50.1
^ permalink raw reply
* Re: [PATCH V3 1/3] net: stmmac: Fix PTP ref clock for Tegra234
From: Krzysztof Kozlowski @ 2026-03-31 10:18 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: <01f56e6f-5459-4a96-9042-8a003a340fab@nvidia.com>
On 31/03/2026 12:14, Jon Hunter wrote:
>
> On 26/03/2026 08:32, Krzysztof Kozlowski wrote:
>
> ...
>
>>> @@ -257,9 +258,23 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
>>> if (!mgbe->clks)
>>> return -ENOMEM;
>>>
>>> - for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++)
>>> + /*
>>> + * Older device-trees use 'ptp-ref' rather than 'ptp_ref'.
>>> + * Fall back to the legacy name when 'ptp_ref' is absent.
>>> + */
>>> + use_legacy_ptp = of_property_match_string(pdev->dev.of_node,
>>> + "clock-names", "ptp_ref") < 0;
>>> +
>>> + for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++) {
>>> mgbe->clks[i].id = mgbe_clks[i];
>>>
>>> + if (use_legacy_ptp && !strcmp(mgbe_clks[i], "ptp_ref")) {
>>
>> Why index 0 is not valid? And why -EINVAL would be considered as legacy
>> clock present?
>
> Index 0 is valid. However, yes I guess that treating an -EINVAL from
> of_property_match_string() is not correct. I will switch the logic to be ...
>
> use_legacy_ptp = of_property_match_string(pdev->dev.of_node,
> "clock-names", "ptp-ref") >= 0;
No, apologies, I think my comment was not correct and your reply made me
rethink. I missed final "< 0" in of_property_match_string().
So the code is good, you do not store index in 'use_legacy_ptp', but the
error return value.
Can you however make it more obvious code, so something like:
if (of_property_match_string...))
use_legacy_ptp = true;;
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V3 1/3] net: stmmac: Fix PTP ref clock for Tegra234
From: Jon Hunter @ 2026-03-31 10:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
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: <20260326-gigantic-tentacled-hornet-cbdb8d@quoll>
On 26/03/2026 08:32, Krzysztof Kozlowski wrote:
...
>> @@ -257,9 +258,23 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
>> if (!mgbe->clks)
>> return -ENOMEM;
>>
>> - for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++)
>> + /*
>> + * Older device-trees use 'ptp-ref' rather than 'ptp_ref'.
>> + * Fall back to the legacy name when 'ptp_ref' is absent.
>> + */
>> + use_legacy_ptp = of_property_match_string(pdev->dev.of_node,
>> + "clock-names", "ptp_ref") < 0;
>> +
>> + for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++) {
>> mgbe->clks[i].id = mgbe_clks[i];
>>
>> + if (use_legacy_ptp && !strcmp(mgbe_clks[i], "ptp_ref")) {
>
> Why index 0 is not valid? And why -EINVAL would be considered as legacy
> clock present?
Index 0 is valid. However, yes I guess that treating an -EINVAL from
of_property_match_string() is not correct. I will switch the logic to be ...
use_legacy_ptp = of_property_match_string(pdev->dev.of_node,
"clock-names", "ptp-ref") >= 0;
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 04/12] i3c: master: Support ACPI enumeration
From: Akhil R @ 2026-03-31 10:09 UTC (permalink / raw)
To: thierry.reding
Cc: Frank.Li, acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, fredrik.markstrom, jonathanh, krzk, lenb,
linux-acpi, linux-hwmon, linux-i3c, linux-kernel, linux-tegra,
linux, lkp, llvm, miquel.raynal, oe-kbuild-all, p.zabel, rafael,
robert.moore, robh
In-Reply-To: <acO_PUjS_VG07qcS@orome>
On Wed, 25 Mar 2026 11:59:12 +0100, Thierry Reding wrote:
> On Tue, Mar 24, 2026 at 10:52:15PM +0530, Akhil R wrote:
>> On Tue, 24 Mar 2026 09:43:27 +0100, Alexandre Belloni wrote:
>>
>> ...
>>
>> >> #include <linux/acpi.h> is added in PATCH 03/12. The functions' prototypes
>> >> are present in acpi.h. I think the bot checked this patch individually,
>> >> or did I miss something?
>> >>
>> >
>> > #include <acpi/acpi_bus.h> is behind an #ifdef in acpi.h and your code
>> > is not.
>>
>> Thanks for pointing Alexandre and Guenter. I also noticed that we do not
>> have stub functions for a few of the acpi_* functions in #else.
>>
>> Looks like I will have to guard calls to these functions under
>> #ifdef CONFIG_ACPI.
>
> Alternatively it might make sense to add the stubs in a separate patch.
> I don't know if they were purposefully left out or nobody's ever run
> into the lack of these before.
I looked into this and it turns out to be more involved than expected,
and requires adding stubs at multiple layers. We may end up either
sneaking in only what we require or a non-trivial change which may
involve too many parameters.
If you would agree, I will guard the ACPI calls used in this patchset with
#ifdef CONFIG_ACPI to keep things self-contained. If you think adding the
stubs is worthwhile, we can take them up as a separate series.
Best Regards,
Akhil
^ permalink raw reply
* Re: [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 9:50 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <act9hqxjL6wZ25dP@orome>
On 31/03/2026 10:25, Thierry Reding wrote:
>
>>> dt-bindings: phy: tegra-xusb: Document Type C support
>>
>> No acks, but that is waiting for one month so it is fine.
>
> It's got a Reviewed-by from Rob and there were no corresponding driver
> changes associated with it. There's literally no reason for this to go
> in through a subsystem tree.
There are reasons - process and technical:
1. It's a subsystem maintainer's patch, not yours. You rather should
have reason to take someone else's patches.
2. Conflict in that file.
>
>>> 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
>>
>> That's even my subsystem and I did not ack it. You did not even sent it
>> to me as requested by MAINTAINERS file (+dt is ignore alias), so
>> obviously I did not even had a chance to ack it.
>
> Ugh... really? I was Cc'ed to you as a DT maintainer as well as the
> devicetree mailing list, so I'm sure you've seen it. This had also been
Really, you are supposed to use get_maintainers.pl. Not invent the CC
list, not come with own filtered list.
I understand that my non dt address disappears when running
get_maintainers.pl on entire set.
But if you sent that patch targetting subsystem instead of combining 6
or 7 subsystems at once, it would pop up.
And yes, you are not supposed to mix 7 different subsystems in single
patchset. That's basic!
But sure, let's skip memory controllers patch cc list and:
> reviewed by Rob a long time ago, and honestly, it's also quite trivial.
> It's been on the list for a month and there were no objections, so it
> does pass all of the criteria you mentioned before.
No objections because you did not cc people. How can you claim "no
objections from person foo" if you do not cc person "foo", because you
do not use get_maintainers.pl?
Look, find me here phy mantainers:
https://lore.kernel.org/all/20260223143305.3771383-7-thierry.reding@kernel.org/
>
>> And we even had few days ago talk were I explained you how these
>> bindings must go. Seeing pull request completely ignoring that
>> discussion is just huge surprise.
>>
>> No, it cannot go in. Send patches to proper maintainers first.
>
> Stop making these baseless accusations, Krzysztof. You were on Cc and
Not using get_maintainers.pl so not ccing right address is not baseless.
This is the fact.
Neither phy, nor interrupts, nor clocks were sent to right people.
You mixed 6 or 7 different subsystems in on patchset, but you call my
remarks as baseless. You use several adjectives "trivial", "baseless",
but no actual facts.
Final commentary:
Stop taking patches from other subsystems, just because you want to
streamline your DTS. You are bypassing other subsystems review, other
people trees, and that's not acceptable.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 9:35 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <acuE-URAuRvmtd4u@orome>
On 31/03/2026 10:43, Thierry Reding wrote:
>>>> Maybe they had more time for previous versions, but
>>>> nevertheless it is also part of other patchset, so it will get into the
>>>> kernel other tree and nothing on v3 posting:
>>>> https://lore.kernel.org/all/20260326135855.2795149-4-thierry.reding@kernel.org/
>>>> gives hints that there will be cross tree merge.
>>>
>>> Maybe look at the cover letter:
>>>
>>> https://lore.kernel.org/all/20260326135855.2795149-1-thierry.reding@kernel.org/
>>>
>>> I clearly pointed out the build dependencies and suggested a shared
>>> branch to resolve them in both trees. Given that the bindings were
>>
>> No problem, that's a valid solution. Can you point me with a lore link
>> to the shared branch posting (these tags/pull requests must be posted on
>> the lists)? Or to an ack from PCI maintainers?
>>
>> The commit itself does not have an Ack, but maybe was just missed.
>
> Yes, the DT bindings patch does not have an Acked-by, but again, I
> didn't think that was necessary, especially since we were going to have
> a cross-merge anyway.
>
> Here's the PR for PCI:
>
> https://lore.kernel.org/linux-tegra/20260329155040.1448158-1-thierry.reding@kernel.org/
Thanks, this solves my question. A note in the pull message (not
necessarily in the tag) would also solve it, BTW.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Thierry Reding @ 2026-03-31 8:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <e5327cd9-4aa1-4e26-b748-dd1af29e6fdb@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3992 bytes --]
On Tue, Mar 31, 2026 at 10:00:01AM +0200, Krzysztof Kozlowski wrote:
> On 31/03/2026 09:53, Thierry Reding wrote:
> > On Mon, Mar 30, 2026 at 01:45:24PM +0200, Krzysztof Kozlowski wrote:
> >> On 29/03/2026 17:10, 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
> >>
> >>
> >> This is unreviewed/unacked binding where PCI maintainers had 1 day to
> >> react to your v3.
> >
> > Rob gave a reviewed-by on this about a week ago:
> >
> > https://lore.kernel.org/linux-tegra/177440189257.2451552.18196101830235626115.robh@kernel.org/
>
> Rob, although knows a lot about PCI, is not a formally a PCI subsystem
> maintainer.
>
> >
> > In my experience the PCI maintainers typically defer review of the DT
> > bindings to DT maintainers, so I considered Rob's R-b sufficient.
>
> Sure and they acknowledge this, that review is done and patch can go
> other way, with "Ack".
No they don't. The vast majority of the PCI DT bindings patches are
indeed applied by the PCI maintainers, but for those that aren't (there
are, admittedly, only a handful over the last few years) there were no
Acked-bys from the PCI maintainers.
> Where is the Ack?
Again, this is where your rules start to fail to meet demands. As it is,
the only option that we have is to get DT and drivers merged, then wait
for an entire cycle before we can merge the DT parts, otherwise we break
DT validation.
> >
> >> Maybe they had more time for previous versions, but
> >> nevertheless it is also part of other patchset, so it will get into the
> >> kernel other tree and nothing on v3 posting:
> >> https://lore.kernel.org/all/20260326135855.2795149-4-thierry.reding@kernel.org/
> >> gives hints that there will be cross tree merge.
> >
> > Maybe look at the cover letter:
> >
> > https://lore.kernel.org/all/20260326135855.2795149-1-thierry.reding@kernel.org/
> >
> > I clearly pointed out the build dependencies and suggested a shared
> > branch to resolve them in both trees. Given that the bindings were
>
> No problem, that's a valid solution. Can you point me with a lore link
> to the shared branch posting (these tags/pull requests must be posted on
> the lists)? Or to an ack from PCI maintainers?
>
> The commit itself does not have an Ack, but maybe was just missed.
Yes, the DT bindings patch does not have an Acked-by, but again, I
didn't think that was necessary, especially since we were going to have
a cross-merge anyway.
Here's the PR for PCI:
https://lore.kernel.org/linux-tegra/20260329155040.1448158-1-thierry.reding@kernel.org/
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Thierry Reding @ 2026-03-31 8:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <406ca5ed-4a3e-48ba-94ad-d88c53b09299@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4247 bytes --]
On Mon, Mar 30, 2026 at 01:39:49PM +0200, Krzysztof Kozlowski wrote:
> On 29/03/2026 17:10, 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
>
> Why are you taking subsystem patches? This was posted on 26th of March
> and was not acked by PCI maintainers.
>
> How the bindings should go is already documented, so there is no
> question here.
We've discussed this in the past and I still think your rule about DT
bindings needing to go in through the driver tree is impractical. Yes,
it means you get around the checkpatch warning about undocumented
compatible strings, but at the expense of a new warning in the Tegra
tree because the bindings aren't there.
> The question was whether you can take them if subsystem maintainer is
> non-responsive and yes, you can. You gave PCI maintainers one day before
> applying it.
I did not get a response to my suggestion about creating a shared
branch, which was included in v1 already. So I went ahead and did what
I thought was best. PCI maintainers are free to not pull this if they
don't want to. I also offered to address any further review comments if
there were any.
> > dt-bindings: phy: tegra-xusb: Document Type C support
>
> No acks, but that is waiting for one month so it is fine.
It's got a Reviewed-by from Rob and there were no corresponding driver
changes associated with it. There's literally no reason for this to go
in through a subsystem tree.
> > 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
>
> That's even my subsystem and I did not ack it. You did not even sent it
> to me as requested by MAINTAINERS file (+dt is ignore alias), so
> obviously I did not even had a chance to ack it.
Ugh... really? I was Cc'ed to you as a DT maintainer as well as the
devicetree mailing list, so I'm sure you've seen it. This had also been
reviewed by Rob a long time ago, and honestly, it's also quite trivial.
It's been on the list for a month and there were no objections, so it
does pass all of the criteria you mentioned before.
> And we even had few days ago talk were I explained you how these
> bindings must go. Seeing pull request completely ignoring that
> discussion is just huge surprise.
>
> No, it cannot go in. Send patches to proper maintainers first.
Stop making these baseless accusations, Krzysztof. You were on Cc and
DT maintainers have seen and reviewed these patches. You're grasping at
straws to somehow try to make my life miserable and I don't know why.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Thierry Reding @ 2026-03-31 8:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <63b6c9da-4c0e-497c-a2a6-8aa5e74e2adb@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
On Tue, Mar 31, 2026 at 09:59:07AM +0200, Krzysztof Kozlowski wrote:
> On 29/03/2026 17:10, 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)
> >
>
> I guess related to my question why patches were applied one day after
> the list:
>
> Days in linux-next:
> ----------------------------------------
> 0 | ++++++++ (8)
>
> Commits with 0 days in linux-next (8 of 8: 100.0%):
> ...
>
> So you exposed soc tree to all sort of integration issues. No, please
> keep them for some days in the next before you send them to soc, to
> allow people to test and eventually complain/report issues.
Most issues would've been caught by daily bots already. A lot of these
probably were in linux-next but changed SHAs because I rebased them on
top of the PCI bindings patch to keep the shared branch as small as
possible.
I also do fairly extensive build testing on my side before sending those
pull requests, so I don't think I've exposed the SoC tree to an unfair
amount of integration issues.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 8:00 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <act77WcvwYedN0Q8@orome>
On 31/03/2026 09:53, Thierry Reding wrote:
> On Mon, Mar 30, 2026 at 01:45:24PM +0200, Krzysztof Kozlowski wrote:
>> On 29/03/2026 17:10, 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
>>
>>
>> This is unreviewed/unacked binding where PCI maintainers had 1 day to
>> react to your v3.
>
> Rob gave a reviewed-by on this about a week ago:
>
> https://lore.kernel.org/linux-tegra/177440189257.2451552.18196101830235626115.robh@kernel.org/
Rob, although knows a lot about PCI, is not a formally a PCI subsystem
maintainer.
>
> In my experience the PCI maintainers typically defer review of the DT
> bindings to DT maintainers, so I considered Rob's R-b sufficient.
Sure and they acknowledge this, that review is done and patch can go
other way, with "Ack".
Where is the Ack?
>
>> Maybe they had more time for previous versions, but
>> nevertheless it is also part of other patchset, so it will get into the
>> kernel other tree and nothing on v3 posting:
>> https://lore.kernel.org/all/20260326135855.2795149-4-thierry.reding@kernel.org/
>> gives hints that there will be cross tree merge.
>
> Maybe look at the cover letter:
>
> https://lore.kernel.org/all/20260326135855.2795149-1-thierry.reding@kernel.org/
>
> I clearly pointed out the build dependencies and suggested a shared
> branch to resolve them in both trees. Given that the bindings were
No problem, that's a valid solution. Can you point me with a lore link
to the shared branch posting (these tags/pull requests must be posted on
the lists)? Or to an ack from PCI maintainers?
The commit itself does not have an Ack, but maybe was just missed.
> reviewed by Rob and they are needed in both the subsystem tree
> (according to your own rules) as well as the DT tree (for validation),
> I included the bindings in the shared branch as well.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 7:59 UTC (permalink / raw)
To: Thierry Reding, arm, soc
Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-6-thierry.reding@kernel.org>
On 29/03/2026 17:10, 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)
>
I guess related to my question why patches were applied one day after
the list:
Days in linux-next:
----------------------------------------
0 | ++++++++ (8)
Commits with 0 days in linux-next (8 of 8: 100.0%):
...
So you exposed soc tree to all sort of integration issues. No, please
keep them for some days in the next before you send them to soc, to
allow people to test and eventually complain/report issues.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Thierry Reding @ 2026-03-31 7:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <7b9bc5d1-7a1d-456c-b280-5f4dc969609d@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]
On Mon, Mar 30, 2026 at 01:45:24PM +0200, Krzysztof Kozlowski wrote:
> On 29/03/2026 17:10, 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
>
>
> This is unreviewed/unacked binding where PCI maintainers had 1 day to
> react to your v3.
Rob gave a reviewed-by on this about a week ago:
https://lore.kernel.org/linux-tegra/177440189257.2451552.18196101830235626115.robh@kernel.org/
In my experience the PCI maintainers typically defer review of the DT
bindings to DT maintainers, so I considered Rob's R-b sufficient.
> Maybe they had more time for previous versions, but
> nevertheless it is also part of other patchset, so it will get into the
> kernel other tree and nothing on v3 posting:
> https://lore.kernel.org/all/20260326135855.2795149-4-thierry.reding@kernel.org/
> gives hints that there will be cross tree merge.
Maybe look at the cover letter:
https://lore.kernel.org/all/20260326135855.2795149-1-thierry.reding@kernel.org/
I clearly pointed out the build dependencies and suggested a shared
branch to resolve them in both trees. Given that the bindings were
reviewed by Rob and they are needed in both the subsystem tree
(according to your own rules) as well as the DT tree (for validation),
I included the bindings in the shared branch as well.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [GIT PULL 4/7] ARM: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 7:42 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <act5kGG-4mZl0j3p@orome>
On 31/03/2026 09:38, Thierry Reding wrote:
>> Why does the DTS branch has mach code? Tag message mentions legacy
>> cleanup only and such cleanup should not cause mixing independent
>> hardware description (DTS) with drivers.
>
> The DT additions for PAZ00 replace the legacy code, so it makes sense to
> replace it in one patch, otherwise we'd be introducing a bisectability
> problem.
OK, please mention it in the tag message in the future.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 4/7] ARM: tegra: Device tree changes for v7.1-rc1
From: Thierry Reding @ 2026-03-31 7:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <058d79b7-3d4c-4f0a-a95f-b2e3582a4fa7@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]
On Mon, Mar 30, 2026 at 01:46:32PM +0200, Krzysztof Kozlowski wrote:
> On 29/03/2026 17:10, Thierry Reding wrote:
> > ----------------------------------------------------------------
> > 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.
> >
> > ----------------------------------------------------------------
> > Dmitry Torokhov (1):
> > ARM: tegra: paz00: Configure WiFi rfkill switch through device tree
> >
> > Svyatoslav Ryhel (8):
> > ARM: tegra: Add SOCTHERM support on Tegra114
> > ARM: tn7: Adjust panel node
> > ARM: tegra: lg-x3: Add panel and bridge nodes
> > ARM: tegra: lg-x3: Add USB and power related nodes
> > ARM: tegra: lg-x3: Add node for capacitive buttons
> > ARM: tegra: Add ACTMON node to Tegra114 device tree
> > ARM: tegra: Add External Memory Controller node on Tegra114
> > ARM: tegra: transformers: Add connector node
> >
> > arch/arm/boot/dts/nvidia/tegra114-tn7.dts | 13 +-
> > arch/arm/boot/dts/nvidia/tegra114.dtsi | 221 +++++++++++++++++++++++
> > arch/arm/boot/dts/nvidia/tegra20-paz00.dts | 8 +
> > arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 21 ++-
> > arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 23 +++
> > arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 33 ++++
> > arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 174 +++++++++++++++++-
> > arch/arm/mach-tegra/Makefile | 2 -
> > arch/arm/mach-tegra/board-paz00.c | 56 ------
> > arch/arm/mach-tegra/board.h | 2 -
> > arch/arm/mach-tegra/tegra.c | 4 -
>
> Why does the DTS branch has mach code? Tag message mentions legacy
> cleanup only and such cleanup should not cause mixing independent
> hardware description (DTS) with drivers.
The DT additions for PAZ00 replace the legacy code, so it makes sense to
replace it in one patch, otherwise we'd be introducing a bisectability
problem.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/7] pwm: tegra: Add support for Tegra264
From: Thierry Reding @ 2026-03-31 7:36 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <20260331-t264-pwm-v4-6-c041659677cf@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 6390 bytes --]
On Tue, Mar 31, 2026 at 11:12:18AM +0900, Mikko Perttunen wrote:
> 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.
This paragraph exceeds the 80 character limit. Technically checkpatch
now has a limit of 100 characters, so it probably doesn't warn about
this, but I've seen some people say that we should still stay within
the 80 character limit if easily doable (which would be the case here).
I don't care much either way, so it's ultimately up to Uwe. Other than
that looks good:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/7] pwm: tegra: Parametrize enable register offset
From: Thierry Reding @ 2026-03-31 7:30 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <20260331-t264-pwm-v4-4-c041659677cf@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
On Tue, Mar 31, 2026 at 11:12:16AM +0900, Mikko Perttunen wrote:
> 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(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/7] pwm: tegra: Avoid hard-coded max clock frequency
From: Thierry Reding @ 2026-03-31 7:29 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <20260331-t264-pwm-v4-2-c041659677cf@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
On Tue, Mar 31, 2026 at 11:12:14AM +0900, Mikko Perttunen wrote:
> 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(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/7] pwm: tegra: Parametrize enable register offset
From: Thierry Reding @ 2026-03-31 7:27 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <177483744958.916245.860145469758840098.b4-reply@b4>
[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]
On Mon, Mar 30, 2026 at 11:24:09AM +0900, Mikko Perttunen wrote:
> On 2026-03-26 10:47 +0100, Thierry Reding wrote:
> > On Wed, Mar 25, 2026 at 07:17:02PM +0900, Mikko Perttunen wrote:
> > > 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 cf54f75d92a5..22d709986e8c 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;
> > > + }
> >
> > This looks incomplete for the Tegra264 case where
> >
> > pc->soc->enable_reg == PWM_CSR_1
> >
> > >
> > > pwm_writel(pwm, PWM_CSR_0, val);
> >
> > I think we need another write for PWM_CSR_1 here to properly toggle the
> > PWM_ENABLE bit on Tegra264.
> >
> > Or am I missing something?
>
> This check is here just so we don't change the value of PWM_ENABLE when
> writing the CSR_0 register. The function doesn't write to CSR_1 so
> nothing needs to be done on Tegra264.
>
> I agree it's not the clearest, but it'll get cleaned up when adding
> support for configurable depth, as at that point we will need to write
> both registers on Tegra264.
Ah... nevermind. I realize now that we're not touching PWM_CSR_1 at all
in tegra_pwm_config(), so there's no need to explicitly set PWM_ENABLE.
If moving to the new APIs, that would need to change, but for the legacy
PWM callbacks this is probably fine.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v4 7/7] arm64: tegra: Add PWM controllers on 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, Thierry Reding,
Mikko Perttunen
In-Reply-To: <20260331-t264-pwm-v4-0-c041659677cf@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Tegra264 has a number of PWM controllers that are similar but
incompatible with those found on earlier chips.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[mperttunen: Adjust commit message]
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 72 ++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 7644a41d5f72..13fd04068016 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3336,6 +3336,18 @@ i2c3: i2c@c610000 {
status = "disabled";
};
+ pwm4: pwm@c6a0000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc6a0000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM4>;
+ resets = <&bpmp TEGRA264_RESET_PWM4>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
pmc: pmc@c800000 {
compatible = "nvidia,tegra264-pmc";
reg = <0x0 0x0c800000 0x0 0x100000>,
@@ -3538,6 +3550,66 @@ i2c16: i2c@c430000 {
status = "disabled";
};
+ pwm2: pwm@c5e0000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc5e0000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM2>;
+ resets = <&bpmp TEGRA264_RESET_PWM2>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
+ pwm3: pwm@c5f0000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc5f0000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM3>;
+ resets = <&bpmp TEGRA264_RESET_PWM3>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
+ pwm5: pwm@c600000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc600000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM5>;
+ resets = <&bpmp TEGRA264_RESET_PWM5>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
+ pwm9: pwm@c610000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc610000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM9>;
+ resets = <&bpmp TEGRA264_RESET_PWM9>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
+ pwm10: pwm@c620000 {
+ compatible = "nvidia,tegra264-pwm";
+ reg = <0x0 0xc620000 0x0 0x10000>;
+ status = "disabled";
+
+ clocks = <&bpmp TEGRA264_CLK_PWM10>;
+ resets = <&bpmp TEGRA264_RESET_PWM10>;
+ reset-names = "pwm";
+
+ #pwm-cells = <2>;
+ };
+
i2c0: i2c@c630000 {
compatible = "nvidia,tegra264-i2c";
reg = <0x00 0x0c630000 0x0 0x10000>;
--
2.53.0
^ permalink raw reply related
* [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
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