[Intel-xe] [PATCH v5 3/7] drm/sched: Move schedule policy to scheduler

[Luben Tuikov]

On 2023-10-12 00:31, Matthew Brost wrote:
> On Wed, Oct 11, 2023 at 08:39:55PM -0400, Luben Tuikov wrote:
>> On 2023-10-11 19:58, Matthew Brost wrote:
>>> Rather than a global modparam for scheduling policy, move the scheduling
>>> policy to scheduler so user can control each scheduler policy.
>>>
>>> v2:
>>>   - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
>>>   - Only include policy in scheduler (Luben)
>>> v3:
>>>   - use a ternary operator as opposed to an if-control (Luben)
>>>   - s/DRM_SCHED_POLICY_DEFAULT/DRM_SCHED_POLICY_UNSET/ (Luben)
>>>   - s/default_drm_sched_policy/drm_sched_policy_default/ (Luben)
>>>   - Update commit message (Boris)
>>>   - Fix v3d build (CI)
>>>   - s/bad_policies/drm_sched_policy_mismatch/ (Luben)
>>>   - Don't update modparam doc (Luben)
>>> v4:
>>>   - Fix alignment in msm_ringbuffer_new (Luben / checkpatch)
>>>
>>> Reviewed-by: Luben Tuikov <luben.tuikov at amd.com>
>>> Signed-off-by: Matthew Brost <matthew.brost at intel.com>
>>
>> Was the R-V added by hand? (As in editing the commit message manually?)
>>
> 
> Yes.
> 
>> I use automated tools for this which do not re-order the tags.
>> IOW, the S-O-B is first as this is how it appears in the patch,
>> then the R-V most probably added by automated tools, and then
>> any other as are tacked on by other automated tools.
>>
> 
> Ok, so always add tags in order starting with S-O-B?

Yes!

The S-O-B tag you add when you write the commit and then you post
it up to a mailing list, it's mandatory and it's always there.
It's most likely the first, top tag.

Then various other scripts and tools start adding tags in an automated way,
and those tags are just appended below any existing tags.

Generally, always follow a natural order (meaning least amount of energy
expenditure--if you have to edit to reorder, that is extra energy expenditure
and nature doesn't like that). Make it like a letter you'd get from or write to
your bank, attorney, etc.
	These are tags you add when you craft your commit:
Cc: goes first, followed by other tags whose values
Cc: are personal emails, i.e. people. These are people
Cc: you want to let know of this commit. This is followed
Cc: by other personal tags, for instance,
Co-developed-by: or
Suggested-by: Another personal tag is,
Reported-by: which must be followed by a Link tag with
Link: the link of the report. This could also be a link to anything else. You can also add a
Fixes: tag which should follow a --pretty %h (\"%s\") format.
Closes: link to the bug the patch closes
Signed-off-by: You
	Then scripts and tools (or even people) would append the tag list with:
Tested-by: someone reliable, could have more than one instance of this tag,
Acked-by: someone
Reviewed-by: someone

There are no empty lines between tags. They form a block paragraph as they would
if/when added by a script. (I never add _any_ tag manually.)

So, for instance, you may have:

Cc: Luben
Signed-off-by: Matt

And when the patch is R-V-ed this becomes (least amount of energy, append at the bottom),

Cc: Luben
Signed-off-by: Matt
Reviewed-by: Luben

Then other tags may be appended, depending on the path the patch takes to land in a tree.

Check out:
https://docs.kernel.org/process/5.Posting.html
https://docs.kernel.org/process/submitting-patches.html
https://docs.kernel.org/process/submit-checklist.html
And there's more resources to check out in the Documentation/process directory.
-- 
Regards,
Luben