From: Yazen Ghannam <yazen.ghannam@amd.com>
To: John Allen <john.allen@amd.com>
Cc: yazen.ghannam@amd.com, bp@alien8.de, linux-edac@vger.kernel.org,
tony.luck@intel.com, linux-kernel@vger.kernel.org,
avadhut.naik@amd.com, muralidhara.mk@amd.com
Subject: Re: [PATCH 2/4] RAS: ATL: Expand helpers for adding and removing base and hole
Date: Tue, 26 Mar 2024 10:13:21 -0400 [thread overview]
Message-ID: <010bb8bb-cc48-4b83-b46b-14e5efc753a8@amd.com> (raw)
In-Reply-To: <ZgHQB2yasP1DeLcy@AUS-L1-JOHALLEN.amd.com>
On 3/25/24 15:27, John Allen wrote:
> On Mon, Mar 18, 2024 at 11:28:48AM -0400, Yazen Ghannam wrote:
>> On 3/14/24 12:35, John Allen wrote:
>>> Data fabric 4.5 denormalization will need to frequently add and remove
>>
>> More specifically, the non-power-of-2 cases will need this.
>>
>>> the base and the legacy MMIO hole. Modify existing helpers to improve DF
>>> 4.5 denormalization flow and add helper to remove the base and hole.
>>
>> Please write the what/context, why/issue, and how/fix information as
>> separate paragraphs even if they're just a single sentence each. I think
>> this helps to find the details more easily.
>>
>>>
>>> Signed-off-by: John Allen <john.allen@amd.com>
>>> ---
>>> drivers/ras/amd/atl/core.c | 43 ++++++++++++++++++++++------------
>>> drivers/ras/amd/atl/internal.h | 3 +++
>>> 2 files changed, 31 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/ras/amd/atl/core.c b/drivers/ras/amd/atl/core.c
>>> index c1710d233adb..cafdfc57d929 100644
>>> --- a/drivers/ras/amd/atl/core.c
>>> +++ b/drivers/ras/amd/atl/core.c
>>> @@ -49,15 +49,26 @@ static bool legacy_hole_en(struct addr_ctx *ctx)
>>> return FIELD_GET(DF_LEGACY_MMIO_HOLE_EN, reg);
>>> }
>>> -static int add_legacy_hole(struct addr_ctx *ctx)
>>> +static u64 add_legacy_hole(struct addr_ctx *ctx, u64 addr)
>>> {
>>> if (!legacy_hole_en(ctx))
>>> - return 0;
>>> + return addr;
>>> - if (ctx->addr >= df_cfg.dram_hole_base)
>>> - ctx->addr += (BIT_ULL(32) - df_cfg.dram_hole_base);
>>> + if (addr >= df_cfg.dram_hole_base)
>>> + addr += (BIT_ULL(32) - df_cfg.dram_hole_base);
>>> - return 0;
>>> + return addr;
>>> +}
>>> +
>>> +static u64 remove_legacy_hole(struct addr_ctx *ctx, u64 addr)
>>> +{
>>> + if (!legacy_hole_en(ctx))
>>> + return addr;
>>> +
>>> + if (addr >= df_cfg.dram_hole_base)
>>> + addr -= (BIT_ULL(32) - df_cfg.dram_hole_base);
>>> +
>>> + return addr;
>>> }
>>> static u64 get_base_addr(struct addr_ctx *ctx)
>>> @@ -72,14 +83,16 @@ static u64 get_base_addr(struct addr_ctx *ctx)
>>> return base_addr << DF_DRAM_BASE_LIMIT_LSB;
>>> }
>>> -static int add_base_and_hole(struct addr_ctx *ctx)
>>> +u64 add_base_and_hole(struct addr_ctx *ctx, u64 addr)
>>> {
>>> - ctx->ret_addr += get_base_addr(ctx);
>>> -
>>> - if (add_legacy_hole(ctx))
>>> - return -EINVAL;
>>> + addr += get_base_addr(ctx);
>>> + return add_legacy_hole(ctx, addr);
>>> +}
>>> - return 0;
>>> +u64 remove_base_and_hole(struct addr_ctx *ctx, u64 addr)
>>> +{
>>> + addr -= get_base_addr(ctx);
>>> + return remove_legacy_hole(ctx, addr);
>>
>> This should be the inverse of the "add" operation, I think. So remove
>> the legacy hole first, then remove the base address.
>>
>>> }
>>> static bool late_hole_remove(struct addr_ctx *ctx)
>>> @@ -123,14 +136,14 @@ unsigned long norm_to_sys_addr(u8 socket_id, u8 die_id, u8 coh_st_inst_id, unsig
>>> if (denormalize_address(&ctx))
>>> return -EINVAL;
>>> - if (!late_hole_remove(&ctx) && add_base_and_hole(&ctx))
>>> - return -EINVAL;
>>> + if (!late_hole_remove(&ctx))
>>> + ctx.ret_addr = add_base_and_hole(&ctx, ctx.ret_addr);
>>> if (dehash_address(&ctx))
>>> return -EINVAL;
>>> - if (late_hole_remove(&ctx) && add_base_and_hole(&ctx))
>>> - return -EINVAL;
>>> + if (late_hole_remove(&ctx))
>>> + ctx.ret_addr = add_base_and_hole(&ctx, ctx.ret_addr);
>>> if (addr_over_limit(&ctx))
>>> return -EINVAL;
>>> diff --git a/drivers/ras/amd/atl/internal.h b/drivers/ras/amd/atl/internal.h
>>> index 1413c8ddc6c5..05b870fcb24e 100644
>>> --- a/drivers/ras/amd/atl/internal.h
>>> +++ b/drivers/ras/amd/atl/internal.h
>>> @@ -236,6 +236,9 @@ int dehash_address(struct addr_ctx *ctx);
>>> unsigned long norm_to_sys_addr(u8 socket_id, u8 die_id, u8 coh_st_inst_id, unsigned long addr);
>>> unsigned long convert_umc_mca_addr_to_sys_addr(struct atl_err *err);
>>> +u64 add_base_and_hole(struct addr_ctx *ctx, u64 addr);
>>> +u64 remove_base_and_hole(struct addr_ctx *ctx, u64 addr);
>>
>> remove_base_and_hole() is only used in denormalize.c, correct? So why
>> not define it there as static? Other than trying to keep the code
>> together and symmetrical, I mean.
>
> In addition to keeping the two inverse functions together,
> remove_base_and_hole depends on other functions in core.c. So if we
> don't expose remove_base_and_hole in the header, then we would need to
> expose get_base_addr and remove_legacy_hole in the header.
> Alternatively, we could move remove_legacy_hole to denormalize.c and
> expose get_base_addr and legacy_hole_en in the header instead. So
> exposing one function that's the inverse of the other just looks better
> to me than exposing two.
>
Right, fair point. So what you have is good then.
Thanks,
Yazen
next prev parent reply other threads:[~2024-03-26 14:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 16:35 [PATCH 0/4] RAS: ATL: DF 4.5 NP2 Denormalization John Allen
2024-03-14 16:35 ` [PATCH 1/4] RAS: ATL: Read DRAM hole base early John Allen
2024-03-18 15:06 ` Yazen Ghannam
2024-03-14 16:35 ` [PATCH 2/4] RAS: ATL: Expand helpers for adding and removing base and hole John Allen
2024-03-18 15:28 ` Yazen Ghannam
2024-03-25 19:27 ` John Allen
2024-03-26 14:13 ` Yazen Ghannam [this message]
2024-03-14 16:35 ` [PATCH 3/4] RAS: ATL: Add map_bits_valid to header John Allen
2024-03-18 15:46 ` Yazen Ghannam
2024-03-25 19:57 ` John Allen
2024-03-26 13:47 ` Yazen Ghannam
2024-03-14 16:35 ` [PATCH 4/4] RAS: ATL: Implement DF 4.5 NP2 denormalization John Allen
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=010bb8bb-cc48-4b83-b46b-14e5efc753a8@amd.com \
--to=yazen.ghannam@amd.com \
--cc=avadhut.naik@amd.com \
--cc=bp@alien8.de \
--cc=john.allen@amd.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=muralidhara.mk@amd.com \
--cc=tony.luck@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.