- Jun 24, 2024
-
-
Vivek Kasireddy authored
When an imported dmabuf obj is used as part of an atomic commit, we need to pin it as part of prepare and unpin it during cleanup of the associated FB, to make sure that it does not move until the commit is completed (and also while it is being used on the Host). Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:Vivek Kasireddy <vivek.kasireddy@intel.com>
-
- Jun 18, 2024
-
-
Vivek Kasireddy authored
By importing scanout buffers from other devices, we should be able to use the virtio-gpu driver in KMS only mode. Note that we attach dynamically and register a move_notify() callback so that we can let the VMM know of any location changes associated with the backing store of the imported object by sending detach_backing cmd. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: -
Vivek Kasireddy authored
The imported object can be considered a guest blob resource; therefore, we use create_blob cmd while creating it. These helpers are used in the next patch which does the actual import. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: -
Vivek Kasireddy authored
This helper would be used when first initializing the object as part of import and also when updating the plane where we need to ensure that the imported object's backing is valid. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: -
Vivek Kasireddy authored
This cmd is useful to let the VMM (i.e, Qemu) know that the backing store associated with a resource is no longer valid, so that the VMM can perform any cleanup or unmap operations. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
- Jun 17, 2024
-
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
# Conflicts: # drivers/gpu/drm/i915/display/intel_vbt_defs.h # drivers/gpu/drm/xe/xe_devcoredump.c # drivers/gpu/drm/xe/xe_device.h # drivers/gpu/drm/xe/xe_pci.c
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
# Conflicts: # drivers/gpu/drm/xe/xe_gt_idle.c # drivers/gpu/drm/xe/xe_guc_pc.c
-
Francois Dugast authored
The properties of this struct are used in long running context so make that clear by renaming it to lr, in alignment with the rest of the code. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240613170348.723245-1-francois.dugast@intel.com Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Mitul Golani authored
Update calculation to avoid overflow. -v2: Remove extra line between cc and signed-off. Fixes: 1676ecd3 ("drm/i915: Compute CMRR and calculate vtotal") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240614044213.377710-1-mitulkumar.ajitkumar.golani@intel.com Signed-off-by:
-
"struct nouveau_job_ops" is not modified in these drivers. Constifying this structure moves some data to a read-only section, so increase overall security. In order to do it, "struct nouveau_job" and "struct nouveau_job_args" also need to be adjusted to this new const qualifier. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 5570 152 0 5722 165a drivers/gpu/drm/nouveau/nouveau_exec.o After: ===== text data bss dec hex filename 5630 112 0 5742 166e drivers/gpu/drm/nouveau/nouveau_exec.o Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/860e9753d7867aa46b003bb3d0497f1b04065b24.1718381285.git.christophe.jaillet@wanadoo.fr
-
I'm pretty sure this optimisation is actually not a great idea, and is racy with other things waiting for fences. Just nuke it, there should be no need to do fence waits in a busy CPU loop. Signed-off-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Ben Skeggs <bskeggs@nvidia.com> Signed-off-by:
-
Add job that runs igt on top of vkms. Acked-by:
Maíra Canal <mcanal@igalia.com> Acked-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
Vignesh Raman <vignesh.raman@collabora.com> Acked-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Tested-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Vinod Govindapillai authored
Move the handling of the disabling FBC when VT-d is active wa as part of the intel_fbc_check_plane(). As the hw is still there, intel_fbc_sanitize should be able to handle the state properly. v2: update the patch description (Jani Nikula) v3: fix the return value in wa handling (Jani Nikula) Bspec: 21664 Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240528114826.134958-1-vinod.govindapillai@intel.com
-
Jani Nikula authored
It's not possible to use the joiner at the same time with eDP MSO. When a panel needs MSO, it's not optional, so MSO trumps joiner. v3: Only change intel_dp_has_joiner(), leave debugfs alone (Ville) Fixes: bc71194e ("drm/i915/edp: enable eDP MSO during link training") Cc: <stable@vger.kernel.org> # v5.13+ Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Closes: drm/xe/kernel#1668 Reviewed-by:
Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 8b5a92ca) Signed-off-by:
-
Jani Nikula authored
Move the comment about FSB straps to where the relevant register is read. Suggested-by:
-
Jani Nikula authored
Instead of duplicating the CLKCFG parsing, reuse i9xx_fsb_freq() to figure out rawclk_freq where applicable. Reviewed-by:
-
Jani Nikula authored
Reuse i9xx_fsb_freq() for GT clock frequency initialization instead of depending on rawclk_freq. Note: If the init order was changed, we could use i915->fsb_freq directly. However, GT clock initialization is done in i915_driver_mmio_probe(), but intel_dram_detect() later in i915_driver_hw_probe(), with a dependency on intel_pcode_init(). Reviewed-by:
-
Jani Nikula authored
Initialize fsb frequency for more platforms to be able to use it for GT clock and rawclk frequency initialization. Note: There's a discrepancy between existing pnv_fsb_freq() and i9xx_hrawclk() regarding CLKCFG interpretation. Presume all PNV is mobile. Default to 1333 MHz for unknown values, similar to i9xx_hrawclk(). v2: - Add MISSING_CASE() (Ville) - Default to the same frequency for both branches (Ville) Reviewed-by:
-
Jani Nikula authored
We'll want to use fsb frequency for deriving GT clock and rawclk frequencies in the future. Increase the accuracy by converting to kHz. Do the same for mem freq to be aligned. Round the frequencies ending in 666 to 667. v2: Also handle mem_freq in gen5_rps_init() (Ville) Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Jani Nikula authored
It's a bit out of place, and only printed for VLV/CHV. Reviewed-by:
-
Jani Nikula authored
Follow the same style in mem freq init as in fsb freq init, returning the value instead of assigning in multiple places. Reviewed-by:
-
Jani Nikula authored
Split out the PNV DDR3 detection to a distinct step instead of conflating it with mem freq detection. Reviewed-by:
-
Jani Nikula authored
To simplify further changes, add separate functions for reading the fsb frequency. This ends up reading CLKCFG register twice, but it's not a big deal. Reviewed-by:
-
Jani Nikula authored
Clarify and unify the logging on not finding PNV CxSR latency config. Just let the i915->fsb_freq == 0 || i915->mem_freq == 0 case go through the table instead of checking for it separately. v2: Do not check for fsb == 0 || mem == 0 separately (Matt) Reviewed-by:
-
Jani Nikula authored
Clarify that the function is specific to PNV, making subsequent changes slightly easier to grasp. Reviewed-by:
-
Jani Nikula authored
It's not possible to use the joiner at the same time with eDP MSO. When a panel needs MSO, it's not optional, so MSO trumps joiner. v3: Only change intel_dp_has_joiner(), leave debugfs alone (Ville) Fixes: bc71194e ("drm/i915/edp: enable eDP MSO during link training") Cc: <stable@vger.kernel.org> # v5.13+ Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Closes: drm/xe/kernel#1668 Reviewed-by:
-
We always call scheduled_delayed_work with no delay, so just use a non-delayed work_struct instead. Signed-off-by:
Sean Anderson <sean.anderson@linux.dev> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
Sort the members of struct zynqmp_dp to reduce padding necessary for alignment. Signed-off-by:
-
drm_encoder_cleanup is responsible for calling drm_bridge_detach for each bridge attached to the encoder. zynqmp_dp_bridge_detach is in turn responsible for unregistering the AUX bus. However, we never ended up calling drm_encoder_cleanup in the remove or error paths, so the AUX bus would stick around after the rest of the driver had been removed. I don't really understand why drm_mode_config_cleanup doesn't call drm_encoder_cleanup for us. It will call destroy (which for simple_encoder is drm_encoder_cleanup) on encoders in the mode_config's encoder_list. Should drm_encoder_cleanup get called before or after drm_atomic_helper_shutdown? Fixes: 2dfd045c ("drm: xlnx: zynqmp_dpsub: Register AUX bus at bridge attach time") Signed-off-by:
-
Unconditionally enable the DPSUB layer in the corresponding atomic plane update callback. Setting the new display mode may require disabling and re-enabling the CRTC. This effectively resets DPSUB to the default state with all layers disabled. The original implementation of the plane atomic update enables the corresponding DPSUB layer only if the framebuffer format has changed. This would leave the layer disabled after switching to a different display mode with the same framebuffer format. Signed-off-by:
Anatoliy Klymenko <anatoliy.klymenko@amd.com> Signed-off-by:
-
If zynqmp_dpsub_drm_init() fails, we must undo the previous drm_bridge_add() call. Fixes: be3f3042 ("drm: zynqmp_dpsub: Always register bridge") Signed-off-by:
Sean Anderson <sean.anderso@linux.dev> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- Jun 16, 2024
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge tag 'parisc-for-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fix from Helge Deller: "On parisc we have suffered since years from random segfaults which seem to have been triggered due to cache inconsistencies. Those segfaults happened more often on machines with PA8800 and PA8900 CPUs, which have much bigger caches than the earlier machines. Dave Anglin has worked over the last few weeks to fix this bug. His patch has been successfully tested by various people on various machines and with various kernels (6.6, 6.8 and 6.9), and the debian buildd servers haven't shown a single random segfault with this patch. Since the cache handling has been reworked, the patch is slightly bigger than I would like in this stage, but the greatly improved stability IMHO justifies the inclusion now" * tag 'parisc-for-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Try to fix random segmentation faults in package builds
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "Two fixes to correctly report i2c functionality, ensuring that I2C_FUNC_SLAVE is reported when a device operates solely as a slave interface" * tag 'i2c-for-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: designware: Fix the functionality flags of the slave-only interface i2c: at91: Fix the functionality flags of the slave-only interface
-
