From: "Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
To: "Nilawar, Badal" <badal.nilawar@intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Matthew Brost <matthew.brost@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>,
<intel-xe@lists.freedesktop.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [PATCH v2 01/23] drm/xe: Error handling in xe_force_wake_get()
Date: Mon, 23 Sep 2024 18:06:51 +0530 [thread overview]
Message-ID: <b2046f22-5ac3-4ae8-a81b-28bfc733fa1a@intel.com> (raw)
In-Reply-To: <276dee6b-4d2d-4ed2-b141-76b311dd269a@intel.com>
On 19-09-2024 18:02, Nilawar, Badal wrote:
>
>
> On 19-09-2024 17:06, Jani Nikula wrote:
>> On Thu, 19 Sep 2024, "Nilawar, Badal" <badal.nilawar@intel.com> wrote:
>>> On 18-09-2024 12:49, Jani Nikula wrote:
>>>> On Wed, 18 Sep 2024, "Ghimiray, Himal Prasad"
>>>> <himal.prasad.ghimiray@intel.com> wrote:
>>>>> On 18-09-2024 00:20, Matthew Brost wrote:
>>>>>> On Tue, Sep 17, 2024 at 11:18:47AM +0530, Nilawar, Badal wrote:
>>>>>>> On 13-09-2024 18:47, Ghimiray, Himal Prasad wrote:
>>>>>>>> Agreed implementation/usage will be same, will use explicit type
>>>>>>>> for
>>>>>>>> clarity.
>>>>>>>> IMO typedef unsigned int xe_wakeref_t is sufficient instead of
>>>>>>>> typedef unsigned long xe_wakeref_t;
>>>>>>>
>>>>>>> I agree with this.
>>>>>>>
>>>>>>
>>>>>> What? Really? I thought it was pretty clear rule in kernel programing
>>>>>> not use typedefs [1]. Reading through conditions acceptable and I
>>>>>> don't
>>>>>> use anything applies to this series, maybe a) applies but not really
>>>>>> convinced. The example in a) is a pte_t which can likely change
>>>>>> based on
>>>>>> platform target whereas here we only have one target and see no
>>>>>> reason
>>>>>> this needs to be opaque.
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>> [1] https://www.kernel.org/doc/html/v4.14/process/coding-
>>>>>> style.html#typedefs
>>>>>
>>>>>
>>>>> While running checkpatch on my changes, patchwork had also issued a
>>>>> WARNING: NEW_TYPEDEFS: do not add new typedefs. I reviewed the
>>>>> usage in
>>>>> the Linux kernel tree and found it used in many places, which led
>>>>> me to
>>>>> assume it was safe. I now realize that I should have been more careful
>>>>> in understanding the context of its usage and referred to the kernel
>>>>> coding guidelines. This was an oversight on my part.
>>>>>
>>>>> Since this doesn’t impact the CI or runtime, I will avoid reverting to
>>>>> unsigned int immediately and will hold off until I receive the other
>>>>> review comments. I will incorporate the changes to revert it in
>>>>> subsequent versions while also addressing the other review comments.
>>>>> Thank you for bringing this to the attention.
>>>>
>>>> If you end up replicating intel_wakeref_t from i915, and go as deep as
>>>> the rabbit hole goes, you'll realize intel_wakeref_t is a pointer
>>>> disguised as an unsigned long. It's a struct ref_tracker * when you
>>>> have
>>>> certain configs enabled.
>>>>
>>>> You could just use struct ref_tracker * everywhere. It's an opaque type
>>>> to start with.
>>>
>>> The original idea of using typedef for the fw return mask was for the
>>> sake of clarity. However, Matt B pointed that the use of typedef in this
>>> instance is not in accordance with the Linux kernel coding standards.
>>> Additionally, I agree with Matt B that there is no need for the fw
>>> return mask to be opaque; therefore, it is preferable to maintain the
>>> use of unsigned int.
>>
>> I'm not sure it's a hot idea to explicitly state that the return value
>> is a domain mask. The callers shouldn't need to care, should they?
>>
>> For example:
>>
>> + fw_ref = xe_force_wake_get(gt_to_fw(gt), XE_FORCEWAKE_ALL);
>> + if (fw_ref != XE_FORCEWAKE_ALL) {
>>
>> Under what conditions do you expect this to happen? Shouldn't
>
> If any of the requested domain is not refcounted (not awake) above
> condition will happen.
>
>> xe_force_wake_get() flag cases where it couldn't deliver what you asked?
>
> Internally xe_force_wake_get prints drm_notice when requested domain set
> ack times out. In the driver currently caller is sometime returning
> there is domain ack failure.
>
> usage: where XE_WARN_ON(fw_ref != XE_FORCEWAKE_ALL) is used, which looks
> redundant to me it can be moved inside xe_force_wake_get.
Agreed, the driver should warn, in case of domain ack timeout failure,
irrespective of whether user wants to continue or not. Will move the
check inside the forcewake_get itself. Similar to what _put will do in
[v4,02/23] drm/xe: Modify xe_force_wake_put to handle _get returned mask
>
> case a)
> fw_ref = xe_force_wake_get(gt_to_fw(gt), XE_FORCEWAKE_ALL);
> XE_WARN_ON(fw_ref != XE_FORCEWAKE_ALL)
>
> //Here caller doesn't bother about all the domains are awake
> and continues
> func_b()
>
> xe_force_wake_put((gt_to_fw(gt), fw_ref); // Puts only domains
> awake by xe_force_wake_get.
>
> case b)
> fw_ref = xe_force_wake_get(gt_to_fw(gt), XE_FORCEWAKE_ALL);
> if(fw_ref != XE_FORCEWAKE_ALL) {
> xe_force_wake_put((gt_to_fw(gt), fw_ref); // Puts only domains
> awake by xe_force_wake_get.
> return -ETIMEDOUT;
> }
>
> func_b()
>
> xe_force_wake_put((gt_to_fw(gt), fw_ref);
>
>
> As of now driver have both usages and this patch series caters both.
>
> Regards,
> Badal
>
>>
>> BR,
>> Jani.
>>
>>
next prev parent reply other threads:[~2024-09-23 12:37 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 19:15 [PATCH v2 00/23] Fix xe_force_wake_get() failure handling Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 01/23] drm/xe: Error handling in xe_force_wake_get() Himal Prasad Ghimiray
2024-09-12 21:31 ` Michal Wajdeczko
2024-09-13 3:59 ` Ghimiray, Himal Prasad
2024-09-13 11:26 ` Michal Wajdeczko
2024-09-13 13:17 ` Ghimiray, Himal Prasad
2024-09-17 5:48 ` Nilawar, Badal
2024-09-17 18:50 ` Matthew Brost
2024-09-18 6:32 ` Ghimiray, Himal Prasad
2024-09-18 7:19 ` Jani Nikula
2024-09-18 14:50 ` Jani Nikula
2024-09-19 11:07 ` Nilawar, Badal
2024-09-19 11:36 ` Jani Nikula
2024-09-19 12:32 ` Nilawar, Badal
2024-09-23 12:36 ` Ghimiray, Himal Prasad [this message]
2024-09-23 16:15 ` Rodrigo Vivi
2024-09-12 19:15 ` [PATCH v2 02/23] drm/xe: Modify xe_force_wake_put to handle _get returned mask Himal Prasad Ghimiray
2024-09-12 21:34 ` Michal Wajdeczko
2024-09-13 4:05 ` Ghimiray, Himal Prasad
2024-09-12 19:15 ` [PATCH v2 03/23] drm/xe/device: Update handling of xe_force_wake_get return Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 04/23] drm/xe/hdcp: " Himal Prasad Ghimiray
2024-09-13 4:23 ` Kandpal, Suraj
2024-09-12 19:15 ` [PATCH v2 05/23] drm/xe/gsc: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 06/23] drm/xe/gt: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 07/23] drm/xe/xe_gt_idle: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 08/23] drm/xe/devcoredump: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 09/23] drm/xe/tests/mocs: Update xe_force_wake_get() return handling Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 10/23] drm/xe/mocs: Update handling of xe_force_wake_get return Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 11/23] drm/xe/xe_drm_client: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 12/23] drm/xe/xe_gt_debugfs: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 13/23] drm/xe/guc: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 14/23] drm/xe/huc: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 15/23] drm/xe/oa: Handle force_wake_get failure in xe_oa_stream_init() Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 16/23] drm/xe/pat: Update handling of xe_force_wake_get return Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 17/23] drm/xe/gt_tlb_invalidation_ggtt: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 18/23] drm/xe/xe_reg_sr: " Himal Prasad Ghimiray
2024-09-12 19:15 ` [PATCH v2 19/23] drm/xe/query: " Himal Prasad Ghimiray
2024-09-12 19:16 ` [PATCH v2 20/23] drm/xe/vram: " Himal Prasad Ghimiray
2024-09-12 19:16 ` [PATCH v2 21/23] drm/xe: forcewake debugfs open fails on xe_forcewake_get failure Himal Prasad Ghimiray
2024-09-12 19:16 ` [PATCH v2 22/23] drm/xe: Ensure __must_check for xe_force_wake_get() return Himal Prasad Ghimiray
2024-09-12 19:16 ` [PATCH v2 23/23] drm/xe: Change return type to void for xe_force_wake_put Himal Prasad Ghimiray
2024-09-13 4:09 ` Ghimiray, Himal Prasad
2024-09-13 10:24 ` Michal Wajdeczko
2024-09-13 13:26 ` Ghimiray, Himal Prasad
2024-09-13 13:31 ` Ghimiray, Himal Prasad
2024-09-16 18:42 ` Nilawar, Badal
2024-09-17 4:48 ` Ghimiray, Himal Prasad
2024-09-17 4:52 ` Nilawar, Badal
2024-09-17 5:21 ` Nilawar, Badal
2024-09-17 5:24 ` Ghimiray, Himal Prasad
2024-09-12 19:24 ` ✓ CI.Patch_applied: success for Fix xe_force_wake_get() failure handling (rev2) Patchwork
2024-09-12 19:24 ` ✓ CI.checkpatch: " Patchwork
2024-09-12 19:25 ` ✓ CI.KUnit: " Patchwork
2024-09-12 19:37 ` ✓ CI.Build: " Patchwork
2024-09-12 19:39 ` ✓ CI.Hooks: " Patchwork
2024-09-12 19:41 ` ✓ CI.checksparse: " Patchwork
2024-09-12 19:58 ` ✗ CI.BAT: failure " Patchwork
2024-09-13 12:01 ` ✗ 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=b2046f22-5ac3-4ae8-a81b-28bfc733fa1a@intel.com \
--to=himal.prasad.ghimiray@intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=nirmoy.das@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