- 05 Dec, 2019 5 commits
-
-
Thomas Zimmermann authored
Including <drm/drm_pci.h> is unnecessary in most cases. Replace these instances. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191203100406.9674-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
Including <drm/drm_pci.h> is unnecessary in most cases. Replace these instances. Signed-off-by:
-
Thomas Zimmermann authored
Including <drm/drm_pci.h> is unnecessary in most cases. Replace these instances. Signed-off-by:
-
Thomas Zimmermann authored
Declarations of drm_legacy_pci_{init,exit}() are being moved to drm_legacy.h. CONFIG_DRM_LEGACY protects the implementation. Signed-off-by: -
Thomas Zimmermann authored
Non-PCI systems should not build PCI helpers. Set up source code, header file and Makefile accordingly. Signed-off-by:
-
- 03 Dec, 2019 9 commits
-
-
Linus Walleij authored
The Rpi panel driver doesn't use any symbols from these GPIO includes so just drop them. Cc: Eric Anholt <eric@anholt.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203152655.159281-1-linus.walleij@linaro.org
-
Benjamin Gaignard authored
Include drm_crtc_helper_internal.h to provide drm_connector_get_single_encoder prototype. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119125805.4266-1-benjamin.gaignard@st.com
-
Jani Nikula authored
Use const for fb_ops to let us make the info->fbops pointer const in the future. Cc: linux-fbdev@vger.kernel.org Cc: linux-omap@vger.kernel.org Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/dfa4376e219ffeef9175993eaff91b5fe7ecccab.1575022735.git.jani.nikula@intel.com
-
Jani Nikula authored
Use const for fb_ops to let us make the info->fbops pointer const in the future. v2: rebase Cc: linux-fbdev@vger.kernel.org Reviewed-by:
-
Jani Nikula authored
Avoid modifying the fb_ops via info->fbops to let us make the pointer const in the future. Cc: linux-fbdev@vger.kernel.org Reviewed-by:
-
Jani Nikula authored
Deferred IO now preserves the fb_ops. Cc: Bernie Thompson <bernie@plugable.com> Cc: linux-fbdev@vger.kernel.org Reviewed-by:
-
Jani Nikula authored
Deferred IO now preserves the fb_ops. Cc: Steve Glendinning <steve.glendinning@shawell.net> Cc: linux-fbdev@vger.kernel.org Reviewed-by:
-
Jani Nikula authored
Deferred IO now preserves the fb_ops. v2: Remove the no-op vfree, drop a local var (Noralf) Cc: Noralf Trønnes <noralf@tronnes.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
Jani Nikula authored
Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap and then resetting it to NULL afterwards causes problems all over the place. First, it prevents making the fbops member of struct fb_info a const pointer, which means we can't make struct fb_ops const anywhere. Second, a few places have to go out of their way to restore the original fb_mmap pointer that gets reset to NULL. Since the only user of the fbops->fb_mmap hook is fb_mmap() in fbmem.c, call fb_deferred_io_mmap() directly when deferred IO is enabled, and avoid modifying fb_ops altogether. Simply use info->fbdefio to determine whether deferred IO should be used or not. This should be accurate enough for all use cases, although perhaps not pedantically correct. v2: Simplify considerably by calling fb_deferred_io_mmap() directly (Daniel, Ville) Cc: Jaya Kumar <jayalk@intworks.biz> Cc: linux-fbdev@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
- 02 Dec, 2019 5 commits
-
-
Linus Walleij authored
This adds a starting point for processing and defining generic bindings used by DSI display controllers and panels attached to the virtual DSI ports. Cc: Stephan Gerhold <stephan@gerhold.net> Cc: devicetree@vger.kernel.org Suggested-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191128090726.51107-1-linus.walleij@linaro.orgReviewed-by:
-
Emil Velikov authored
As mentioned by Christian, for drivers which support only primary nodes this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS. For others, this check in particular will be a noop. So let's remove it as suggested by Christian. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Emil Velikov authored
As of earlier commit we have address space separation. Yet we forgot to remove the respective comment and DRM_AUTH in the ioctl declaration. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Steven Price <steven.price@arm.com> Fixes: 7282f764 ("drm/panfrost: Implement per FD address spaces") Signed-off-by:
Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191101130313.8862-4-emil.l.velikov@gmail.com
-
Emil Velikov authored
Current comment mentions /dev/drm which hasn't been a thing even before the code was merged into the kernel ;-) v2: drop explicit node path (Sean) Signed-off-by:
Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190722165648.7828-1-emil.l.velikov@gmail.com
-
Boris Brezillon authored
bridge->next is only points to the new bridge if drm_bridge_attach() succeeds. No need to reset it manually here. Note that this change is part of the attempt to make the bridge chain a double-linked list. In order to do that we must patch all drivers manipulating the bridge->next field. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023154512.9762-3-boris.brezillon@collabora.com
-
- 01 Dec, 2019 5 commits
-
-
Sam Ravnborg authored
Use the drm_panel_get_modes function. Signed-off-by:
-
Sam Ravnborg authored
Use the function drm_panel_get_modes(). Signed-off-by:
-
Sam Ravnborg authored
Call via drm_panel_get_modes(). Signed-off-by:
-
Sam Ravnborg authored
drm_panel_attach() will check if there is a controller already attached - drop the check in the driver. Use drm_panel_get_modes() so the driver no longer uses the function pointer. Signed-off-by:
-
Colin Ian King authored
There is a continue statement that is indented one level too deeply, remove the extraneous tab. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
- 30 Nov, 2019 2 commits
-
-
Adam Ford authored
Previously, there was an omap panel-dpi driver that would read generic timings from the device tree and set the display timing accordingly. This driver was removed so the screen no longer functions. This patch modifies the panel-simple file to setup the timings to the same values previously used. Fixes: 8bf4b162 ("drm/omap: Remove panel-dpi driver") Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
-
Adam Ford authored
This patch adds documentation of device tree bindings for the WVGA panel Logic PD Type 28 display. Signed-off-by:
-
- 29 Nov, 2019 6 commits
-
-
Ville Syrjälä authored
This thing can get called several thousand times per LUT so seems like we want to inline it to: - avoid the function call overhead - allow constant folding A quick synthetic test (w/o any hardware interaction) with a ridiculously large LUT size shows about 50% reduction in runtime on my HSW and BSW boxes. Slightly less with more reasonable LUT size but still easily measurable in tens of microseconds. v2: Include drm_color_mgmt.h in the .rst (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191108135654.12907-1-ville.syrjala@linux.intel.com
-
Daniel Vetter authored
We're doing a great job for really simple drivers right now, but still a lot of boilerplate for the bigger ones. Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127180035.416209-3-daniel.vetter@ffwll.ch
-
Wayne Lin authored
[Why] In hdmi_mode_alternate_clock(), it adds an exception for VIC 4 mode (4096x2160@24) due to there is no alternate clock defined for that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode. [How] Remove the exception v2: Adjust the comment description of hdmi_mode_alternate_clock() due to there is no more exception for VIC 4 mode. Signed-off-by:
Wayne Lin <Wayne.Lin@amd.com> Signed-off-by:
-
Wayne Lin authored
[Why] HDMI 2.0 adds aspect ratio attribute to distinguish different 4k modes. According to Appendix E of HDMI 2.0 spec, source should use VSIF to indicate video mode only when the mode is one defined in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC. Current code doesn't take aspect ratio into consideration while constructing avi infoframe. Should modify that. [How] Inherit Ville Syrjälä's work "drm/edid: Prep for HDMI VIC aspect ratio" at https://patchwork.kernel.org/patch/11174639/ Add picture_aspect_ratio attributes to edid_4k_modes[] and construct VIC and HDMI_VIC by taking aspect ratio into consideration. v2: Correct missing initializer error at adding aspect ratio of SMPTE mode. Signed-off-by:
-
Markus Elfring authored
A coccicheck run provided information like the following. drivers/gpu/drm/qxl/qxl_kms.c:295:1-7: ERROR: missing iounmap; ioremap on line 178 and execution via conditional on line 185 Generated by: scripts/coccinelle/free/iounmap.cocci A jump target was specified in an if branch. The corresponding function call did not release the desired system resource then. Thus use the label “rom_unmap” instead to fix the exception handling for this function implementation. Fixes: 5043348a ("drm: qxl: Fix error handling at qxl_device_init") Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Link: http://patchwork.freedesktop.org/patch/msgid/5e5ef9c4-4d85-3c93-cf28-42cfcb5b0649@web.deSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Daniel Vetter authored
If rockchip would switch over to the generic fbdev setup we could grabage collect even more of all this code (all of the remaining fb handling code really). v2: Actually use _with_dirty like the patch subject promised (Andrzej) Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by:
-
- 28 Nov, 2019 7 commits
-
-
Daniel Vetter authored
This was forgotten in f96bdf56 ("drm/rect: Handle rounding errors in drm_rect_clip_scaled, v3.") Spotted while reviewing patches from Ville touching this area. Reviewed-by:
-
Ville Syrjälä authored
Add selftests for drm_rect. A few basic ones for clipped and unclipped cases, and a few special ones for specific bugs we had in the code. I'm too lazy to think of more corner cases to check at this time. Maybe later. Signed-off-by:
-
Ville Syrjälä authored
Now that we've constrained the clipped source rectangle such that it can't have negative dimensions doing the same for the dst rectangle seems appropriate. Should at least result in the clipped src and dst rectangles being a bit more consistent with each other. Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
Limit the scaled clip to only clip at most dst_w/h pixels. This avoids the problem with clip_scaled() not being able to return negative values. Since new_src_w/h is now properly bounded we can remove the clamp()s. Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Testcase: igt/kms_selftest/drm_rect_clip_scaled_signed_vs_unsigned Signed-off-by:
-
Ville Syrjälä authored
Check for zero width/height destination rectangle in drm_rect_clip_scaled() to avoid a division by zero. Cc: stable@vger.kernel.org Fixes: f96bdf56 ("drm/rect: Handle rounding errors in drm_rect_clip_scaled, v3.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Daniel Vetter <daniel@ffwll.ch> Testcase: igt/kms_selftest/drm_rect_clip_scaled_div_by_zero Signed-off-by:
-
Daniel Vetter authored
0 means 1 as the default, but it's mighty confusing if the block size for the first plane is spelled out explicitly, but not for the 2nd plane. No cc: stable because this is just confusion, but 0 functional issue. Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Fixes: 7ba0fee2 ("drm/fourcc: Add AFBC yuv fourccs for Mali") Cc: Brian Starkey <brian.starkey@arm.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Alyssa Rosenzweig <alyssa@rosenzweig.io> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Daniel Vetter authored
0 means 1 as the default, but it's mighty confusing if the block size for the first plane is spelled out explicitly, but not for the 2nd plane. No cc: stable because this is just confusion, but 0 functional issue. Acked-by:
-
- 27 Nov, 2019 1 commit
-
-
Mihail Atanassov authored
Caused by file removal without adjusting the Makefile. Fixes: d268f42e ("drm/mediatek: don't open-code drm_gem_fb_create") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by:
Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by:
-
