Thomas-Hellstr…
Commits on Dec 17, 2021
-
drm/i915: Use struct vma_resource instead of struct vma_snapshot
There is always a struct vma_resource guaranteed to be alive when we access a corresponding struct vma_snapshot. So ditch the latter and instead of allocating vma_snapshots, reference the already existning vma_resource. This requires a couple of extra members in struct vma_resource but that's a small price to pay for the simplification. v2: - Fix a missing include and declaration (kernel test robot <lkp@intel.com>) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
drm/i915: Use vma resources for async unbinding
Implement async (non-blocking) unbinding by not syncing the vma before calling unbind on the vma_resource. Add the resulting unbind fence to the object's dma_resv from where it is picked up by the ttm migration code. Ideally these unbind fences should be coalesced with the migration blit fence to avoid stalling the migration blit waiting for unbind, as they can certainly go on in parallel, but since we don't yet have a reasonable data structure to use to coalesce fences and attach the resulting fence to a timeline, we defer that for now. Note that with async unbinding, even while the unbind waits for the preceding bind to complete before unbinding, the vma itself might have been destroyed in the process, clearing the vma pages. Therefore we can only allow async unbinding if we have a refcounted sg-list and keep a refcount on that for the vma resource pages to stay intact until binding occurs. If this condition is not met, a request for an async unbind is diverted to a sync unbind. v2: - Use a separate kmem_cache for vma resources for now to isolate their memory allocation and aid debugging. - Move the check for vm closed to the actual unbinding thread. Regardless of whether the vm is closed, we need the unbind fence to properly wait for capture. - Clear vma_res::vm on unbind and update its documentation. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
drm/i915: Use the vma resource as argument for gtt binding / unbinding
When introducing asynchronous unbinding, the vma itself may no longer be alive when the actual binding or unbinding takes place. Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource instead of a struct i915_vma for the bind_vma() and unbind_vma() ops. Similarly change the insert_entries() op for struct i915_address_space. Replace a couple of i915_vma_snapshot members with their newly introduced i915_vma_resource counterparts, since they have the same lifetime. Also make sure to avoid changing the struct i915_vma_flags (in particular the bind flags) async. That should now only be done sync under the vm mutex. v2: - Update the vma_res::bound_flags when binding to the aliased ggtt Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
drm/i915: Initial introduction of vma resources
Introduce vma resources, sort of similar to TTM resources, needed for asynchronous bind management. Initially we will use them to hold completion of unbinding when we capture data from a vma, but they will be used extensively in upcoming patches for asynchronous vma unbinding. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
drm/i915: Require the vm mutex for i915_vma_bind()
Protect updates of struct i915_vma flags and async binding / unbinding with the vm::mutex. This means that i915_vma_bind() needs to assert vm::mutex held. In order to make that possible drop the caching of kmap_atomic() maps around i915_vma_bind(). An alternative would be to use kmap_local() but since we block cpu unplugging during sleeps inside kmap_local() sections this may have unwanted side-effects. Particularly since we might wait for gpu while holding the vm mutex. This change may theoretically increase execbuf cpu-usage on snb, but at least on non-highmem systems that increase should be very small. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
drm/i915: Break out the i915_deps utility
Since it's starting to be used outside the i915 TTM move code, move it to a separate set of files. v2: - Update the documentation. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
drm/i915: Avoid using the i915_fence_array when collecting dependencies
Since the gt migration code was using only a single fence for dependencies, these were collected in a dma_fence_array. However, it turns out that it's illegal to use some dma_fences in a dma_fence_array, in particular other dma_fence_arrays and dma_fence_chains, and this causes trouble for us moving forward. Have the gt migration code instead take a const struct i915_deps for dependencies. This means we can skip the dma_fence_array creation and instead pass the struct i915_deps instead to circumvent the problem. v2: - Make the prev_deps() function static. (kernel test robot <lkp@intel.com>) - Update the struct i915_deps kerneldoc. Fixes: 5652df8 ("drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be asynchronous") Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
-
Merge remote-tracking branch 'drm-intel/drm-intel-gt-next' into drm-tip
# Conflicts: # drivers/gpu/drm/i915/i915_pci.c
-
-
Merge tag 'mediatek-drm-next-5.17' of https://git.kernel.org/pub/scm/…
…linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 5.16 1. Add support for MT8192 2. CMDQ refinement. 3. Miscellaneous clean up and reorder. 4. Set the default value of rotation to DRM_MODE_ROTATE_0 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/1639700370-3541-1-git-send-email-chunkuang.hu@kernel.org
-
Merge tag 'drm-misc-next-2021-12-16' of git://anongit.freedesktop.org…
…/drm/drm-misc into drm-next drm-misc-next for 5.17: UAPI Changes: * vmwgfx: Version bump to 2.20 Cross-subsystem Changes: * of: Create simple-framebuffer devices in of_platform_default_init() Core Changes: * Replace include <linux/kernel.h> with more fine-grained includes * Document DRM_IOCTL_MODE_GETFB2 * format-helper: Support XRGB2101010 source buffers Driver Changes: * amdgpu: Fix runtime PM on some configs * ast: Fix I2C initialization * bridge: ti-sn65dsi86: Set regmap max_register * panel: Add Team Source Display TST043015CMHX plus DT bindings * simpledrm: Add support for Apple M1 * sprd: Add various drivers plus DT bindings * vc4: Support 10-bit YUV 4:2:0 output; Fix clock-rate updates * vmwgfx: Implement GEM support; Implement GL 4.3 support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/YbtOaZLvar+9hBOi@linux-uq9g.fritz.box
-
Merge tag 'drm-intel-next-2021-12-14' of ssh://git.freedesktop.org/gi…
…t/drm/drm-intel into drm-next drm/i915 feature pull #2 for v5.17: Features and functionality: - Add eDP privacy screen support (Hans) - Add Raptor Lake S (RPL-S) support (Anusha) - Add CD clock squashing support (Mika) - Properly support ADL-P without force probe (Clint) - Enable pipe color support (10 bit gamma) for display 13 platforms (Uma) - Update ADL-P DMC firmware to v2.14 (Madhumitha) Refactoring and cleanups: - More FBC refactoring preparing for multiple FBC instances (Ville) - Plane register cleanups (Ville) - Header refactoring and include cleanups (Jani) - Crtc helper and vblank wait function cleanups (Jani, Ville) - Move pipe/transcoder/abox masks under intel_device_info.display (Ville) Fixes: - Add a delay to let eDP source OUI write take effect (Lyude) - Use div32 version of MPLLB word clock for UHBR on SNPS PHY (Jani) - Fix DMC firmware loader overflow check (Harshit Mogalapalli) - Fully disable FBC on FIFO underruns (Ville) - Disable FBC with double wide pipe as mutually exclusive (Ville) - DG2 workarounds (Matt) - Non-x86 build fixes (Siva) - Fix HDR plane max width for NV12 (Vidya) - Disable IRQ for selftest timestamp calculation (Anshuman) - ADL-P VBT DDC pin mapping fix (Tejas) Merges: - Backmerge drm-next for privacy screen plumbing (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87ee6f5h9u.fsf@intel.com
-
Merge tag 'amd-drm-fixes-5.16-2021-12-15' of https://gitlab.freedeskt…
…op.org/agd5f/linux into drm-fixes amd-drm-fixes-5.16-2021-12-15: amdgpu: - Fix RLC register offset - GMC fix - Properly cache SMU FW version on Yellow Carp - Fix missing callback on DCN3.1 - Reset DMCUB before HW init - Fix for GMC powergating on PCO - Fix a possible memory leak in GPU metrics table handling on RN Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211216035239.5787-1-alexander.deucher@amd.com
-
Merge tag 'drm-misc-fixes-2021-12-16-1' of ssh://git.freedesktop.org/…
…git/drm/drm-misc into drm-fixes One null pointer dereference fix for ast, a pixel clock unit fix for simpledrm and a user-space regression revert for fb-helper Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211216082603.pm6yzlckmxvwnqyv@houat
Commits on Dec 16, 2021
-
drm/nouveau/disp/dp: add support for eDP link rates
eDP 1.4 adds a table of link rates supported by the sink to DPCD, as well as a LINK_RATE_SET register to select between the entries in it. If present, we will use this data to generate our internal link rate table rather than using the standard list based on MAX_LINK_RATE. Some recent laptops report MAX_LINK_RATE=0, and require this support. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/17
-
drm/nouveau/disp/dp: add support for hbr3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/17
-
drm/nouveau/disp/dp: add support for lttprs
Add support for Link-Training Tunable PHY Repeaters, required to support higher bit rates on longer cables, as well as USB-C on certain docks and laptops. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/17
-
drm/nouveau/disp/dp: fixup cr/eq delays for 1.4
Also use usleep_range() instead of [um]delay() to be a bit nicer. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/17
-
drm/nouveau/disp/dp: add support for tps4
Required for HBR3 and LTTPR. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/17
-
drm/nouveau/disp/dp: generate supported link rates table at detect time
Replaces the static list used during link training with a table built dynamically from the union of source and sink capabilities. Preparation for adding support for HBR3, LTTPR and eDP 1.4 link rates. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/17
-
drm/nouveau/disp/dp: explicitly control scrambling when setting pattern
TPS1/2/3 require scrambling to be disabled. The IED scripts on earlier boards used to handle this, but appear not to anymore. TPS4 support will also require scrambling to remain enabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/17
-
drm/nouveau/disp: remove some remnant of a rework
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/17
-
drm/i915/dg1: Read OPROM via SPI controller
Read OPROM SPI through MMIO and find VBT entry since we can't use OpRegion and PCI mapping may not work on some systems due to most BIOSes not leaving the Option ROM mapped. v2: Remove message with allocation failure Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211216062645.3477854-1-lucas.demarchi@intel.com
-
drm/vmwgfx: Fix possible usage of an uninitialized variable
vmw_user_bo_lookup can fail to lookup user buffers, especially because the buffer handles come from the userspace. The return value has to be checked before the buffers are put back. This was spotted by Dan's Smatch statick checker: drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:574 vmw_user_bo_synccpu_release() error: uninitialized symbol 'vmw_bo'. Signed-off-by: Zack Rusin <zackr@vmware.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 8afa13a ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215200224.3693345-1-zack@kde.org -
drm/vmwgfx: Remove unused compile options
Before the driver had screen targets support we had to disable explicit bringup of its infrastructure because it was breaking screen objects support. Since the implementation of screen targets landed there hasn't been a reason to explicitly disable it and the options were never used. Remove of all that unused code. Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: d80efd5 ("drm/vmwgfx: Initial DX support") Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-3-zack@kde.org
-
drm/vmwgfx: Remove explicit transparent hugepages support
Old versions of the svga device used to export virtual vram, handling of which was optimized on top of transparent hugepages support. Only very old devices (OpenGL 2.1 support and earlier) used this code and at this point performance differences are negligible. Because the code requires very old hardware versions to run it has been largely untested and unused for a long time. Furthermore removal of the ttm hugepages support in: commit 0d97950 ("drm/ttm: remove ttm_bo_vm_insert_huge()") broke the coherency mode in vmwgfx when running with hugepages. Fixes: 0d97950 ("drm/ttm: remove ttm_bo_vm_insert_huge()") Signed-off-by: Zack Rusin <zackr@vmware.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org
-
drm/vmwgfx: Fix a size_t/long int format specifier mismatch
On i386 size_t is of course 32bits and using long int throws warnings, trivially fix it by using the dedicated size_t format. This is enough to fix the following warning found by the kernel test robot: drivers/gpu/drm/vmwgfx/vmwgfx_gem.c: In function 'vmw_bo_print_info': >> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c:230:33: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Wformat=] 230 | seq_printf(m, "\t\t0x%08x: %12ld bytes %s, type = %s", | ~~~~^ | | | long int | %12d 231 | id, bo->base.base.size, placement, type); | ~~~~~~~~~~~~~~~~~~ | | Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: 8afa13a ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-1-zack@kde.org -
drm/ingenic: Add support for JZ4780 and HDMI output
Add support for the LCD controller present on JZ4780 SoCs. This SoC uses 8-byte descriptors which extend the current 4-byte descriptors used for other Ingenic SoCs. Tested on MIPS Creator CI20 board. Signed-off-by: Paul Boddie <paul@boddie.org.uk> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/caf9e56b64b0717563e03172b30fa03736e92e15.1638470392.git.hns@goldelico.com
-
drm/ingenic: prepare ingenic drm for later addition of JZ4780
This changes the way the regmap is allocated to prepare for the later addition of the JZ4780 which has more registers and bits than the others. Therefore we make the regmap as big as the reg property in the device tree tells. Suggested-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/ee65e70e91268b3963f8a6581c8aa6c3b643c53e.1638470392.git.hns@goldelico.com
-
drm/i915: Remove unused intel_gmbus_set_speed() function
The intel_gmbus_set_speed() function is not used anywhere, remove it. Note drivers/gpu/drm/gma500 has its own copy called gma_intel_gmbus_set_speed() which is used, the intel_gmbus_set_speed() version in the i915 code is not used at all Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211121191001.252076-1-hdegoede@redhat.com
-
drm/i915/backlight: Make ext_pwm_disable_backlight() call intel_backl…
…ight_set_pwm_level() At least the Bay Trail LPSS PWM controller used with DSI panels on many Bay Trail tablets seems to leave the PWM pin in whatever state it was (high or low) ATM that the PWM gets disabled. Combined with some panels not having a separate backlight-enable pin this leads to the backlight sometimes staying on while it should not (when the pin was high during PWM-disabling). First calling intel_backlight_set_pwm_level() will ensure that the pin is always low (or high for inverted brightness panels) since the passed in duty-cycle is 0% (or 100%) when the PWM gets disabled fixing the backlight sometimes staying on. With the exception of ext_pwm_disable_backlight() all other foo_disable_backlight() functions call intel_backlight_set_pwm_level() already before disabling the backlight, so this change also aligns ext_pwm_disable_backlight() with all the other disable() functions. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211121110032.4720-2-hdegoede@redhat.com