Pass the full atomic state+crtc rather than the redundant
crtc+crtc_state pair. We already need the full atomic state
in the hsw+ codepath anyway.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

All platforms have dpll_funcs. Remove the pointless NULL checks.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Stop passing around the drm_device and just pass the
dev_priv instead.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Get rid of the confusing back and forth between bools and ints
in the .get_dplls() stuff. Just make everything return an int.

Initial conversion done with cocci, with some manual fixups on top:
@find@
identifier func !~ "get_hw_state|_is_|needed";
typedef bool;
parameter list[N] P;
@@
- bool
+ int
 func(P)
{
<...
(
- return true;
+ return 0;
|
- return false;
+ return -EINVAL;
)
...>
}

@@
identifier find.func;
expression list[find.N] E;
expression X;
@@
- if (!func(E))
+ ret = func(E);
+ if (ret)
  {
  ...
- return X;
+ return ret;
  }

@@
identifier find.func;
expression X;
expression list[find.N] E;
@@
- if (!func(E))
+ ret = func(E);
+ if (ret)
- return X;
+ return ret;

@@
identifier find.func;
expression list[find.N] E;
expression O, X;
typedef bool;
bool B;
@@
- B = func(E);
- if (O && !B)
+ if (O) {
+ ret = func(E);
+ if (ret)
- return X;
+ return ret;
+ }

@@
identifier find.func;
expression list[find.N] E;
expression O, X;
@@
- if (O && !func(E))
+ if (O) {
+ ret = func(E);
+ if (ret)
- return X;
+ return ret;
+ }

@@
identifier find.func;
expression list[find.N] E;
expression X;
typedef bool;
bool B;
@@
- B = func(E);
- if (!B)
+ ret = func(E);
+ if (ret)
  {
  ...
- return X;
+ return ret;
  }
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325123205.22140-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

intel_fbc_check_plane() is supposed to an int, not a boolean.
So replace the bogus 'return false's with the correct 'return 0's.
These were accidental copy-paste mistakes when the code got moved
into intel_fbc_check_plane() from somewhere else tht did return
a boolean.

No functional issue here since false==0.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413152852.7336-2-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

plane_state->uapi.crtc is not what we want to be looking at.
If bigjoiner is used hw.crtc is what tells us what crtc the plane
is supposedly using.

Not an actual problem on current hardware as the only FBC capable
pipe (A) can't be a bigjoiner slave and thus uapi.crtc==hw.crtc
always here. But when we get more FBC instances this will become
actually important.

Fixes: 2e6c99f8 ("drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cache")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413152852.7336-1-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

Fix typo in the _SEL_FETCH_PLANE_BASE_1_B register base address.

Fixes: a5523e2f ("drm/i915: Add PSR2 selective fetch registers")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/5400
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: <stable@vger.kernel.org> # v5.9+
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421162221.2261895-1-imre.deak@intel.com

Merge tag 'gvt-next-2022-04-21-for-christoph' of https://github.com/intel/gvt-linux into drm-intel-next

gvt-next-2022-04-21-for-christoph

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)

[Jani: added #include to adapt to header refactoring in drm-intel-next]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
From: "Wang, Zhi A" <zhi.a.wang@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/25a713cd-0b7d-4c09-7d91-4f4ef6c9eb11@intel.com

We have now seen panel (XMG Core 15 e21 laptop) advertizing support
for Intel proprietary eDP backlight control via DPCD registers, but
actually working only with legacy pwm control.

This patch adds panel EDID check for possible HDR static metadata and
Intel proprietary eDP backlight control is used only if that exists.
Missing HDR static metadata is ignored if user specifically asks for
Intel proprietary eDP backlight control via enable_dpcd_backlight
parameter.

v2 :
- Ignore missing HDR static metadata if Intel proprietary eDP
  backlight control is forced via i915.enable_dpcd_backlight
- Printout info message if panel is missing HDR static metadata and
  support for Intel proprietary eDP backlight control is detected

Fixes: 4a8d7990 ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284
Cc: Lyude Paul <lyude@redhat.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Filippo Falezza <filippo.falezza@outlook.it>
Cc: stable@vger.kernel.org
Signed-off-by: NJouni Högander <jouni.hogander@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413082826.120634-1-jouni.hogander@intel.comReviewed-by: NLyude Paul <lyude@redhat.com>

This is no longer used, remove it.

All usages were moved over to either use container_of() from a vfio_device
or to use dev_drvdata() directly on the mdev.
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-35-hch@lst.deReviewed-by: NKirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

The device creator is supposed to use the dev.groups value to add sysfs
files before device_add is called, not call sysfs_create_files() after
device_add() returns. This creates a race with uevent delivery where the
extra attribute will not be visible.

This was being done because the groups had been co-opted by the mdev
driver, now that prior patches have moved the driver's groups to the
struct device_driver the dev.group is properly free for use here.
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-34-hch@lst.deReviewed-by: NKirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

The last useful member in this struct is the supported_type_groups, move
it to the mdev_driver and delete mdev_parent_ops.

Replace it with mdev_driver as an argument to mdev_register_device()
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-33-hch@lst.deReviewed-by: NKirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

This is only used by one sample to print a fixed string that is pointless.

In general, having a device driver attach sysfs attributes to the parent
is horrific. This should never happen, and always leads to some kind of
liftime bug as it become very difficult for the sysfs attribute to go back
to any data owned by the device driver.

Remove the general mechanism to create this abuse.
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-32-hch@lst.deReviewed-by: NKirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Now that all mdev drivers directly create their own mdev_device driver and
directly register with the vfio core's vfio_device_ops this is all dead
code.

Delete vfio_mdev.c and the mdev_parent_ops members that are connected to
it.
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-31-hch@lst.deReviewed-by: NKirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

The code in both files is deeply interconnected, so merge it and
keep a bunch of structures and functions static.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-30-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

This is straightforward conversion, the intel_vgpu already has a pointer
to the vfio_dev, which can be replaced with the embedded structure and
we can replace all the mdev_get_drvdata() with a simple container_of().

Based on an patch from Jason Gunthorpe.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-29-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Merge these into their only callers.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-28-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Pass the structure we actually care about instead of deriving it from
the mdev_device in the lower level code.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-27-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Initialize variables at declaration time, avoid pointless gotos and
cater for the fact that intel_gvt_create_vgpu can't return NULL.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-26-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

All the dmabufs are torn down when th VGPU is released, so there is
no need for extra refcounting here.

Based on an patch from Jason Gunthorpe.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-25-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just call the initializion and exit functions directly and remove
this abstraction entirely.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-24-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just call the function directly and remove a pointless wrapper.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-23-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just call the functions directly.  Also remove a pointless wrapper.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-22-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just call the kvmgt functions directly.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-21-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just open code it in the only caller.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-20-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just call the code directly and move towards the callers.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-19-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just open code the MSI injection in a single place instead of going
through the method table.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-18-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just call the function directly.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-17-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just call the code to setup the opregions and EDID data directly.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-16-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just open code the calls to the VFIO APIs.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-15-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Just call the VFIO functions directly instead of through the method
table.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-14-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Always pass the actual vgpu structure instead of encoding it as a
"handle" and add a bool flag to denote if a VGPU is attached.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-13-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Consolidate the per-VGPU structures into a single one.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-12-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Move towards having only a single structure for the per-VGPU state.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-11-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-10-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

The map_gfn_to_mfn and set_trap_area ops are never defined, so remove
them and clean up code that depends on them in the callers.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-9-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Remove these pointless indirect alls by just calling the only instance
of each method directly.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-8-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Instead of having an option to build the gvt code into the main i915
module, just move it into the kvmgt.ko module.  This only requires
a new struct with three entries that the KVMGT modules needs to register
with the main i915 module, and a proper list of GVT-enabled devices
instead of global device pointer.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-7-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

Free the intel_vgpu_ops symbol name for something that fits better.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-4-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>

The only supported hypervisor is KVM, so don't bother with dead code
enumerating hypervisors.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-3-hch@lst.deReviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>