From: Jon Hunter <jonathanh@nvidia.com>
To: Ketan Patil <ketanp@nvidia.com>,
krzk@kernel.org, thierry.reding@gmail.com
Cc: linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH v5 2/4] memory: tegra: Group register and fields
Date: Wed, 7 Jan 2026 11:53:43 +0000 [thread overview]
Message-ID: <61cf00f8-7f9e-4739-8946-a37c0b18ab02@nvidia.com> (raw)
In-Reply-To: <20251219114354.2727906-3-ketanp@nvidia.com>
On 19/12/2025 11:43, Ketan Patil wrote:
> The current register definitions are not in sorted order. Sort these
> registers according to their address. Put bit fields of the
> corresponding registers below the register definitions to clearly
> identify which fields belongs to which registers.
>
> Signed-off-by: Ketan Patil <ketanp@nvidia.com>
> ---
> drivers/memory/tegra/mc.h | 49 +++++++++++++++++++++------------------
> 1 file changed, 27 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
> index a7f20850741f..482f836f7816 100644
> --- a/drivers/memory/tegra/mc.h
> +++ b/drivers/memory/tegra/mc.h
> @@ -13,13 +13,31 @@
> #include <soc/tegra/mc.h>
>
> #define MC_INTSTATUS 0x00
> +/* Bit field of MC_INTSTATUS register */
> +#define MC_INT_DECERR_EMEM BIT(6)
> +#define MC_INT_INVALID_GART_PAGE BIT(7)
> +#define MC_INT_SECURITY_VIOLATION BIT(8)
> +#define MC_INT_ARBITRATION_EMEM BIT(9)
> +#define MC_INT_INVALID_SMMU_PAGE BIT(10)
> +#define MC_INT_INVALID_APB_ASID_UPDATE BIT(11)
> +#define MC_INT_DECERR_VPR BIT(12)
> +#define MC_INT_SECERR_SEC BIT(13)
> +#define MC_INT_DECERR_MTS BIT(16)
> +#define MC_INT_DECERR_GENERALIZED_CARVEOUT BIT(17)
> +#define MC_INT_DECERR_ROUTE_SANITY BIT(20)
> +
> #define MC_INTMASK 0x04
> #define MC_GART_ERROR_REQ 0x30
> #define MC_EMEM_ADR_CFG 0x54
> +#define MC_EMEM_ADR_CFG_EMEM_NUMDEV BIT(0)
> +
> #define MC_DECERR_EMEM_OTHERS_STATUS 0x58
> #define MC_SECURITY_VIOLATION_STATUS 0x74
> #define MC_EMEM_ARB_CFG 0x90
> #define MC_EMEM_ARB_OUTSTANDING_REQ 0x94
> +#define MC_EMEM_ARB_OUTSTANDING_REQ_HOLDOFF_OVERRIDE BIT(30)
> +#define MC_EMEM_ARB_OUTSTANDING_REQ_LIMIT_ENABLE BIT(31)
> +
> #define MC_EMEM_ARB_TIMING_RCD 0x98
> #define MC_EMEM_ARB_TIMING_RP 0x9c
> #define MC_EMEM_ARB_TIMING_RC 0xa0
> @@ -41,44 +59,31 @@
> #define MC_EMEM_ARB_OVERRIDE 0xe8
> #define MC_TIMING_CONTROL_DBG 0xf8
> #define MC_TIMING_CONTROL 0xfc
> +#define MC_TIMING_UPDATE BIT(0)
> +
> #define MC_GLOBAL_INTSTATUS 0xf24
>
> -#define MC_INT_DECERR_ROUTE_SANITY BIT(20)
> -#define MC_INT_DECERR_GENERALIZED_CARVEOUT BIT(17)
> -#define MC_INT_DECERR_MTS BIT(16)
> -#define MC_INT_SECERR_SEC BIT(13)
> -#define MC_INT_DECERR_VPR BIT(12)
> -#define MC_INT_INVALID_APB_ASID_UPDATE BIT(11)
> -#define MC_INT_INVALID_SMMU_PAGE BIT(10)
> -#define MC_INT_ARBITRATION_EMEM BIT(9)
> -#define MC_INT_SECURITY_VIOLATION BIT(8)
> -#define MC_INT_INVALID_GART_PAGE BIT(7)
> -#define MC_INT_DECERR_EMEM BIT(6)
> +/* Bit field of MC_ERR_STATUS_0 register */
> +#define MC_ERR_STATUS_RW BIT(16)
> +#define MC_ERR_STATUS_SECURITY BIT(17)
> +#define MC_ERR_STATUS_NONSECURE BIT(25)
> +#define MC_ERR_STATUS_WRITABLE BIT(26)
> +#define MC_ERR_STATUS_READABLE BIT(27)
>
> #define MC_ERR_STATUS_TYPE_SHIFT 28
> #define MC_ERR_STATUS_TYPE_INVALID_SMMU_PAGE (0x6 << 28)
> #define MC_ERR_STATUS_TYPE_MASK (0x7 << 28)
> -#define MC_ERR_STATUS_READABLE BIT(27)
> -#define MC_ERR_STATUS_WRITABLE BIT(26)
> -#define MC_ERR_STATUS_NONSECURE BIT(25)
> +
> #define MC_ERR_STATUS_ADR_HI_SHIFT 20
> #define MC_ERR_STATUS_ADR_HI_MASK 0x3
> -#define MC_ERR_STATUS_SECURITY BIT(17)
> -#define MC_ERR_STATUS_RW BIT(16)
> -
> -#define MC_EMEM_ADR_CFG_EMEM_NUMDEV BIT(0)
>
> #define MC_EMEM_ARB_CFG_CYCLES_PER_UPDATE(x) ((x) & 0x1ff)
> #define MC_EMEM_ARB_CFG_CYCLES_PER_UPDATE_MASK 0x1ff
>
> #define MC_EMEM_ARB_OUTSTANDING_REQ_MAX_MASK 0x1ff
Shouldn't the above masks be moved as well? Typically we put both the
masks and bits next to the associated registers.
> -#define MC_EMEM_ARB_OUTSTANDING_REQ_HOLDOFF_OVERRIDE BIT(30)
> -#define MC_EMEM_ARB_OUTSTANDING_REQ_LIMIT_ENABLE BIT(31)
>
> #define MC_EMEM_ARB_OVERRIDE_EACK_MASK 0x3
And this one.
Jon
--
nvpublic
next prev parent reply other threads:[~2026-01-07 11:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 11:43 [PATCH v5 0/4] memory: tegra: Add MC error logging support for Tegra264 SoC Ketan Patil
2025-12-19 11:43 ` [PATCH v5 1/4] memory: tegra: Group mc-err related registers Ketan Patil
2026-01-12 13:29 ` Thierry Reding
2025-12-19 11:43 ` [PATCH v5 2/4] memory: tegra: Group register and fields Ketan Patil
2026-01-07 11:53 ` Jon Hunter [this message]
2025-12-19 11:43 ` [PATCH v5 3/4] memory: tegra: Add support for multiple irqs Ketan Patil
2026-01-12 10:52 ` Thierry Reding
2025-12-19 11:43 ` [PATCH v5 4/4] memory: tegra: Add MC error logging support for Tegra264 Ketan Patil
2026-01-07 12:47 ` Jon Hunter
2026-01-07 12:57 ` Jon Hunter
2026-01-12 12:49 ` Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61cf00f8-7f9e-4739-8946-a37c0b18ab02@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=ketanp@nvidia.com \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®