- 10 Mar, 2020 15 commits
-
-
Lyude Paul authored
Noticed this while having some problems with hubs sometimes not being detected on the first plug. Every single dpcd read or write function returns the number of bytes transferred on success or a negative error code, except apparently for drm_dp_mst_dpcd_write() - which returns 0 on success. There's not really any good reason for this difference that I can tell, and having the two functions give differing behavior means that drm_dp_dpcd_write() will end up returning 0 on success for MST devices, but the number of bytes transferred for everything else. So, fix that and update the kernel doc. Signed-off-by:
Lyude Paul <lyude@redhat.com> Fixes: 2f221a5e ("drm/dp_mst: Add MST support to DP DPCD R/W functions") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-2-lyude@redhat.comReviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
H. Nikolaus Schaller authored
The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. There are two variants of the COM37H3M panel. The older one's COM37H3M05DTC data sheet specifies: MIN TYP MAX CLK frequency fCLK -- 22.4 26.3 MHz (in VGA mode) VSYNC Frequency fVSYNC 54 60 66 Hz VSYNC cycle time tv -- 650 -- H HSYNC frequency fHSYNC -- 39.3 -- kHz HSYNC cycle time th -- 570 -- CLK The newer one's COM37H3M99DTC data sheet says: MIN TYP MAX CLK frequency fCLK 18 19.8 27 MHz VSYNC Frequency fVSYNC 54 60 66 Hz VSYNC cycle time tv 646 650 700 H HSYNC frequency fHSYNC -- 39.0 50.0 kHz HSYNC cycle time th 504 508 630 CLK So we choose a parameter set that lies within the specs of both variants. We start at .vrefresh = 60, choose .htotal = 570 and .vtotal = 650 and end up in a clock of 22.230 MHz. Reported-by:Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/e63a0533ad5b5142373437ef758aedbdb716152d.1583826198.git.hns@goldelico.com
-
Laurent Pinchart authored
The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type accordingly. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Akeem G Abodunrin authored
In Pete Goodliffe words, "You can improve a system by adding new code. You can also improve a system by removing code" - In this case, commit "202b52b7" added new code to initialize end of the node. So, there is no need for duplicated initialization, and this patch simply removes it. Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Neil Armstrong authored
This patch adds support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. In addition if pixel stream down-sampling, the Y Cb Cr components must also be mapped differently to align with the HDMI2.0 specifications. This mode needs a different clock generation scheme since the TMDS PHY clock must match the 10x ratio with the YUV420 pixel clock, but the video encoder must run at 2x the pixel clock. This patch enables the bridge bus format negociation, and handles the YUV420 case if selected by the negociation. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-12-narmstrong@baylibre.com
-
Neil Armstrong authored
This patch adds clocking support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. This mode needs a different clock generation scheme since the TMDS PHY clock must match the 10x ratio with the YUV420 pixel clock, but the video encoder must run at 2x the pixel clock. This patch adds the TMDS PHY clock value in all the video clock setup in order to better support these specific uses cases and switch to the Common Clock framework for clocks handling in the future. Signed-off-by:
-
Neil Armstrong authored
This patch adds encoding support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. In addition if pixel stream down-sampling, the Y Cb Cr components must also be mapped differently to align with the HDMI2.0 specifications. Signed-off-by:
-
Neil Armstrong authored
To allow using formats from negotiation, stop enforcing input_bus_format in the private dw-plat-data struct. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
-
Neil Armstrong authored
Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local bridge, connecting it to the dw-hdmi bridge, then implement the atomic_get_input_bus_fmts/atomic_get_output_bus_fmts. Signed-off-by:
-
Neil Armstrong authored
Before switching to bridge funcs, make sure drm_display_mode is passed as const to the venc functions. Signed-off-by:
-
Neil Armstrong authored
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support for these modes in the connector if the platform supports them. We limit these modes to DW-HDMI IP version >= 0x200a which are designed to support HDMI2.0 display modes. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
-
Neil Armstrong authored
Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate the possible output and input formats for the current mode and monitor, and use the negotiated formats in a basic atomic_check callback. Signed-off-by:
-
Neil Armstrong authored
Add atomic_duplicate_state/atomic_destroy_state/atomic_reset bridge funcs to allow setup of atomic bridge state. Signed-off-by:
-
Jonas Karlman authored
Add the max_bpc property to the dw-hdmi connector to prepare support for 10, 12 & 16bit output support. Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
Jonas Karlman authored
Configure the correct mtmdsclock for deep colors to prepare support for 10, 12 & 16bit output. Signed-off-by:
-
- 09 Mar, 2020 3 commits
-
-
Gurchetan Singh authored
This function can be reused for hostmem objects. v2: move virtio_gpu_is_shmem() check to virtio_gpu_cleanup_object() v3: use-after free fix Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-2-gurchetansingh@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gurchetan Singh authored
A resource will be a shmem based resource or a (planned) vram based resource, so it makes sense to factor out common fields (resource handle, dumb). v2: move mapped field to shmem object Signed-off-by:
-
Chris Wilson authored
Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its only caller. The diff chooses it to so it by moving drm_pci_agp_destroy earlier, but the important bit is moving the #ifdef earlier before drm_pci_agp_init. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200307093702.2269-1-chris@chris-wilson.co.uk
-
- 07 Mar, 2020 2 commits
-
-
Peter Rosin authored
This reverts commit 0f9cdd74. The interface of the panel is LVDS, not parallel. The color depth is RGB888, not RGB565. The panel has additional features, making it not so simple. The only user (upstream) of this panel is appropriately using panel-lvds. Suggested-by:
Thierry Reding <thierry.reding@gmail.com> Suggested-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 06 Mar, 2020 19 commits
-
-
Dafna Hirschfeld authored
convert the binding file rockchip-drm.txt to yaml format. This was tested and verified on ARM and ARM64 with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml Changes since v2: - add a missing ">" sign in maintainers list - change the licens to GPL-2.0-only - add "additionalProperties: false" - change the commit message to conform that it was tested on both ARM and ARM64 Changes since v1: - fixed worng sign-off - fixed the path of the $id property to be the path of the yaml file Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200121154314.3444-1-dafna.hirschfeld@collabora.com
-
Daniel Vetter authored
Only user left is the shadow attach for legacy drivers. v2: Shift the #ifdef CONFIG_DRM_LEGACY to now also include drm_get_pci_dev() (Thomas) Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225165835.2394442-1-daniel.vetter@ffwll.ch
-
Pankaj Bharadiya authored
drm_fb_helper tasks are completed now hence remove them from todo list. Changes since v1: * remove entire drm_fb_helper tasks from todo list. Daniel's "64914da2 drm/fbdev-helper: don't force restores" already fixes first one (Daniel) Signed-off-by:
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-8-pankaj.laxminarayan.bharadiya@intel.com
-
Pankaj Bharadiya authored
drm_fb_helper_single_add_all_connectors(), drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector() don't keep an array of connectors anymore and are just dummy. Now we have no callers to these functions hence remove them. Signed-off-by:
-
Pankaj Bharadiya authored
drm_fb_helper_{add,remove}_one_connector() and drm_fb_helper_single_add_all_connectors() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h This removal is done using below sementic patch and unused variable compilation warnings are fixed manually. @@ @@ - drm_fb_helper_single_add_all_connectors(...); @@ expression e1; statement S; @@ - e1 = drm_fb_helper_single_add_all_connectors(...); - S @@ @@ - drm_fb_helper_add_one_connector(...); @@ @@ - drm_fb_helper_remove_one_connector(...); Changes since v1: * Squashed warning fixes into the patch that introduced the warnings (into 5/7) (Laurent, Emil, Lyude) Signed-off-by: -
Pankaj Bharadiya authored
drm_fb_helper_{add,remove}_one_connector() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h Signed-off-by: -
Pankaj Bharadiya authored
drm_fb_helper_{add,remove}_one_connector() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h Signed-off-by: -
Pankaj Bharadiya authored
drm_fb_helper_{add,remove}_one_connector() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h Signed-off-by: -
Pankaj Bharadiya authored
The max connector argument for drm_fb_helper_init() isn't used anymore hence remove it. All the drm_fb_helper_init() calls are modified with below sementic patch. @@ expression E1, E2, E3; @@ - drm_fb_helper_init(E1,E2, E3) + drm_fb_helper_init(E1,E2) Signed-off-by:
-
Lukas Bulwahn authored
Commit 52791eee ("dma-buf: rename reservation_object to dma_resv") renamed include/linux/reservation.h to include/linux/dma-resv.h, but missed the reference in the MAINTAINERS entry. Since then, ./scripts/get_maintainer.pl --self-test complains: warning: no file matches F: include/linux/reservation.h Adjust the DMA BUFFER SHARING FRAMEWORK entry in MAINTAINERS. Co-developed-by:
Sebastian Duda <sebastian.duda@fau.de> Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/356414/Signed-off-by:
-
Randy Dunlap authored
Unbreak the DRM menu. This Kconfig symbol does not depend on DRM, so the menu is broken at that point. Move the symbol to a location in the Kconfig file so that it does not break the dependency continuity. Fixes: 6349120d ("drm: Move EXPORT_SYMBOL_FOR_TESTS_ONLY under a separate Kconfig") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Chris Wilson authored
We try hard to select a suitable hole in the drm_mm first time. But if that is unsuccessful, we then have to look at neighbouring nodes, and this requires traversing the rbtree. Walking the rbtree can be slow (much slower than a linear list for deep trees), and if the drm_mm has been purposefully fragmented our search can be trapped for a long, long time. For non-preemptible kernels, we need to break up long CPU bound sections by manually checking for cond_resched(); similarly we should also bail out if we have been told to terminate. (In an ideal world, we would break for any signal, but we need to trade off having to perform the search again after ERESTARTSYS, which again may form a trap of making no forward progress.) Reported-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200207151720.2812125-1-chris@chris-wilson.co.uk
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Thomas Zimmermann authored
Per-CRTC VBLANK information used to be addressed by device and pipe index. A call drm_crtc_vblank_helper_get_vblank_timestamp_internal() receives a pointer to the CRTC instead. Fix the documentation. Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
-
Thomas Zimmermann authored
Brings the documentation of drm_simple_encoder_init() in sync with the function's signature. Also add a paragraph clarifying the management of the encoder's memory. v2: * document memory management Signed-off-by:
-
Heiko Stuebner authored
Panel driver for the KD35T133 display from Elida, used for example in the rk3326-based Odroid Go Advance handheld. changes in v3: - add missing return value assignment (Francesco) - re-sort header includes (Sam) changes in v2: - rename dsi_generic_write_seq macro to dsi_dcs_write_seq to honor the underlying mipi_dsi_dcs_write (Robin) Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by:
-
Heiko Stuebner authored
The KD35T133 is a 3.5" 320x480 DSI display used in the RK3326-based Odroid Go Advance handheld device. Signed-off-by:
-
- 05 Mar, 2020 1 commit
-
-
James Hughes authored
The wait_for macro's for Broadcom V3D driver used msleep, which is inappropriate due to its inaccuracy at low values (minimum wait time is about 30ms on the Raspberry Pi). This sleep was triggering in v3d_clean_caches(), causing us to only be able to dispatch ~33 compute jobs per second. This patch replaces the macro with the one from the Intel i915 version which uses usleep_range to provide more accurate waits. v2: Split from the vc4 patch so that we can confidently apply to stable (by anholt) Signed-off-by:James Hughes <james.hughes@raspberrypi.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200217153145.13780-1-james.hughes@raspberrypi.com Link: https://github.com/raspberrypi/linux/issues/3460 Fixes: 57692c94 ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")
-
