- 23 Jul, 2018 2 commits
-
-
Thomas Zimmermann authored
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180717110927.30776-1-tzimmermann@suse.de
-
Oleksandr Andrushchenko authored
Dan Carpenter has reported that there is the following static checker warning: drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf() warn: 'sgt' can also be NULL 314 sgt = obj->dev->driver->gem_prime_get_sg_table(obj); 315 316 if (!IS_ERR(sgt)) { 317 if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir, Problematic functions are xen_drm_front_gem_get_sg_table and drm_gem_cma_prime_get_sg_table. Fix those by replacing NULL with error value. Signed-off-by:Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
- 19 Jul, 2018 4 commits
-
-
Lyude Paul authored
This isn't supposed to take dev as an argument, I guess no one noticed! Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180718215716.5784-1-lyude@redhat.com
-
Paul Kocialkowski authored
Not all sunxi platforms with the first version of the Display Engine support an alpha component on the plane with the lowest z position (as in: lowest z-pos), that gets blended with the background color. In particular, the A13 is known to have this limitation. However, it was recently discovered that the A20 and A33 are capable of having alpha on their lowest plane. Thus, this introduces a specific quirk to indicate such support, per-platform. Since this was not tested on sun4i and sun6i platforms, a conservative approach is kept and this feature is not supported. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180719080838.31598-2-paul.kocialkowski@bootlin.com
-
Paul Kocialkowski authored
In prevision for introducing a new quirk that will be used at atomic plane check time, register the quirks structure with the backend structure. This way, it can easily be grabbed where needed. Signed-off-by:
-
Giulio Benetti authored
Handle both positive and negative dclk polarity, according to bus_flags, taking care of this: On A20 and similar SoCs, the only way to achieve Positive Edge (Rising Edge), is setting dclk clock phase to 2/3(240°). By default TCON works in Negative Edge(Falling Edge), this is why phase is set to 0 in that case. Unfortunately there's no way to logically invert dclk through IO_POL register. The only acceptable way to work, triple checked with scope, is using clock phase set to 0° for Negative Edge and set to 240° for Positive Edge. On A33 and similar SoCs there would be a 90° phase option, but it divides also dclk by 2. This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers for using A33 90° phase divided by 2 and consequently increase code complexity. Check if panel is used. TCON can also handle VGA DAC, then panel could be empty. Signed-off-by:
Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by:
-
- 18 Jul, 2018 4 commits
-
-
Ayan Kumar Halder authored
drm_format_info table has a field 'is_yuv' to denote if the format is yuv or not. The driver is expected to use this instead of having a function for the same purpose. Signed-off-by:
Ayan Kumar halder <ayan.halder@arm.com> Reviewed-by:
Ville Syrjala <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1531847626-22248-5-git-send-email-ayan.halder@arm.com
-
Ayan Kumar Halder authored
drm_format_info table has a field 'is_yuv' to denote if the format is yuv or not. The driver is expected to use this instead of having a function for the same purpose. Signed-off-by:
-
Ayan Kumar Halder authored
drm_format_info table has a field 'is_yuv' to denote if the format is yuv or not. The driver is expected to use this instead of having a function for the same purpose. Signed-off-by:
-
Ayan Kumar Halder authored
A lot of drivers duplicate the function to check if a format is yuv or not. If we add a field (to denote whether the format is yuv or not) in the drm_format_info table, all the drivers can use this field and it will prevent duplication of similar logic. Signed-off-by:
-
- 17 Jul, 2018 5 commits
-
-
Gustavo A. R. Silva authored
Add suffix ULL to constant 1000 in order to give the compiler complete information about the proper arithmetic to use. Notice that such constant is used in a context that expects an expression of type u64 (64 bits, unsigned) and the following expression is currently being evaluated using 32-bit arithmetic: mode->clock * 1000 Addresses-Coverity-ID: 1466139 ("Unintentional integer overflow") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180704142255.GA8614@embeddedor.com
-
Thomas Zimmermann authored
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by:
-
Thomas Zimmermann authored
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by:
-
Paul Kocialkowski authored
Blending order is set based on the z position of each DRM plane. The blending order register is currently cleared at each atomic DRM commit, with the intent that each committed plane will set the appropriate bits (based on its z-pos) when enabling the plane. However, it sometimes happens that a particular plane is left unchanged by an atomic commit and thus will not be configured again. In that scenario, blending order is cleared and only the bits relevant for the planes affected by the commit are set. This leaves the planes that did not change without their blending order set in the register, leading to that plane not being displayed. Instead of clearing the blending order register at every atomic commit, this change moves the register's initial clear at bind time and only clears the bits for a specific plane when disabling it or changing its zpos. This way, planes that are left untouched by a DRM atomic commit are no longer disabled. Signed-off-by:
-
Thomas Zimmermann authored
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by:
-
- 16 Jul, 2018 5 commits
-
-
Lyude Paul authored
Signed-off-by:
-
Lyude Paul authored
This is something we've needed for a very long time now, as it makes debugging issues with faulty MST hubs along with debugging issues regarding us interfacing with hubs correctly vastly easier to debug. Currently this can actually be done if you trace the i2c devices for DP using ftrace but that's significantly less useful for a couple of reasons: - Tracing the i2c devices through ftrace means all of the traces are going to contain a lot of "garbage" output that we're sending over the i2c line. Most of this garbage comes from retrying transactions, DRM's helper library adding extra transactions to work around bad hubs, etc. - Having a user set up ftrace so that they can provide debugging information is a lot more difficult then being able to say "just boot with drm.debug=0x100" - We can potentially expand upon this tracing in the future to print debugging information in regards to other DP transactions like MST sideband transactions This is inspired by a patch Rob Clark sent to do this a long time back. Neither of us could find the patch however, so we both assumed it would probably just be easier to rewrite it anyway. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180716154432.13433-1-lyude@redhat.com
-
Alexandru Gheorghe authored
During iteration process one of the proposed mechanism for not breaking existing userspace was to report writeback connectors as disconnected, however the final version used DRM_CLIENT_CAP_WRITEBACK_CONNECTORS for that purpose. Change-Id: I2319d099f7669094c8530f1521abdbca08e76486 Signed-off-by:
Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/238399/
-
Michel Dänzer authored
Fixes the BUG_ON spuriously triggering under the following circumstances: * reservation_object_reserve_shared is called with shared_count == shared_max - 1, so obj->staged is freed in preparation of an in-place update. * reservation_object_add_shared_fence is called with the first fence, after which shared_count == shared_max. * reservation_object_add_shared_fence is called with a follow-up fence from the same context. In the second reservation_object_add_shared_fence call, the BUG_ON triggers. However, nothing bad would happen in reservation_object_add_shared_inplace, since both fences are from the same context, so they only occupy a single slot. Prevent this by moving the BUG_ON to where an overflow would actually happen (e.g. if a buggy caller didn't call reservation_object_reserve_shared before). v2: * Fix description of breaking scenario (Christian König) * Add bugzilla reference Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/106418 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1 Reviewed-by: Christian König <christian.koenig@amd.com> # v1 Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180704151405.10357-1-michel@daenzer.net
-
Neil Armstrong authored
Remove the modes timings tables for DMT modes and calculate the HW paremeters from the modes timings. Switch the DMT modes pixel clock calculation out of the static frequency list to a generic calculation from a range of possible PLL dividers. This patch is an intermediate step towards usage of the Common Clock Framwework for PLL setup, by reworking the code to have common sel_pll() function called by the CEA (HDMI) freq setup and the generic DMT frequencies setup, we should be able to simply call clk_set_rate() on the PLL clock handle in a near future. The CEA (HDMI) and CVBS modes needs very specific clock paths that CCF will never be able to determine by itself, so there is still some work to do for a full handoff to CCF handling the clocks. This setup permits setting non-CEA modes like : - 1600x900-60Hz - 1280x1024-75Hz - 1280x1024-60Hz - 1440x900-60Hz - 1366x768-60Hz - 1280x800-60Hz - 1152x864-75Hz - 1024x768-75Hz - 1024x768-70Hz - 1024x768-60Hz - 832x624-75Hz - 800x600-75Hz - 800x600-72Hz - 800x600-60Hz - 640x480-75Hz - 640x480-73Hz - 640x480-67Hz Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Jerome Brunet <jbrunet@baylibre.com> [narmstrong: fixed trivial checkpatch issues] Link: https://patchwork.freedesktop.org/patch/msgid/1531726814-14638-1-git-send-email-narmstrong@baylibre.com
-
- 13 Jul, 2018 20 commits
-
-
Daniel Vetter authored
Lots of added text here since I think the various control flow bits are worth explaining a bit better. v2: Fix conflict with Boris' no_vblank addition. Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-15-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Fixes a dead link I spotted in the struct drm_crtc docs. Comments themselves are in a surprisingly good state. v2: Fix subject typo (Sean). Reviewed-by:
-
Daniel Vetter authored
Instead of spreading them all over the place. Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
Daniel Vetter authored
And clean them up a bit, as usual. v2: Fix nits (Sean). Reviewed-by:
-
Daniel Vetter authored
And use that opportunity to polish the kernel doc all around: - Beef up some of the documentation. - Intro text for drm_plane and better links - Fix all the hyperlinks! v2: Fix linebreaks. Reviewed-by:
-
Daniel Vetter authored
For consistency and to encourage more detailed documentation. While doing this also beefed up a few of the comments, linking at least to the setup function. Plus fixed all the hyperlinks. Reviewed-by:
-
Daniel Vetter authored
Since there's very few callers of these I've decided to do them all in one patch. With this the unecessarily long drm_mode_connector_ prefix is gone from the codebase! The only exception being struct drm_mode_connector_set_property, which is part of the uapi so can't be renamed. Again done with sed+some manual fixups for indent issues. Reviewed-by:
-
Daniel Vetter authored
Again to align with the usual prefix of just drm_connector_. Again done with sed + manual fixup for indent issues. Reviewed-by:
-
Daniel Vetter authored
Just makes it longer, and for most things in drm_connector.[hc] we just use the drm_connector_ prefix. Done with sed + a bit of manual fixup for the indenting. Reviewed-by:
-
Daniel Vetter authored
- switch everything over to inline comments - add notes about locking, links to functions and other related stuff - also include a note about Ville's soon-to-be-merged drm_connector_for_each_possible_encoder(). Also check that all the hyperlinks in drm_connector.h work and fix them as needed. Reviewed-by:
-
Daniel Vetter authored
For consistency. Also spelled out the docs for ->best_encoder a bit more while at it. Reviewed-by:
-
Daniel Vetter authored
Last bit the prevented us from starting to delete the drmP.h monster includes from source files! Also add kernel-doc while moving them. A nice consistent drm_dev_ prefix would be cute for these, but since they're used everywhere I've figured I'll leave this bikeshed aside for now. Reviewed-by:
-
Ayan Kumar Halder authored
AFBC is a proprietary lossless image compression protocol and format. It provides fine-grained random access and minimizes the amount of data transferred between IP blocks. AFBC has several features which may be supported and/or used, which are represented using bits in the modifier. Not all combinations are valid, and different devices or use-cases may support different combinations. Changes from v2:- - Added ack by Maarten Lankhorst Signed-off-by:
Rosen Zhelev <rosen.zhelev@arm.com> Signed-off-by:
Brian Starkey <brian.starkey@arm.com> Reviewed-by:
James (Qian) Wang <james.qian.wang@arm.com> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lkml.org/lkml/2018/7/10/360
-
Sean Paul authored
Noticed this while browsing the docs. Reviewed-by:
-
Ville Syrjälä authored
Everything (apart from the actual ->set_config() call) __drm_mode_set_config_internal() does is now useless on atomic drivers. So let's just skip all the foreplay. v2: Use drm_drv_uses_atomic_modeset() (Daniel) Signed-off-by:
-
Ville Syrjälä authored
All the plane->fb/old_fb/crtc dance of __setplane_internal() is pointless on atomic drivers. So let's just introduce a simpler version that skips all that. Ideally we could also skip the __setplane_check() as drm_atomic_plane_check() already checks for everything, but the legacy cursor/"async" .update_plane() tricks bypass that so we still need to call __setplane_check(). Toss in a FIXME to remind someone to clean this up later. v2: Use drm_drv_uses_atomic_modeset() (Daniel) Signed-off-by:
-
Ville Syrjälä authored
Pull all the error checking out from __set_plane_internal() to a helper function. We'll have another user of this soon. Signed-off-by:
-
Hans Verkuil authored
Implement support for this DisplayPort feature. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by:
-
Hans Verkuil authored
Document the Display Port CEC helper functions. Signed-off-by:
-
Hans Verkuil authored
This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a chip that has this capability actually hook up the CEC pin, so even though a CEC device is created, it may not actually work. Signed-off-by:
-
