All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yaodong Li <yaodong.li@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com>
Subject: Re: [PATCH v9 3/7] drm/i915/guc: Implement dynamic GuC WOPCM offset and size
Date: Fri, 9 Feb 2018 11:32:30 -0800	[thread overview]
Message-ID: <63a8cd57-2320-b6d2-5b4b-f46af7b907cc@intel.com> (raw)
In-Reply-To: <op.zd6inwn0xaggs7@mwajdecz-mobl1.ger.corp.intel.com>

On 02/09/2018 09:24 AM, Michal Wajdeczko wrote:
>> +    struct intel_guc *guc =
>> +        container_of(guc_wopcm, struct intel_guc, wopcm);
>
> If you define this as "wopcm_to_guc" inline helper, then maybe
> all your functions could take "wopcm" as first parameter?
First thought is this is only one time work, so wanted to keep the code
simple. The following patch added an inline for this when there are more
places needs to use wopcm_to_guc.
>
>> +    u32 reserved = guc_wopcm_context_reserved_size(guc);
>> +    u32 offset, size, top;
>> +    int err;
>> -    /* On BXT, the top of WOPCM is reserved for RC6 context */
>> -    if (IS_GEN9_LP(i915))
>> -        size -= BXT_GUC_WOPCM_RC6_RESERVED;
>> +    if (!guc_fw_size)
>> +        return -EINVAL;
>
> As there are many reasons to fail, maybe it would be good idea to
> add at least DRM_DEBUG_DRIVER to each failing condition?
>
Honestly. that's my personal preference too:-) but I am trying to catch
up with the coding style to avoid these redundancies.
I thought there are redundant because:
0) this func is called by uc_init which will print error message when
     this failed.
1) there are two types of errors: invalid parameters. or FW sizes are
      too big to fit in WOPCM. the upper layer error message could 
easily reflect
     these info by check the error code.
and more, I now do feel some of these checks are redundant and will
remove them. :-)
>> +
>> +    if (reserved >= WOPCM_DEFAULT_SIZE)
>> +        return -E2BIG;
>
> Do we really need to check this every time in runtime?
> I think we can enforce this as GEM_BUG_ON here or in
> guc_wopcm_context_reserved_size() function.
>
Yes. this is redundant since we are total having control
of this value.
>
>> +/* 24KB at the end of GuC WOPCM is reserved for RC6 CTX on BXT. */
>> +#define BXT_GUC_WOPCM_RC6_CTX_RESERVED    (24 << 10)
>> +
>> +/*
>> + * GuC WOPCM starts at 144KB (GUC_WOPCM_RESERVED + 128KB reserved 
>> for GuC
>> + * firmware loading) from GuC WOPCM offset on BXT.
>> + */
>> +#define GEN9_GUC_WOPCM_OFFSET        (144 << 10)
>
> Other BXT specific macro (BXT_GUC_WOPCM_RC6_CTX_RESERVED) was
> defined with BXT_ prefix ... can we use common prefix?
>
BXT suggests this is only for Gen9 LP while Gen9 means it's for all Gen9.:-)

Regards,
-Jackie
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-02-09 19:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08 23:03 [PATCH v9 1/7] drm/i915/guc: Move GuC WOPCM related code into separate files Jackie Li
2018-02-08 23:03 ` [PATCH v9 2/7] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset Jackie Li
2018-02-09  8:01   ` Joonas Lahtinen
2018-02-08 23:03 ` [PATCH v9 3/7] drm/i915/guc: Implement dynamic GuC WOPCM offset and size Jackie Li
2018-02-09  9:31   ` Joonas Lahtinen
2018-02-09 17:24   ` Michal Wajdeczko
2018-02-09 19:32     ` Yaodong Li [this message]
2018-02-08 23:03 ` [PATCH v9 4/7] drm/i915/guc: Add support to return CNL specific reserved GuC WOPCM size Jackie Li
2018-02-09  9:37   ` Joonas Lahtinen
2018-02-08 23:03 ` [PATCH v9 5/7] drm/i915/guc: Add HuC firmware size related restriction for Gen9 and CNL A0 Jackie Li
2018-02-09  9:57   ` Joonas Lahtinen
2018-02-08 23:03 ` [PATCH v9 6/7] drm/i915/guc: Check the locking status of GuC WOPCM registers Jackie Li
2018-02-08 23:31   ` Chris Wilson
2018-02-09  5:05     ` Yaodong Li
2018-02-09 10:47   ` Joonas Lahtinen
2018-02-11  0:36     ` Yaodong Li
2018-02-09 19:42   ` Michal Wajdeczko
2018-02-09 22:12     ` Yaodong Li
2018-02-08 23:03 ` [PATCH v9 7/7] HAX Enable GuC Submission for CI Jackie Li
2018-02-08 23:29 ` ✗ Fi.CI.BAT: failure for series starting with [v9,1/7] drm/i915/guc: Move GuC WOPCM related code into separate files Patchwork
2018-02-09 16:46 ` [PATCH v9 1/7] " Michal Wajdeczko
2018-02-09 19:38   ` Yaodong Li
2018-02-09 20:59     ` Michel Thierry

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=63a8cd57-2320-b6d2-5b4b-f46af7b907cc@intel.com \
    --to=yaodong.li@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michal.wajdeczko@intel.com \
    --cc=sujaritha.sundaresan@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.