- 30 Nov, 2020 2 commits
-
-
Thomas Zimmermann authored
The new GEM object function drm_gem_cma_mmap() sets the VMA flags and offset as in the old implementation and immediately maps in the buffer's memory pages. Changing CMA helpers to use the GEM object function allows for the removal of the special implementations for mmap and gem_prime_mmap callbacks. The regular functions drm_gem_mmap() and drm_gem_prime_mmap() are now used. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201123115646.11004-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
These functions are not directly related to PRIME interfaces any longer, but are now GEM object functions. Rename them accordingly and fix the docs. Signed-off-by:
-
- 29 Nov, 2020 13 commits
-
-
Douglas Anderson authored
Add support for the BOE NV110WTM-N61 panel. The EDID lists two modes (one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of them here. Note that the panel datasheet requires 80 ms between HPD asserting and the backlight power being turned on. We'll use the new timing constraints structure to do this cleanly. This assumes that the backlight will be enabled _after_ the panel enable finishes. This is how it works today and seems a sane assumption. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201109170018.v4.4.I71b2118dfc00fd7b43b02d28e7b890081c2acfa2@changeid
-
Douglas Anderson authored
Add yet another eDP panel. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Douglas Anderson authored
On the panel I'm looking at, there's an 80 ms minimum time between HPD being asserted by the panel and setting the backlight enable GPIO. While we could just add an 80 ms "enable" delay, this is not ideal. Link training is allowed to happen in parallel with this delay so the fixed 80 ms delay over-delays. We'll support this by logging the time at the end of prepare and then delaying in enable if enough time hasn't passed. Signed-off-by:
-
Douglas Anderson authored
It is believed that all of the current users of the "unprepare" delay don't actually need to wait the amount of time specified directly in the unprepare phase. The purpose of the delay that's specified is to allow the panel to fully power off so that we don't try to power it back on before it's managed to full power down. Let's use this observation to avoid the fixed delay that we currently have. Instead of delaying, we'll note the current time when the unprepare happens. If someone then tries to prepare the panel later and not enough time has passed, we'll do the delay before starting the prepare phase. Signed-off-by:
-
Douglas Anderson authored
When I run: scripts/kernel-doc -rst drivers/gpu/drm/panel/panel-simple.c I see that several of the kernel-doc entries aren't showing up because they don't specify the full path down the hierarchy. Let's fix that and also move to inline kernel docs. Signed-off-by:
-
Dan Carpenter authored
The NULL checking isn't done consistently in this function and it leads to a static checker warning: drivers/gpu/drm/kmb/kmb_drv.c:561 kmb_pm_suspend() error: we previously assumed 'drm' could be null (see line 559) Fortunately "drm" cannot be NULL at this point so the check can just be removed. Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Anitha Chrisanthus <anitha.chrisanthus@intel.com> Signed-off-by:
-
Tom Rix authored
The macro use will already have a semicolon. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Sam Ravnborg authored
Fix following W=1 warnings: - Fix set but not used variables that were used only for logging. Fixed by introducing no_printk() to trick compiler to think variables are used - Fix kernel-doc warning by deleting an empty comment line v3: - Fix grammar in commit message (Thomas) v2: - Subject updated (Lee) Signed-off-by:
-
Sam Ravnborg authored
Replacing DPRINTK() statements with pr_debug fixes set but not used warnings. And moves to a more standard logging setup at the same time. v2: - Fix indent (Joe) Signed-off-by:
-
Sam Ravnborg authored
Fix kernel-doc warnings reported when using W=1. v3: - Do not replace '-' with ':' (Thomas) v2: - Improve subject (Lee) Signed-off-by:
-
Dafna Hirschfeld authored
In the help of ROCKCHIP_DW_MIPI_DSI it said it is a HDMI driver instead of a dsi driver. Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201116141609.26719-1-dafna.hirschfeld@collabora.com
-
Dafna Hirschfeld authored
There is a use of DRM_DEV_ERROR(dsi->dev,..) which should be replaced with DRM_DEV_ERROR(dev, ..) since dsi->dev is set later Signed-off-by:
-
Jonathan Liu authored
Error message incorrectly refers to grf clock instead of vpll clock. Signed-off-by:
Jonathan Liu <net147@gmail.com> Signed-off-by:
-
- 28 Nov, 2020 1 commit
-
-
Paul Cercueil authored
Call drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() on suspend and resume, respectively. This makes sure that the display stack is properly disabled when the hardware is put to sleep. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
-
- 27 Nov, 2020 4 commits
-
-
Daniel Vetter authored
Not technically a problem for ttm, but very likely a driver bug and pretty big time confusing for reviewing code. So warn about it, both at cleanup time (so we catch these for sure) and at pin/unpin time (so we know who's the culprit). Reviewed-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028113120.3641237-1-daniel.vetter@ffwll.ch
-
Randy Dunlap authored
It looks like SPARC64 requires FB_ATY_CT to build without errors, so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled instead of using "default y if SPARC64 && PCI", which is not strong enough to prevent build errors. As it currently is, FB_ATY_CT can be disabled, resulting in build errors: ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined! ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined! Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Fixes: f7018c21 ("video: move fbdev to drivers/video/fbdev") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdunlap@infradead.org
-
Bernard Zhao authored
This change also fix checkpatch.pl warning: WARNING: Prefer using '"%s...", __func__' to using 'via_driver_irq_postinstall', this function's name, in a string + DRM_DEBUG("via_driver_irq_postinstall\n"); Signed-off-by:Bernard Zhao <bernard@vivo.com> Signed-off-by:
-
Christian König authored
Reorder the code to fix checking if blitting is available. Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/403847/
-
- 26 Nov, 2020 3 commits
-
-
Laurentiu Palcu authored
This patch adds support for using NN interpolation scaling by setting the SCALING_FILTER plane property to 1. Otherwise, the default method is used. Signed-off-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Laurentiu Palcu authored
This small patch fixes a warning that I got while running coccinelle: CHECK drivers/gpu/drm/imx/dcss/dcss-plane.c drivers/gpu/drm/imx/dcss/dcss-plane.c:107:21-23: WARNING !A || A && B is equivalent to !A || B Fixes: 9021c317 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by:
-
Laurentiu Palcu authored
DCSS supports 90/180/270 degree rotations for Vivante tiled and super-tiled formats. Unfortunately, with the current code, they didn't work properly. This simple patch makes the rotations work by fixing the way the scaler is set up for 90/270 degree rotations. In this particular case, the source width and height need to be swapped since DPR is sending the buffer to scaler already rotated. Also, make sure to allow full rotations for DRM_FORMAT_MOD_VIVANTE_SUPER_TILED. Fixes: 9021c317 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by:
-
- 25 Nov, 2020 2 commits
-
-
Colin Ian King authored
The masking of val with ~MCDE_CRX1_CLKSEL_MASK is currently being ignored because there seems to be a missing bitwise-or of val in the following statement. Fix this by replacing the assignment of val with a bitwise-or. Fixes: d795fd32 ("drm/mcde: Support DPI output") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused valued") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201124121528.395681-1-colin.king@canonical.com
-
Maarten Lankhorst authored
We hardcode the maximum number of shared fences to 4, instead of respecting num_fences. Use a minimum of 4, but more if num_fences is higher. This seems to have been an oversight when first implementing the api. Fixes: 04a5faa8 ("reservation: update api and add some helpers") Cc: <stable@vger.kernel.org> # v3.17+ Reported-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201124115707.406917-1-maarten.lankhorst@linux.intel.com
-
- 24 Nov, 2020 15 commits
-
-
Lukas F. Hartmann authored
The Innolux N125HCE-GN1 display is used in the MNT Reform 2.0 laptop, attached via eDP to a SN65DSI86 MIPI-DSI to eDP bridge. Signed-off-by:
Lukas F. Hartmann <lukas@mntre.com> Signed-off-by:
-
Lukas F. Hartmann authored
The Innolux N125HCE-GN1 display is used in the MNT Reform 2.0 laptop, attached via eDP to a SN65DSI86 MIPI-DSI to eDP bridge. This patch contains the DT binding for "innolux,n125hce-gn1". Signed-off-by:
-
Simon Ser authored
This patch fixes the following kernel-doc warnings: /home/simon/src/linux/Documentation/gpu/drm-kms:466: ./drivers/gpu/drm/drm_crtc.c:236: WARNING: Unexpected indentation. /home/simon/src/linux/Documentation/gpu/drm-kms:466: ./drivers/gpu/drm/drm_crtc.c:237: WARNING: Block quote ends without a blank line; unexpected unindent. /home/simon/src/linux/Documentation/gpu/drm-kms:472: ./drivers/gpu/drm/drm_blend.c:203: WARNING: Unexpected indentation. /home/simon/src/linux/Documentation/gpu/drm-kms:472: ./drivers/gpu/drm/drm_blend.c:204: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by:Simon Ser <contact@emersion.fr> Fixes: 5c759eda ("drm: Introduce plane and CRTC scaling filter properties") Cc: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Acked-by:
-
Thomas Zimmermann authored
Flushing the fbdev's shadow buffer requires vmap'ing the BO memory, which in turn requires pinning the BO. While being pinned, the BO cannot be moved into VRAM for scanout. Consequently, a concurrent modeset operation that involves the fbdev framebuffer would likely fail. Resolve this problem be acquiring the modeset lock of the planes that use the fbdev framebuffer. On non-atomic drivers, also acquire the mode-config lock. This serializes the flushing of the framebuffer with concurrent modeset operations. v2: * only acquire struct drm_fb_helper.lock in damage blitter (Daniel, Christian) Signed-off-by:
-
Thomas Zimmermann authored
Copy the vmap()'ed instance of struct dma_buf_map before modifying it, in case the implementation of vunmap() depends on the exact address. Signed-off-by:
-
Thomas Zimmermann authored
If the damage handling fails, restore the damage area. The next invocation of the damage worker will then perform the update. v3: * Use drm_WARN_ONCE() with an error message to print warning v2: * print a single warning if dirty callback fails (Daniel, Sebastian) * update comment Signed-off-by:
-
Thomas Zimmermann authored
Introduce a separate function for the blit code and its vmap setup. Done in preparation of additional changes. No functional changes are made. v3: * Use drm_WARN_ONCE() with an error message to print warning v2: * print a single warning if damage blitter fails Signed-off-by:
-
Thomas Zimmermann authored
Flushing the shadow framebuffer and invoking the dirty callback are two separate operations, so do them separately. The flush operation is paired with calls to vmap and vunmap. They are not needed for the dirty callback, which performs its own invocations if necessary. Signed-off-by:
-
Thomas Zimmermann authored
Returning early in the damage worker if no update is required. Makes the code more readable. No functional changes are being made. v3: * s/dirty/damage in commit message (Sam) Signed-off-by:
-
Thomas Zimmermann authored
The dirty worker handles all damage updates, instead of just calling the framebuffer's dirty callback. Rename it to damage worker. Also rename related variables accordingly. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
DRM client's vmap/vunmap functions don't allow for multiple vmap operations. Calling drm_client_buffer_vmap() twice returns the same mapping, then calling drm_client_buffer_vunmap() twice already unmaps on the first call. This leads to unbalanced vmap refcounts. Fix this by calling drm_gem_vmap() unconditionally in drm_client_buffer_vmap(). All drivers that support DRM clients have to implement correct ref- counting for their vmap operations, or not vunmap at all. This is the case for drivers that use CMA, SHMEM and VRAM helpers, and QXL. Other drivers are not affected. Signed-off-by:
-
Thomas Zimmermann authored
The fbdev helper's generic probe function establishes a mapping for framebuffers without shadow buffer. The clean-up function did not unmap the buffer object. Add the unmap operation. As fbdev devices are usally released during system shutdown, this has not been a problem in practice. Signed-off-by:
-
Thomas Zimmermann authored
If fbdev uses a shadow framebuffer, call the damage handler. Otherwise the update might not make it to the screen. v2: * mark virtual screen as dirty (Ville) Signed-off-by:
-
Thomas Zimmermann authored
Cached page mappings are now the default for SHMEM GEM objects. Remove the obsolete create function for cached mappings. Signed-off-by:
-
Thomas Zimmermann authored
SHMEM-buffer backing storage is allocated from system memory; which is typically cachable. The default mode for SHMEM objects is writecombine though. Unify SHMEM semantics by defaulting to cached mappings. The exception is pages imported via dma-buf. DMA memory is usually not cached. DRM drivers that require write-combined mappings set the map_wc flag in struct drm_gem_shmem_object to true. This currently affects lima, panfrost and v3d. The drivers mgag200, udl, virtio and vkms continue to use default shmem mappings. The drivers cirrus and gm12u320 change caching flags. Both used writecombine and now switch over to shmem defaults. Both drivers use SHMEM objects as shadow buffers for internal video memory, so cached mappings will not affect them negatively. v3: * set value of shmem pointer before dereferencing it in __drm_gem_shmem_create() (Dan, kernel test robot) v2: * recreate patch on top of latest SHMEM helpers * update lima, panfrost, v3d to select writecombine (Daniel, Rob) Signed-off-by:
-
