Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
To: Juston Li <justonli@chromium.org>,
	Andrzej Hajda <andrzej.hajda@intel.com>
Cc: intel-gfx@lists.freedesktop.org, alan.previn.teres.alexis@intel.com
Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/pxp: don't start pxp without mei_pxp bind
Date: Thu, 25 Aug 2022 16:05:27 -0700	[thread overview]
Message-ID: <db46be26-0a23-2fda-6492-8cbc76c18adc@intel.com> (raw)
In-Reply-To: <CAKhQNHHoC3e6NjpjRovHnTCe88fiRXU_U08Rw1k+-3pcB3sDYg@mail.gmail.com>



On 8/23/2022 2:15 PM, Juston Li wrote:
> On Fri, Aug 19, 2022 at 4:53 AM Andrzej Hajda <andrzej.hajda@intel.com> wrote:
>> On 18.08.2022 19:42, Juston Li wrote:
>>> pxp will not start correctly until after mei_pxp bind completes and
>>> intel_pxp_init_hw() is called.
>>> Wait for the bind to complete before proceeding with startup.
>>>
>>> This fixes a race condition during bootup where we observed a small
>>> window for pxp commands to be sent, starting pxp before mei_pxp bind
>>> completed.
>>>
>>> Changes since v2:
>>> - wait for pxp_component to bind instead of returning -EAGAIN (Daniele)
>>>
>>> Changes since v1:
>>> - check pxp_component instead of pxp_component_added (Daniele)
>>> - pxp_component needs tee_mutex (Daniele)
>>> - return -EAGAIN so caller knows to retry (Daniele)
>>>
>>> Signed-off-by: Juston Li <justonli@chromium.org>
>> In typical usage of component framework driver postpones initialization
>> till component is bound. In such case checking/waiting for component as
>> in this patch is not necessary and the code is more straightforward.
>> I wonder how it behaves on component unbind.

This component is only used for a specific use-case (content 
protection), so we don't want to hold back the whole graphics driver 
initialization for that. Unbind can only happen on suspend or driver 
removal and in both cases we're not accepting userspace submission at 
that point.

>> Anyway:
>> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
> Thanks Andrzej!
>
> Any other comments Daniele?
> Otherwise, need some help from someone to merge this :)

No other comments from me. I've pushed the patch to gt-next.

Thanks,
Daniele

>
> Thanks
> Juston
>
>> Regards
>> Andrzej
>>
>>
>>> ---
>>>    drivers/gpu/drm/i915/pxp/intel_pxp.c | 15 +++++++++++++++
>>>    1 file changed, 15 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c b/drivers/gpu/drm/i915/pxp/intel_pxp.c
>>> index 15311eaed848..17109c513259 100644
>>> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
>>> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
>>> @@ -176,6 +176,18 @@ static void pxp_queue_termination(struct intel_pxp *pxp)
>>>        spin_unlock_irq(&gt->irq_lock);
>>>    }
>>>
>>> +static bool pxp_component_bound(struct intel_pxp *pxp)
>>> +{
>>> +     bool bound = false;
>>> +
>>> +     mutex_lock(&pxp->tee_mutex);
>>> +     if (pxp->pxp_component)
>>> +             bound = true;
>>> +     mutex_unlock(&pxp->tee_mutex);
>>> +
>>> +     return bound;
>>> +}
>>> +
>>>    /*
>>>     * the arb session is restarted from the irq work when we receive the
>>>     * termination completion interrupt
>>> @@ -187,6 +199,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
>>>        if (!intel_pxp_is_enabled(pxp))
>>>                return -ENODEV;
>>>
>>> +     if (wait_for(pxp_component_bound(pxp), 250))
>>> +             return -ENXIO;
>>> +
>>>        mutex_lock(&pxp->arb_mutex);
>>>
>>>        if (pxp->arb_is_valid)


      reply	other threads:[~2022-08-25 23:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18 17:42 [Intel-gfx] [PATCH v3] drm/i915/pxp: don't start pxp without mei_pxp bind Juston Li
2022-08-18 18:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: don't start pxp without mei_pxp bind (rev3) Patchwork
2022-08-19 11:12 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-08-19 11:53 ` [Intel-gfx] [PATCH v3] drm/i915/pxp: don't start pxp without mei_pxp bind Andrzej Hajda
2022-08-23 21:15   ` Juston Li
2022-08-25 23:05     ` Ceraolo Spurio, Daniele [this message]

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=db46be26-0a23-2fda-6492-8cbc76c18adc@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=alan.previn.teres.alexis@intel.com \
    --cc=andrzej.hajda@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=justonli@chromium.org \
    /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