From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>,
Matthew Brost <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 10/13] drm/xe/guc: Introduce the GuC Buffer Cache
Date: Wed, 18 Dec 2024 22:03:51 +0100 [thread overview]
Message-ID: <05d474ac-9d04-4c2e-9f0b-e24eb39fef39@intel.com> (raw)
In-Reply-To: <Z1yVX8wtuPn_6X9V@intel.com>
On 13.12.2024 21:13, Rodrigo Vivi wrote:
> On Fri, Dec 13, 2024 at 10:38:05AM -0800, Matthew Brost wrote:
>> On Thu, Dec 12, 2024 at 10:48:34PM +0100, Michal Wajdeczko wrote:
>>>
>>>
>>> On 12.12.2024 04:30, Matthew Brost wrote:
>>>> On Thu, Dec 12, 2024 at 02:01:38AM +0100, Michal Wajdeczko wrote:
>>>
>>> ...
>>>
>>>>> diff --git a/drivers/gpu/drm/xe/xe_guc_buf_types.h b/drivers/gpu/drm/xe/xe_guc_buf_types.h
>>>>> new file mode 100644
>>>>> index 000000000000..9e123d71c064
>>>>> --- /dev/null
>>>>> +++ b/drivers/gpu/drm/xe/xe_guc_buf_types.h
>>>>> @@ -0,0 +1,28 @@
>>>>> +/* SPDX-License-Identifier: MIT */
>>>>> +/*
>>>>> + * Copyright © 2024 Intel Corporation
>>>>> + */
>>>>> +
>>>>> +#ifndef _XE_GUC_BUF_TYPES_H_
>>>>> +#define _XE_GUC_BUF_TYPES_H_
>>>>> +
>>>>> +struct drm_suballoc;
>>>>> +struct xe_sa_manager;
>>>>> +
>>>>> +/**
>>>>> + * struct xe_guc_buf_cache - GuC Data Buffer Cache.
>>>>> + */
>>>>> +struct xe_guc_buf_cache {
>>>>> + /* private: internal sub-allocation manager */
>>>>
>>>> I think this generate kerenl doc complaints.
>>>>
>>>
>>> or maybe not, see [1] which says:
>>>
>>> "Inside a struct or union description, you can use the private: and
>>> public: comment tags. Structure fields that are inside a private: area
>>> are not listed in the generated output documentation."
>>>
>>> and CI.hooks is also fine with it
>>>
>>> [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#members
>>>
>>
>> Ah, ok. However AFIAK we don't use this style anywhere in Xe so maybe
>> double check with the maintainers on there preference.
>
> As long as it is in-line member doc comment we should be okay.
>
> But do you intend to expand these 2 structs later? It is kind of strange
no, they are just simple wrappers around SA types, but allows strict
type checks to avoid mismatch with ordinary SA objects
> that they are exported in a _types.h with only 'private' members. In
> the current way it doesn't look like we need this _types.h at all and
> only static struct in .h or .c itself....
can't be static in .c since we need full definition externally
and IMO we shouldn't define them in .h either as our "rule" is to keep
all type definitions in _types.h, since some types, xe_guc_buf_cache,
will be referenced directly by other _types.h files (guc_types.h)
>
>>
>> Matt
>>
>>>> i.e. Should be:
>>>>
>>>> /* @sam: private - internal sub-allocation manager */
>>>>
>>>>> + struct xe_sa_manager *sam;
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct xe_guc_buf - GuC Data Buffer Reference.
>>>>> + */
>>>>> +struct xe_guc_buf {
>>>>> + /* private: internal sub-allocation reference */
>>>>
>>>> Same here.
>>>>
>>>> Matt
>>>>
>>>>> + struct drm_suballoc *sa;
>>>>> +};
>>>>> +
>>>>> +#endif
next prev parent reply other threads:[~2024-12-18 21:03 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-12 1:01 [PATCH 00/13] The xe_sa_manager based GuC Buffer Cache Michal Wajdeczko
2024-12-12 1:01 ` [PATCH 01/13] drm/xe/sa: Always call drm_suballoc_manager_fini() Michal Wajdeczko
2024-12-12 3:03 ` Matthew Brost
2024-12-12 1:01 ` [PATCH 02/13] drm/xe/sa: Drop redundant NULL assignments Michal Wajdeczko
2024-12-12 3:03 ` Matthew Brost
2024-12-12 1:01 ` [PATCH 03/13] drm/xe/sa: Cleanup internal BO data at device removal Michal Wajdeczko
2024-12-12 3:07 ` Matthew Brost
2024-12-12 1:01 ` [PATCH 04/13] drm/xe/sa: Drop useless is_iomem member Michal Wajdeczko
2024-12-12 3:09 ` Matthew Brost
2024-12-18 20:53 ` Michal Wajdeczko
2024-12-12 1:01 ` [PATCH 05/13] drm/xe/sa: Improve error message on init failure Michal Wajdeczko
2024-12-12 3:10 ` Matthew Brost
2024-12-12 1:01 ` [PATCH 06/13] drm/xe/sa: Tidy up coding style in init() Michal Wajdeczko
2024-12-12 3:11 ` Matthew Brost
2024-12-12 1:01 ` [PATCH 07/13] drm/xe/sa: Allow making suballocations using custom gfp flags Michal Wajdeczko
2024-12-12 3:12 ` Matthew Brost
2024-12-12 1:01 ` [PATCH 08/13] drm/xe/sa: Allow creating suballocator with custom guard size Michal Wajdeczko
2024-12-12 3:23 ` Matthew Brost
2024-12-12 21:57 ` Michal Wajdeczko
2024-12-12 22:48 ` Matthew Brost
2024-12-12 1:01 ` [PATCH 09/13] drm/xe/sa: Minor header cleanups Michal Wajdeczko
2024-12-12 3:14 ` Matthew Brost
2024-12-12 1:01 ` [PATCH 10/13] drm/xe/guc: Introduce the GuC Buffer Cache Michal Wajdeczko
2024-12-12 3:30 ` Matthew Brost
2024-12-12 21:48 ` Michal Wajdeczko
2024-12-13 18:38 ` Matthew Brost
2024-12-13 20:13 ` Rodrigo Vivi
2024-12-18 21:03 ` Michal Wajdeczko [this message]
2024-12-19 20:28 ` Rodrigo Vivi
2024-12-12 1:01 ` [PATCH 11/13] drm/xe/pf: Use GuC Buffer Cache during VFs provisioning Michal Wajdeczko
2024-12-12 3:34 ` Matthew Brost
2024-12-12 22:02 ` Michal Wajdeczko
2024-12-12 1:01 ` [PATCH 12/13] drm/xe/kunit: Allow to replace xe_managed_bo_create_pin_map() Michal Wajdeczko
2024-12-12 1:01 ` [PATCH 13/13] drm/xe/kunit: Add KUnit tests for GuC Buffer Cache Michal Wajdeczko
2024-12-12 3:36 ` Matthew Brost
2024-12-18 21:06 ` Michal Wajdeczko
2024-12-12 2:20 ` ✓ CI.Patch_applied: success for The xe_sa_manager based " Patchwork
2024-12-12 2:20 ` ✗ CI.checkpatch: warning " Patchwork
2024-12-12 2:21 ` ✓ CI.KUnit: success " Patchwork
2024-12-12 2:41 ` ✓ CI.Build: " Patchwork
2024-12-12 2:45 ` ✓ CI.Hooks: " Patchwork
2024-12-12 2:48 ` ✓ CI.checksparse: " Patchwork
2024-12-12 3:14 ` ✗ Xe.CI.BAT: failure " Patchwork
2024-12-12 8:50 ` ✗ Xe.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=05d474ac-9d04-4c2e-9f0b-e24eb39fef39@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@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