- 09 Mar, 2023 5 commits
-
-
Jacob Keller authored
Use the overflow-protected struct_size() helper macro to compute the allocation size of the vop2 data structure. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: Heiko Stübner <heiko@sntech.de> Cc: David Airlie <airlied@gmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230223013533.1707706-1-jacob.e.keller@intel.com
-
Sascha Hauer authored
The Rockchip PLL drivers are currently table based and support only the most common pixelclocks. Discard all modes we cannot achieve at all. Normally the desired pixelclocks have an exact match in the PLL driver, nevertheless allow for a 0.1% error just in case. Tested-by:
Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Tested-by:
Michael Riesch <michael.riesch@wolfvision.net> Tested-by:
Dan Johansen <strit@manjaro.org> Link: https://lore.kernel.org/r/20230118132213.2911418-4-s.hauer@pengutronix.deSigned-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Sascha Hauer authored
This adds the PLL/phy settings to support higher resolutions like 4k@30. The values were taken from the Rockchip downstream Kernel. Tested-by:
-
Sascha Hauer authored
The driver checks if the pixel clock of the given mode matches an entry in the mpll config table. At least for the Synopsys phy the frequencies in the mpll table are meant as a frequency range up to which the entry works, not as a frequency that must match the pixel clock. Return MODE_OK when the pixelclock is smaller than one of the mpll frequencies to allow for more display resolutions. Limit this behaviour to the Synopsys phy at the moment and keep the current behaviour of forcing exact pixelclock rates for the other phys until it has been sorted out how and if the vendor specific phys work with non standard clock rates. Tested-by:
-
Sascha Hauer authored
The different VOP variants support different maximum resolutions. Reject resolutions that are not supported by a specific variant. This hasn't been a problem in the upstream driver so far as 1920x1080 has been the maximum resolution supported by the HDMI driver and that resolution is supported by all VOP variants. Now with higher resolutions supported in the HDMI driver we have to limit the resolutions to the ones supported by the VOP. The actual maximum resolutions are taken from the Rockchip downstream Kernel. Signed-off-by:
-
- 07 Mar, 2023 7 commits
-
-
Konrad Dybcio authored
Add support for the Sony TD4353 JDI 2160x1080 display panel used in some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics of smartphone manufacturing, it is impossible to retrieve a better name for this panel. This revision adds support for the default 60 Hz configuration, however there could possibly be some room for expansion, as the display panels used on Sony devices have historically been capable of >2x refresh rate overclocking. Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230119163201.580858-2-konrad.dybcio@linaro.org
-
Konrad Dybcio authored
Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2 Compact smartphones. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Maya Matuszczyk authored
Note that this patch is 'heavily inspired' by orientation support in driver for Elida KD35T133 panel Signed-off-by:
Maya Matuszczyk <maccraft123mc@gmail.com> Signed-off-by:
-
Maya Matuszczyk authored
Add KD50T048A MIPI-DSI panel, which is based on ST7701 chip. Not sure what else to add to this commit message. Signed-off-by:
-
Maya Matuszczyk authored
Add compatible for 854x480 Elida KD50T048A panel, found in Odroid Go Super and Odroid Go Ultra Signed-off-by:
-
Jiapeng Chong authored
The function dsi_read is defined in the dw-mipi-dsi-rockchip.c file, but not called elsewhere, so remove this unused function. drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:362:19: warning: unused function 'dsi_read'. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3984Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Deepak R Varma authored
According to Documentation/filesystems/sysfs.rst, the show() callback function of kobject attributes should strictly use sysfs_emit() instead of sprintf() family functions. So, make this change. Issue identified using the coccinelle device_attr_show.cocci script. Signed-off-by:
Deepak R Varma <drv@mailo.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
- 06 Mar, 2023 2 commits
-
-
Dmitry Osipenko authored
VirtIO-GPU got a new config option for disabling KMS. There were two problems left unnoticed during review when the new option was added: 1. The IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) check in the code was inverted, hence KMS was disabled when it should be enabled and vice versa. 2. The disabled KMS crashed kernel with a NULL dereference in drm_kms_helper_hotplug_event(), which shall not be invoked with a disabled KMS. Fix the inverted config option check in the code and skip handling the VIRTIO_GPU_EVENT_DISPLAY sent by host when KMS is disabled in guest to fix the crash. Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Fixes: 72122c69 ("drm/virtio: Add option to disable KMS support") Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230306163916.1595961-1-dmitry.osipenko@collabora.com
-
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:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-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:
-
