From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: "Matthew Brost" <matthew.brost@intel.com>,
"Matt Roper" <matthew.d.roper@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Lucas De Marchi" <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/xe: Rename internal vram helper function
Date: Wed, 29 May 2024 13:25:03 +0200 [thread overview]
Message-ID: <46164a96-f72c-4991-a41d-eea299540d75@intel.com> (raw)
In-Reply-To: <ZlZXaouXdtj852Aq@DUT025-TGLU.fm.intel.com>
++ maintainers
On 29.05.2024 00:15, Matthew Brost wrote:
> On Tue, May 28, 2024 at 02:35:15PM -0700, Matt Roper wrote:
>> On Mon, May 27, 2024 at 07:35:53PM +0200, Michal Wajdeczko wrote:
>>> Drop no longer applicable "xe_mmio_" prefix and downgrade the
>>> existing kernel-doc for internal function to normal comment.
>>
>> As noted on the previous patch, there are several other functions with
>> "xe_" prefixes even though they're static (xe_resize_vram_bar,
>> xe_pci_resource_valid, xe_determine_lmem_bar_size, and the
>> xe_mmio_tile_vram_size you're updating here). Maybe we should drop the
>> "xe_" prefix from all of them (and "xe_mmio" from this one) before the
>> movement of VRAM code to a new file?
agree on doing all renames for consistency, but this time I just didn't
want to make too many cleanups in one shot, my focus was to do clear
code separation first
>>
>
> We have talked about this before and I think the consensous was "xe_"
> prefixes for static functions are fine, perhaps even desired. I can't
IMO use of "xe_foo" prefix for static functions is inconsistent (as its
name suggests that it is public function while OTOH it is declared as
static) and may mislead that it could be used in other compilation unit.
thus use of "xe_" (for static) should be rather discouraged but also at
the same time it shouldn't be treated as showstopper (with the hope
better name will be provided later)
> find a reference but I do recall a discussion on the list about this.
>
> I think the maintainers should make / document a rule wrt to "xe_"
> prefixes before we start making changes in this area as it is not clear.
before we start writing rules for static functions, better to focus only
on rules for public naming convention for the components, like:
files:
GOOD
xe_foo.ch
xe_foo_types.h
xe_foo_helpers.h
FINE
xe_gt_foo.ch
BAD
foo.ch
types:
GOOD
struct xe_foo_xxx
enum xe_foo_yyy
typedef xe_foo_zzz
BAD
struct foo
struct xe_bar
functions:
GOOD
xe_foo_bar(struct xe_foo *foo, ...)
FINE
xe_foo_bar(struct xe_device *xe, ...)
xe_gt_foo_bar(struct xe_gt *gt, ...)
BAD
xe_foo_bar(..., struct xe_foo *foo)
xe_bar_foo(struct xe_foo *foo, ...)
>
> Matt
>
>>
>> Matt
>>>
>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> ---
>>> drivers/gpu/drm/xe/xe_vram.c | 12 ++++++------
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
>>> index d8b81e4e050c..411e8d23fd4d 100644
>>> --- a/drivers/gpu/drm/xe/xe_vram.c
>>> +++ b/drivers/gpu/drm/xe/xe_vram.c
>>> @@ -192,8 +192,8 @@ static inline u64 get_flat_ccs_offset(struct xe_gt *gt, u64 tile_size)
>>> return offset;
>>> }
>>>
>>> -/**
>>> - * xe_mmio_tile_vram_size() - Collect vram size and offset information
>>> +/*
>>> + * tile_vram_size() - Collect vram size and offset information
>>> * @tile: tile to get info for
>>> * @vram_size: available vram (size - device reserved portions)
>>> * @tile_size: actual vram size
>>> @@ -211,8 +211,8 @@ static inline u64 get_flat_ccs_offset(struct xe_gt *gt, u64 tile_size)
>>> * NOTE: multi-tile bases will include the tile offset.
>>> *
>>> */
>>> -static int xe_mmio_tile_vram_size(struct xe_tile *tile, u64 *vram_size,
>>> - u64 *tile_size, u64 *tile_offset)
>>> +static int tile_vram_size(struct xe_tile *tile, u64 *vram_size,
>>> + u64 *tile_size, u64 *tile_offset)
>>> {
>>> struct xe_device *xe = tile_to_xe(tile);
>>> struct xe_gt *gt = tile->primary_gt;
>>> @@ -287,7 +287,7 @@ int xe_vram_probe(struct xe_device *xe)
>>>
>>> /* Get the size of the root tile's vram for later accessibility comparison */
>>> tile = xe_device_get_root_tile(xe);
>>> - err = xe_mmio_tile_vram_size(tile, &vram_size, &tile_size, &tile_offset);
>>> + err = tile_vram_size(tile, &vram_size, &tile_size, &tile_offset);
>>> if (err)
>>> return err;
>>>
>>> @@ -302,7 +302,7 @@ int xe_vram_probe(struct xe_device *xe)
>>>
>>> /* tile specific ranges */
>>> for_each_tile(tile, xe, id) {
>>> - err = xe_mmio_tile_vram_size(tile, &vram_size, &tile_size, &tile_offset);
>>> + err = tile_vram_size(tile, &vram_size, &tile_size, &tile_offset);
>>> if (err)
>>> return err;
>>>
>>> --
>>> 2.43.0
>>>
>>>
>>
>> --
>> Matt Roper
>> Graphics Software Engineer
>> Linux GPU Platform Enablement
>> Intel Corporation
next prev parent reply other threads:[~2024-05-29 11:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 17:35 [PATCH 0/5] VF: Setup VRAM based on received config data Michal Wajdeczko
2024-05-27 17:35 ` [PATCH 1/5] drm/xe: Move XEHP_MTCFG_ADDR register definition to xe_regs.h Michal Wajdeczko
2024-05-28 21:14 ` Matt Roper
2024-05-27 17:35 ` [PATCH 2/5] drm/xe: Move BAR definitions to dedicated file Michal Wajdeczko
2024-05-28 21:18 ` Matt Roper
2024-05-27 17:35 ` [PATCH 3/5] drm/xe: Promote VRAM initialization function to own file Michal Wajdeczko
2024-05-28 21:27 ` Matt Roper
2024-05-27 17:35 ` [PATCH 4/5] drm/xe: Rename internal vram helper function Michal Wajdeczko
2024-05-28 21:35 ` Matt Roper
2024-05-28 22:15 ` Matthew Brost
2024-05-29 11:25 ` Michal Wajdeczko [this message]
2024-05-29 11:50 ` Jani Nikula
2024-05-29 12:45 ` Michal Wajdeczko
2024-05-29 12:52 ` Jani Nikula
2024-05-29 16:22 ` Lucas De Marchi
2024-05-29 18:01 ` Jani Nikula
2024-05-29 20:03 ` Lucas De Marchi
2024-05-27 17:35 ` [PATCH 5/5] drm/xe/vf: Setup VRAM based on received config data Michal Wajdeczko
2024-05-28 21:50 ` Matt Roper
2024-05-27 17:42 ` ✓ CI.Patch_applied: success for VF: " Patchwork
2024-05-27 17:42 ` ✗ CI.checkpatch: warning " Patchwork
2024-05-27 17:43 ` ✓ CI.KUnit: success " Patchwork
2024-05-27 17:55 ` ✓ CI.Build: " Patchwork
2024-05-27 17:55 ` ✗ CI.Hooks: failure " Patchwork
2024-05-27 17:57 ` ✓ CI.checksparse: success " Patchwork
2024-05-27 18:28 ` ✗ CI.BAT: failure " Patchwork
2024-05-27 19:38 ` ✗ CI.FULL: " Patchwork
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=46164a96-f72c-4991-a41d-eea299540d75@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=thomas.hellstrom@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox