From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
Cc: "sean.z.huang@intel.com" <sean.z.huang@intel.com>,
"Huang@freedesktop.org" <Huang@freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>,
"chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Subject: Re: [Intel-gfx] [PATCH v10 09/17] drm/i915/pxp: Implement PXP irq handler
Date: Mon, 20 Sep 2021 13:28:06 -0400 [thread overview]
Message-ID: <YUjEpiFPnHvq+rDW@intel.com> (raw)
In-Reply-To: <f998c74c65c3a30ae2e6e0b9f68d551b0d92b063.camel@intel.com>
On Mon, Sep 20, 2021 at 04:18:10PM +0000, Teres Alexis, Alan Previn wrote:
>
> On Mon, 2021-09-20 at 12:04 -0400, Rodrigo Vivi wrote:
> > On Fri, Sep 17, 2021 at 09:20:00PM -0700, Alan Previn wrote:
> > > From: "Huang, Sean Z" <sean.z.huang@intel.com>
> > >
> > > The HW will generate a teardown interrupt when session termination is
> > > required, which requires i915 to submit a terminating batch. Once the HW
> > > is done with the termination it will generate another interrupt, at
> > > which point it is safe to re-create the session.
> > >
> > > Since the termination and re-creation flow is something we want to
> > > trigger from the driver as well, use a common work function that can be
> > > called both from the irq handler and from the driver set-up flows, which
> > > has the addded benefit of allowing us to skip any extra locks because
> > > the work itself serializes the operations.
> > >
> > > v2: use struct completion instead of bool (Chris)
> > > v3: drop locks, clean up functions and improve comments (Chris),
> > > move to common work function.
> > > v4: improve comments, simplify wait logic (Rodrigo)
> > > v5: unconditionally set interrupts, rename state_attacked var (Rodrigo)
> > >
> > > Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
> > > Signed-off-by: Huang, Sean Z <sean.z.huang@intel.com>
> > > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > ---
> > > +#include <linux/workqueue.h>
> > > +#include "intel_pxp.h"
> > > +#include "intel_pxp_irq.h"
> > > +#include "intel_pxp_session.h"
> > > +#include "gt/intel_gt_irq.h"
> > > +#include "gt/intel_gt_types.h"
> > > +#include "i915_irq.h"
> > > +#include "i915_reg.h"
> > > +
> > > +/**
> > > + * intel_pxp_irq_handler - Handles PXP interrupts.
> > > + * @pxp: pointer to pxp struct
> > > + * @iir: interrupt vector
> > > + */
> > > +void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
> > > +{
> > > + struct intel_gt *gt = pxp_to_gt(pxp);
> >
> > this compiles, but I don't see how this can work.
> >
> > shouldn't we use the container_of here directly instead of trying
> > to use something that is not properly defined?
> >
> Its now a function that's abstracted in .c file and prototype defined in the intel_pxp.h. Unless i
> misunderstood something, i thought this was one of the options discussed in last rev - i can change it
> again to use the container_of directly in all the instances if you like. side note: inline was still
> defined but only for the CONFIG_PXP==off case that doesn't require the additional header inclusions.
Oh, indeed.... Sorry
If this was not working we would get an "Undefined referrence" in the face.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
for this v as well.
>
> > > +
next prev parent reply other threads:[~2021-09-20 17:28 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-18 4:19 [Intel-gfx] [PATCH v10 00/17] drm/i915: Introduce Intel PXP Alan Previn
2021-09-18 4:19 ` [Intel-gfx] [PATCH v10 01/17] drm/i915/pxp: Define PXP component interface Alan Previn
2021-09-18 4:19 ` [Intel-gfx] [PATCH v10 02/17] mei: pxp: export pavp client to me client bus Alan Previn
2021-09-18 4:19 ` [Intel-gfx] [PATCH v10 03/17] drm/i915/pxp: define PXP device flag and kconfig Alan Previn
2021-09-18 4:19 ` [Intel-gfx] [PATCH v10 04/17] drm/i915/pxp: allocate a vcs context for pxp usage Alan Previn
2021-09-18 4:19 ` [Intel-gfx] [PATCH v10 05/17] drm/i915/pxp: Implement funcs to create the TEE channel Alan Previn
2021-09-18 4:19 ` [Intel-gfx] [PATCH v10 06/17] drm/i915/pxp: set KCR reg init Alan Previn
2021-09-18 4:19 ` [Intel-gfx] [PATCH v10 07/17] drm/i915/pxp: Create the arbitrary session after boot Alan Previn
2021-09-18 4:19 ` [Intel-gfx] [PATCH v10 08/17] drm/i915/pxp: Implement arb session teardown Alan Previn
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 09/17] drm/i915/pxp: Implement PXP irq handler Alan Previn
2021-09-20 16:04 ` Rodrigo Vivi
2021-09-20 16:18 ` Teres Alexis, Alan Previn
2021-09-20 17:28 ` Rodrigo Vivi [this message]
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 10/17] drm/i915/pxp: interfaces for using protected objects Alan Previn
2021-09-20 16:09 ` Rodrigo Vivi
2021-09-20 16:13 ` Teres Alexis, Alan Previn
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 11/17] drm/i915/pxp: start the arb session on demand Alan Previn
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 12/17] drm/i915/pxp: Enable PXP power management Alan Previn
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 13/17] drm/i915/pxp: Add plane decryption support Alan Previn
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 14/17] drm/i915/pxp: black pixels on pxp disabled Alan Previn
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 15/17] drm/i915/pxp: add pxp debugfs Alan Previn
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 16/17] drm/i915/pxp: add PXP documentation Alan Previn
2021-09-18 4:20 ` [Intel-gfx] [PATCH v10 17/17] drm/i915/pxp: enable PXP for integrated Gen12 Alan Previn
2021-09-18 4:52 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Introduce Intel PXP (rev8) Patchwork
2021-09-18 4:54 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-09-18 4:57 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-09-18 5:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-09-18 6:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=YUjEpiFPnHvq+rDW@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=Huang@freedesktop.org \
--cc=alan.previn.teres.alexis@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniele.ceraolospurio@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=sean.z.huang@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