Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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.
>>
>>


  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