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: 29+ 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 ` 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 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.