- 18 Jul, 2018 3 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-3-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
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 <tzimmermann@suse.de> 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:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180717122522.11327-1-paul.kocialkowski@bootlin.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:
-
- 16 Jul, 2018 5 commits
-
-
Lyude Paul authored
Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180716171711.413-1-lyude@redhat.com
-
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 23 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:
-
Noralf Trønnes authored
This fixes a static checker warning: drivers/gpu/drm/drm_client.c:289 drm_client_buffer_create() error: double free of 'buffer' Extend drm_client_buffer_delete() to handle the case when there's no dumb buffer attached and drop the extra kfree. Fixes: c76f0f7c ("drm: Begin an API for in-kernel clients") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> 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:
Benjamin Gaignard <benjamin.gaignard@linaro.org> 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:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
-
- 12 Jul, 2018 4 commits
-
-
Arnd Bergmann authored
This tinydrm driver fails to link without the backlight support: drivers/gpu/drm/tinydrm/ili9341.o: In function `ili9341_probe': ili9341.c:(.text+0x578): undefined reference to `devm_of_find_backlight' Fixes: 3fa0e8f6 ("drm/tinydrm: new driver for ILI9341 display panels") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180709152106.990066-1-arnd@arndb.de
-
Maxime Ripard authored
When commit af11942e ("drm/sun4i: tcon-top: Cleanup clock handling") was merged, the error handling path of the of_property_match_string was changed to take into account the fact that the returned value of that function wasn't an error pointer but an error code. Unfortunately, this introduced a warning since the now returned value is an integer, while the sun8i_tcon_top_register_gate function should return an error pointer. Fix that by calling ERR_PTR. Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Chen-Yu Tsai <wens@csie.org> Fixes: af11942e ("drm/sun4i: tcon-top: Cleanup clock handling") Reviewed-by:
kbuild test robot <lkp@intel.com> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Jernej Skrabec authored
Initial implementation of DE2 planes only supported fixed zpos. Expand implementation with configurable zpos property. Implementation background: Channel in DE2 driver represents one DRM plane, whereas pipe is just mapped channel to known Z position. Pipe 0 will always be at the bottom, pipe 1 just above pipe 0 and so on. If, for example, channel 1 is mapped at pipe 0 and channel 0 at pipe 1, whatever is on channel 0 will appear on top. Before this commit, channel id was used for addressing channel related registers (prefixed with SUN8I_MIXER_CHAN_UI_ or SUN8I_MIXER_CHAN_VI_) and pipe registers (prefixed with SUN8I_MIXER_BLEND_). Additionally, register SUN8I_MIXER_BLEND_ROUTE, which takes care for mapping channels to pipes had fixed value. It mapped channel 0 to pipe 0, 1 to 1 and so on. Consequence of all that was fixed Z order of planes. With this commit, pipe registers are using zpos property as index and channel related registers still use channel id as index. Pipe mapping register is now set dynamically too and pipe enable register is rebuild every time to make sure only active pipes are enabled. Testing was done to confirm that there is no issues if bottom plane contains pixels with alpha value < 0xff and if it doesn't whole screen. Tested-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Rodrigo Siqueira authored
This patch appends the minimum helpers related to framebuffer and plane to make vkms minimally usable. Changes since V1: - None Changes since V2: - Squash "Add plane helper struct" and "Add helper for framebuffer create" Changes since V3: Daniel Vetter: - Remove atomic_check from plane helper Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by:
-
