public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915/wopcm: Try to use already locked WOPCM layout
Date: Wed, 14 Aug 2019 14:32:18 -0700	[thread overview]
Message-ID: <f4a80c06-0332-62dd-cb67-f24fb99a33d2@intel.com> (raw)
In-Reply-To: <op.z6i5gtzoxaggs7@mwajdecz-mobl1.ger.corp.intel.com>



On 8/14/19 1:49 PM, Michal Wajdeczko wrote:
> On Wed, 14 Aug 2019 22:10:51 +0200, Daniele Ceraolo Spurio 
> <daniele.ceraolospurio@intel.com> wrote:
> 
>>
>>
>> On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
>>>   On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
>>>> If WOPCM layout is already locked in HW we shouldn't continue
>>>> with our own partitioning as it could be likely different and
>>>> we will be unable to enforce it and fail. Instead we should try
>>>> to reuse what is already programmed, maybe there will be a fit.
>>>>
>>>> This should enable us to reload driver with slightly different
>>>> HuC firmware (or even without HuC) without need to reboot.
>>>>
>>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>> Cc: Michal Winiarski <michal.winiarski@intel.com>
>>>> ---
>>>>   drivers/gpu/drm/i915/intel_wopcm.c | 29 +++++++++++++++++++++++++++--
>>>>   1 file changed, 27 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
>>>> b/drivers/gpu/drm/i915/intel_wopcm.c
>>>> index 2bda24200498..e5bc7b8a433e 100644
>>>> --- a/drivers/gpu/drm/i915/intel_wopcm.c
>>>> +++ b/drivers/gpu/drm/i915/intel_wopcm.c
>>>> @@ -154,6 +154,21 @@ static inline int check_hw_restriction(struct 
>>>> drm_i915_private *i915,
>>>>       return err;
>>>>   }
>>>> +static bool __wopcm_regs_locked(struct intel_uncore *uncore,
>>>> +                u32 *guc_wopcm_base, u32 *guc_wopcm_size)
>>>> +{
>>>> +    u32 reg_base = intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET);
>>>> +    u32 reg_size = intel_uncore_read(uncore, GUC_WOPCM_SIZE);
>>>> +
>>>> +    if (!(reg_size & GUC_WOPCM_SIZE_LOCKED) ||
>>>> +        !(reg_base & GUC_WOPCM_OFFSET_VALID))
>>>> +        return false;
>>>  Should we at least WARN in the unlikely case where only one of the 2 
>>> regs is locked?
> 
> I wanted just to cover valid case where both regs are locked so
> we can grab base/size as final.
> 
> If only single reg is locked, then we continue with our own partitioning
> as before, and fail during reg verification in uc_init_wopcm() where
> we already have WARNs
> 

That works

>>>
>>>> +
>>>> +    *guc_wopcm_base = reg_base & GUC_WOPCM_OFFSET_MASK;
>>>> +    *guc_wopcm_size = reg_size & GUC_WOPCM_SIZE_MASK;
>>>> +    return true;
>>>> +}
>>>> +
>>>>   /**
>>>>    * intel_wopcm_init() - Initialize the WOPCM structure.
>>>>    * @wopcm: pointer to intel_wopcm.
>>>> @@ -167,8 +182,9 @@ static inline int check_hw_restriction(struct 
>>>> drm_i915_private *i915,
>>>>   void intel_wopcm_init(struct intel_wopcm *wopcm)
>>>>   {
>>>>       struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
>>>> -    u32 guc_fw_size = 
>>>> intel_uc_fw_get_upload_size(&i915->gt.uc.guc.fw);
>>>> -    u32 huc_fw_size = 
>>>> intel_uc_fw_get_upload_size(&i915->gt.uc.huc.fw);
>>>> +    struct intel_gt *gt = &i915->gt;
>>>> +    u32 guc_fw_size = intel_uc_fw_get_upload_size(&gt->uc.guc.fw);
>>>> +    u32 huc_fw_size = intel_uc_fw_get_upload_size(&gt->uc.huc.fw);
>>>>       u32 ctx_rsvd = context_reserved_size(i915);
>>>>       u32 guc_wopcm_base;
>>>>       u32 guc_wopcm_size;
>>>> @@ -185,6 +201,14 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
>>>>       if (i915_inject_probe_failure(i915))
>>>>           return;
>>>> +    if (__wopcm_regs_locked(gt->uncore, &guc_wopcm_base, 
>>>> &guc_wopcm_size)) {
>>>> +        DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
>>>> +                     "GuC WOPCM is already locked [%uK, %uK)\n",
>>>> +                     guc_wopcm_base / SZ_1K,
>>>> +                     guc_wopcm_size / SZ_1K);
>>>> +        goto check;
>>>> +    }
>>>> +
>>>>       if (guc_fw_size >= wopcm->size) {
>>>>           DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
>>>>                 guc_fw_size / 1024);
>>>> @@ -211,6 +235,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
>>>>       DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
>>>>                guc_wopcm_base / 1024, guc_wopcm_size / 1024);
>>>> +check:
>>>  The checks here don't really verify that the sizes we're locked with 
>>> are enough to fit the binaries. We need to at least print an error in 
>>> that case so we can debug why GuC/HuC fails to load later if the 
>>> sizes are not ok.
> 
> I've added DRM_DEV_DEBUG_DRIVER("GuC WOPCM is already locked [%uK, %uK)\n"
> but maybe we should promote it to dev_notice ? will that work for you ?

I'd prefer an error-level message if huc doesn't fit so it jumps out 
that this is wrong and not just an informational message. The same as 
what we do with guc size below.

Daniele

> 
>>
>> Here I meant to refer to HuC only, since guc size is verified below 
>> (I'm too used to refer to them as a pair :P )
>>
>> Daniele
>>
>>>  Daniele
>>>
>>>>       guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
>>>>       if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
>>>>           DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-08-14 21:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 11:38 [PATCH 1/2] drm/i915/wopcm: Try to use already locked WOPCM layout Michal Wajdeczko
2019-08-14 11:38 ` [PATCH 2/2] drm/i915/uc: Move FW size sanity check back to fetch Michal Wajdeczko
2019-08-14 20:06   ` Daniele Ceraolo Spurio
2019-08-14 13:21 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/wopcm: Try to use already locked WOPCM layout Patchwork
2019-08-14 19:51 ` [PATCH 1/2] " Daniele Ceraolo Spurio
2019-08-14 20:10   ` Daniele Ceraolo Spurio
2019-08-14 20:49     ` Michal Wajdeczko
2019-08-14 21:32       ` Daniele Ceraolo Spurio [this message]
2019-08-15  3:51 ` ✓ Fi.CI.IGT: success for series starting with [1/2] " 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=f4a80c06-0332-62dd-cb67-f24fb99a33d2@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michal.wajdeczko@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