- 06 Mar, 2023 1 commit
-
-
Carlo Caione authored
Relax a bit the supported modes list by including also 480x1920 and 400x1280. This was actually tested on real hardware and it works correctly. Signed-off-by:
Carlo Caione <ccaione@baylibre.com> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
- 05 Mar, 2023 2 commits
-
-
Simon Ser authored
This is already documented under "standard connector properties". Signed-off-by:
Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <ppaalanen@gmail.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230227122522.117580-1-contact@emersion.fr
-
Simon Ser authored
Add docs for "{left,right,top,bottom} margin" properties. v2: - Mention the purpose: mitigate underscan on TVs - Move out of analog TV section into standard props (Pekka) - Mention HDMI AVI InfoFrames (Pekka, Ville) Signed-off-by:Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230228123156.175973-1-contact@emersion.fr
-
- 03 Mar, 2023 3 commits
-
-
Rob Clark authored
Add a build option to disable modesetting support. This is useful in cases where the guest only needs to use the GPU in a headless mode, or (such as in the CrOS usage) window surfaces are proxied to a host compositor. As the modesetting ioctls are a big surface area for potential security bugs to be found (it's happened in the past, we should assume it will again in the future), it makes sense to have a build option to disable those ioctls in cases where they serve no legitimate purpose. v2: Use more if (IS_ENABLED(...)) v3: Also permit the host to advertise no scanouts v4: Spiff out commit msg v5: Make num_scanouts==0 and DRM_VIRTIO_GPU_KMS=n behave the same v6: Drop conditionally building virtgpu_display.c and early-out of it's init/fini fxns instead Signed-off-by:Rob Clark <robdclark@chromium.org> Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Maíra Canal authored
The missing parentheses prevents the function to be rendered as a link in the documentation. So, add the missing parentheses to the function on the documentation. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230223121909.149980-1-mcanal@igalia.com
-
suijingfeng authored
should replace '@' with '*' Signed-off-by:
suijingfeng <suijingfeng@loongson.cn> Reviewed-by:
-
- 02 Mar, 2023 2 commits
-
-
Douglas Anderson authored
Set the "pre_enable_prev_first" as provided by commit 4fb912e5 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order"). This should allow us to revert commit ec7981e6 ("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") and commit 7d8e9a90 ("drm/msm/dsi: move DSI host powerup to modeset time"). Cc: Dave Stevenson <dave.stevenson@raspberrypi.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230131141756.RFT.v2.1.I723a3761d57ea60c5dd754c144aed6c3b2ea6f5a@changeid
-
Neil Armstrong authored
Add myself as co-maintainer for DRM Panel Drivers in order to help reviewing and getting new panels drivers merged, and Remove Thierry as he suggested since he wasn't active for a while. Thanks Thierry for all your work! Acked-by:
Jagan Teki <jagan@amarulasolutions.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
- 01 Mar, 2023 8 commits
-
-
Maarten Lankhorst authored
Use the generic suballocation helper for radeon. v3: - Select the suballoc helper in Kconfig (Thomas). Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Co-developed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230224095152.30134-4-thomas.hellstrom@linux.intel.com
-
Maarten Lankhorst authored
Now that we have a generic suballocation helper, Use it in amdgpu. For lines that get moved or changed, also fix up pre-existing style issues. Signed-off-by:
-
Maarten Lankhorst authored
Suballocating a buffer object is something that is not driver-specific and useful for many drivers. Use a slightly modified version of amdgpu_sa.c v2: - Style cleanups. - Added / Modified documentation. - Use u64 for the sizes and offset. The code dates back to 2012 and using unsigned int will probably soon come back to bite us. We can consider size_t as well for better 32-bit efficiency. - Add and document gfp, intr and align arguments to drm_suballoc_new(). - Use drm_printer for debug output. v3: - Remove stale author info (Christian König) v4: - Avoid 64-bit integer divisions (kernel test robot <lkp@intel.com>) - Use size_t rather than u64 for the managed range. (Thomas) Signed-off-by:
-
Ville Syrjälä authored
Remove the bogus csync check and replace it with something that: - triggers for all forms of csync, not just the basic analog variant - actually populates the mode csync flags so that drivers can decide what to do with the mode Originally the code tried to outright reject csync, but that apparently broke some bogus LCD monitor that claimed to have a detailed mode that uses analog csync, despite also claiming the monitor only support separate sync: https://bugzilla.redhat.com/show_bug.cgi?id=540024 Potentially that monitor should just be quirked or something. Anyways, what we are dealing with now is some kind of funny i915 JSL machine with eDP where the panel claims to support a sensible 60Hz separate sync mode, and a 50Hz mode with bipolar analog csync. The 50Hz mode does not work so we want to not use it. Easiest way is to just correctly flag it as csync and the driver will reject it. TODO: or should we just reject any form of csync (or at least the analog variants) for digital display interfaces? v2: Grab digital csync polarity from hsync polarity bit (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8146Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230228213610.26283-1-ville.syrjala@linux.intel.com
-
Thomas Zimmermann authored
The helper to_ast_private() now upcasts to struct ast_device. Rename it accordingly. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
The data structure struct ast_private represents an AST device. Its name comes from the time when it was allocated and stored separately in struct drm_device.dev_private. The DRM device is now embedded, so rename struct ast_private to struct ast_device. Signed-off-by:
-
Thomas Zimmermann authored
Ast defines a number of I/O helpers for accessing hardware. Only 4 of the many generated functions are actually used. Replace the respective generator macros with those 4 functions. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Replace one call to ast_io_write16() with two calls to ast_io_write8() in ast_set_index_reg(). The combined 16-bit-wide write of an index register and the corresponding data register only works on little- endian systems. Write both registers independent from each other. Signed-off-by:
-
- 28 Feb, 2023 3 commits
-
-
Maíra Canal authored
As vc4_cl_lookup_bos() performs the same steps as drm_gem_objects_lookup(), replace the open-coded implementation in vc4 to simply use the DRM function. Signed-off-by:
André Almeida <andrealmeid@igalia.com> Reviewed-by:
-
Maíra Canal authored
The array of BOs that are lookup at the start of exec doesn't need to be instantiated as drm_gem_dma_object, as it doesn't benefit from its attributes. So, simplify the code by replacing the array of drm_gem_dma_object for an array of drm_gem_object in the struct vc4_exec_info. Suggested-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Thomas Zimmermann authored
This reverts commit 67b7836d. The locking appears incomplete. A caller of SHMEM helper's pin function never acquires the dma-buf reservation lock. So we get WARNING: CPU: 3 PID: 967 at drivers/gpu/drm/drm_gem_shmem_helper.c:243 drm_gem_shmem_pin+0x42/0x90 [drm_shmem_helper] Signed-off-by:
-
- 27 Feb, 2023 8 commits
-
-
Harry Wentland authored
This is useful to understand the bpc defaults and support of a driver. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Cc: Pekka Paalanen <ppaalanen@gmail.com> Cc: Sebastian Wick <sebastian.wick@redhat.com> Cc: Vitaly.Prosyak@amd.com Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joshua Ashton <joshua@froggi.es> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-By:
Joshua Ashton <joshua@froggi.es> Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentland@amd.com
-
Harry Wentland authored
The EDID of an HDR display defines EOTFs that are supported by the display and can be set in the HDR metadata infoframe. Userspace is expected to read the EDID and set an appropriate HDR_OUTPUT_METADATA. In drm_parse_hdr_metadata_block the kernel reads the supported EOTFs from the EDID and stores them in the drm_connector->hdr_sink_metadata. While doing so it also filters the EOTFs to the EOTFs the kernel knows about. When an HDR_OUTPUT_METADATA is set it then checks to make sure the EOTF is a supported EOTF. In cases where the kernel doesn't know about a new EOTF this check will fail, even if the EDID advertises support. Since it is expected that userspace reads the EDID to understand what the display supports it doesn't make sense for DRM to block an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't understand. This comes with the added benefit of future-proofing metadata support. If the spec defines a new EOTF there is no need to update DRM and an compositor can immediately make use of it. Bug: https://gitlab.freedesktop.org/wayland/weston/-/issues/609 v2: Distinguish EOTFs defind in kernel and ones defined in EDID in the commit description (Pekka) v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved to drm_hdmi_helper.c Signed-off-by:
-
Dom Cobley authored
Currently we schedule a call to output_poll_execute from drm_kms_helper_poll_enable for 10s in future. Later we try to replace that in drm_helper_probe_single_connector_modes with a 0s schedule with delayed_event set. But as there is already a job in the queue this fails, and the immediate job we wanted with delayed_event set doesn't occur until 10s later. And that call acts as if connector state has changed, reprobing modes. This has a side effect of waking up a display that has been blanked. Make sure we cancel the old job before submitting the immediate one. Fixes: 162b6a57 ("drm/probe-helper: don't lose hotplug event") Acked-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Dom Cobley <popcornmix@gmail.com> [Maxime: Switched to mod_delayed_work] Signed-off-by:
-
Dmitry Osipenko authored
Replace all drm-shmem locks with a GEM reservation lock. This makes locks consistent with dma-buf locking convention where importers are responsible for holding reservation lock for all operations performed over dma-bufs, preventing deadlock between dma-buf importers and exporters. Suggested-by:
-
Dmitry Osipenko authored
DMA-buf core has its own refcounting of vmaps, use it instead of drm-shmem counting. This change prepares drm-shmem for addition of memory shrinker support where drm-shmem will use a single dma-buf reservation lock for all operations performed over dma-bufs. Reviewed-by:
-
Dmitry Osipenko authored
Ease debugging of a multi-GPU system by using drm_WARN_*() and drm_dbg_kms() helpers that print out DRM device name corresponding to shmem GEM. Reviewed-by:
-
Dmitry Osipenko authored
Group all 1-bit boolean members of struct drm_gem_shmem_object in the end of the structure, allowing compiler to pack data better and making code to look more consistent. Reviewed-by:
-
Dmitry Osipenko authored
Add new common evict() callback to drm_gem_object_funcs and corresponding drm_gem_object_evict() helper. This is a first step on a way to providing common GEM-shrinker API for DRM drivers. Reviewed-by:
-
- 26 Feb, 2023 6 commits
-
-
Xu Panda authored
The implementation of strscpy() is more robust and safer. That's now the recommended way to copy NUL terminated strings. Signed-off-by:
Xu Panda <xu.panda@zte.com.cn> Signed-off-by:
Yang Yang <yang.yang29@zte.com> Signed-off-by:
-
Jani Nikula authored
Currently we only parse the Tiled Display Topology Data Block for DisplayID structure version 1.2, but not 2.0. The contents seem to be the same for both, so expand the parsing to structure version 2.0. Note that DisplayID spec version is not the same as DisplayID structure version; DisplayID 1.3 uses structure version 1.2, and DisplayID 2.0-2.1 use structure version 2.0. Lovely. Signed-off-by:
-
Jani Nikula authored
Use the DisplayID 2.0 primary use case information to deduce whether this is a head-mounted display, and should not be used for desktop. Cc: Iaroslav Boliukin <iam@lach.pw> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
-
Jani Nikula authored
The DisplayID structure version and primary use case are stored in the DisplayID Base Section. We should be checking them in a number of places when parsing the DisplayID blocks. Currently, we completely ignore the primary use case, and just look at the block tags without cross-checking against structure version. Store the version and primary use case in the DisplayID iterator, and provide accessors to them. In general, the information is needed when iterating the blocks, and this is a convenient place to both store and retrieve the information during parsing. Promote using accessors rather than users poking at the iterator directly. Cc: Iaroslav Boliukin <iam@lach.pw> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
-
Jani Nikula authored
Avoid figuring out the header pointer multiple times. Cc: Iaroslav Boliukin <iam@lach.pw> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
-
Jani Nikula authored
Add a helper to get a pointer to struct displayid_header. To be pedantic, add buffer overflow checks to not touch the base if that itself would overflow. Cc: Iaroslav Boliukin <iam@lach.pw> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
-
- 24 Feb, 2023 3 commits
-
-
Maíra Canal authored
As v3d_job_add_deps() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in v3d in order to simply use the DRM function. Signed-off-by:
-
Maíra Canal authored
As panfrost_copy_in_sync() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in Panfrost in order to simply use the DRM function. Reviewed-by:
Alyssa Rosenzweig <alyssa@collabora.com> Signed-off-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Maíra Canal authored
In order to add a syncobj's fence as a dependency to a job, it is necessary to call drm_syncobj_find_fence() to find the fence and then add the dependency with drm_sched_job_add_dependency(). So, wrap these steps in one single function, drm_sched_job_add_syncobj_dependency(). Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
- 23 Feb, 2023 3 commits
-
-
Matthew Auld authored
The ttm bo now initially has NULL bo->resource, and leaves the driver the handle that. However it looks like we forgot to handle that for radeon. It looks like this will just null-ptr-deref in radeon_bo_move(), if bo->resource is NULL. Fix this by calling move_null(). Fixes: 18025378 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208145319.397235-4-matthew.auld@intel.comReviewed-by:
-
Matthew Auld authored
The ttm bo now initially has NULL bo->resource, and leaves the driver the handle that. However it looks like we forgot to handle that for qxl. It looks like this will just null-ptr-deref in qxl_bo_move(), if bo->resource is NULL. Fix this by calling move_null() if the new resource is TTM_PL_SYSTEM, otherwise do the multi-hop sequence to ensure can safely call into ttm_bo_move_memcpy(), since it might also need to clear the memory. This should give the same behaviour as before. Fixes: 18025378 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by:
-
Matthew Auld authored
The ttm BO now initially has NULL bo->resource, and leaves the driver the handle that. However it looks like we forgot to handle that for ttm_bo_move_memcpy() users, like with vram-gem, since it just silently returns zero. This seems to then trigger warnings like: WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_gem_vram_helper.c:255 drm_gem_vram_offset (??:?) Fix this by calling move_null() if the new resource is TTM_PL_SYSTEM, otherwise do the multi-hop sequence to ensure can safely call into ttm_bo_move_memcpy(), since it might also need to clear the memory. This should give the same behaviour as before. While we are here let's also treat calling ttm_bo_move_memcpy() with NULL bo->resource as programmer error, where expectation is that upper layers should now handle it. Fixes: 18025378 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by:
-
- 21 Feb, 2023 1 commit
-
-
Jiri Slaby (SUSE) authored
gcc-13 warns about mismatching types for enums. That revealed switched arguments of nv50_wndw_new_(): drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int, const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)' drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of 'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)' It can be barely visible, but the declaration says about the parameters in the middle: enum nv50_disp_interlock_type, u32 interlock_data, u32 heads, While the definition states differently: u32 heads, enum nv50_disp_interlock_type interlock_type, u32 interlock_data, Unify/fix the declaration to match the definition. Fixes: 53e0a3e7 ("drm/nouveau/kms/nv50-: simplify tracking of channel interlocks") Cc: Martin Liska <mliska@suse.cz> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Jiri Slaby (SUSE) <jirislaby@kernel.org> Signed-off-by:
Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221031114229.10289-1-jirislaby@kernel.org
-
