- 25 Apr, 2022 3 commits
-
-
Ville Syrjälä authored
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220413152852.7336-1-ville.syrjala@linux.intel.comReviewed-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Imre Deak authored
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:
Imre Deak <imre.deak@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421162221.2261895-1-imre.deak@intel.com
-
Jani Nikula authored
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:
Jani 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
-
- 21 Apr, 2022 37 commits
-
-
Jouni Högander authored
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:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Jason Gunthorpe authored
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:
Jason Gunthorpe <jgg@nvidia.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-35-hch@lst.deReviewed-by:
Kirti Wankhede <kwankhede@nvidia.com> Reviewed-by:
-
Jason Gunthorpe authored
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:
-
Jason Gunthorpe authored
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:
-
Jason Gunthorpe authored
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:
-
Jason Gunthorpe authored
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:
-
Christoph Hellwig authored
The code in both files is deeply interconnected, so merge it and keep a bunch of structures and functions static. Signed-off-by:
-
Christoph Hellwig authored
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:
-
Christoph Hellwig authored
Merge these into their only callers. Signed-off-by:
-
Christoph Hellwig authored
Pass the structure we actually care about instead of deriving it from the mdev_device in the lower level code. Signed-off-by:
-
Christoph Hellwig authored
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:
-
Christoph Hellwig authored
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:
-
Christoph Hellwig authored
Just call the initializion and exit functions directly and remove this abstraction entirely. Signed-off-by:
-
Christoph Hellwig authored
Just call the function directly and remove a pointless wrapper. Signed-off-by:
-
Christoph Hellwig authored
Just call the functions directly. Also remove a pointless wrapper. Signed-off-by:
-
Christoph Hellwig authored
Just call the kvmgt functions directly. Signed-off-by:
-
Christoph Hellwig authored
Just open code it in the only caller. Signed-off-by:
-
Christoph Hellwig authored
Just call the code directly and move towards the callers. Signed-off-by:
-
Christoph Hellwig authored
Just open code the MSI injection in a single place instead of going through the method table. Signed-off-by:
-
Christoph Hellwig authored
Just call the function directly. Signed-off-by:
-
Christoph Hellwig authored
Just call the code to setup the opregions and EDID data directly. Signed-off-by:
-
Christoph Hellwig authored
Just open code the calls to the VFIO APIs. Signed-off-by:
-
Christoph Hellwig authored
Just call the VFIO functions directly instead of through the method table. Signed-off-by:
-
Christoph Hellwig authored
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:
-
Christoph Hellwig authored
Consolidate the per-VGPU structures into a single one. Signed-off-by:
-
Christoph Hellwig authored
Move towards having only a single structure for the per-VGPU state. Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
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:
-
Christoph Hellwig authored
Remove these pointless indirect alls by just calling the only instance of each method directly. Signed-off-by:
-
Christoph Hellwig authored
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:
-
Christoph Hellwig authored
Free the intel_vgpu_ops symbol name for something that fits better. Signed-off-by:
-
Christoph Hellwig authored
The only supported hypervisor is KVM, so don't bother with dead code enumerating hypervisors. Signed-off-by:
-
Christoph Hellwig authored
THIS_MODULE always is reference when a symbol called by it is used, so don't bother with the additional reference. Signed-off-by:
-
Jani Nikula authored
Drop extra ccflags, drop extra intermediate variables, list object files one per line alphabetically. Cc: Zhi Wang <zhi.wang.linux@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Jani Nikula authored
TRACE_INCLUDE_PATH should be a path relative to define_trace.h, not the file including it. (See the comment in include/trace/define_trace.h.) Cc: Zhi Wang <zhi.wang.linux@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Zhi Wang authored
The code of saving initial HW state snapshot has been moved into i915. Let the GVT-g core logic use that snapshot. Cc: Christoph Hellwig <hch@lst.de> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Vivi Rodrigo <rodrigo.vivi@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by:
-
Zhi Wang authored
Save the initial HW state snapshot in i915 so that the rest code of GVT-g can be moved into a dedicated module while it can still get a clean initial HW state saved at the correct time during the initialization of i915. The futhrer vGPU created by GVT-g will use this HW state as the initial HW state. v6: - Remove the reference of intel_gvt_device_info.(Christoph) - Refine the save_mmio() function. (Christoph) Cc: Christoph Hellwig <hch@lst.de> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Vivi Rodrigo <rodrigo.vivi@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
-
