- 11 Jan, 2019 32 commits
-
-
Daniel Vetter authored
- Move all the legacy gunk at the bottom, and exclude it from kerneldoc. - Documentation for the remaining bits. v2: Fix typo (Sam). Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111164048.29067-5-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Doesn't do anything for atomic drivers. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181217194303.14397-6-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Doesn't do anything for atomic. Signed-off-by:
-
Daniel Vetter authored
It's not a core function, and the matching atomic functions are also not in the core. Plus the suspend/resume helper is also already there. Needs a tiny bit of open-coding, but less midlayer beats that I think. v2: Rebase onto ast (which gained a new user). Cc: Sam Bobroff <sbobroff@linux.ibm.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Sean Paul <sean@poorly.run> Signed-off-by:
-
Linus Walleij authored
The TPO (Toppoly) TPG110 is a pretty generic display driver similar in vein to the Ilitek 93xx devices. It is not a panel per se but a driver used with several low-cost noname panels. This is used on the Nomadik NHK15 combined with a OSD OSD057VA01CT display for WVGA 800x480. The driver is pretty minimalistic right now but can be extended to handle non-default polarities, gamma correction etc. The driver is based on the baked-in code in drivers/video/fbdev/amba-clcd-nomadik.c which will be decomissioned once this us upstream. Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by:
Jagan Teki <jagan@amarulasolutions.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190111175406.27646-1-linus.walleij@linaro.org
-
Paul Kocialkowski authored
When drivers pass non-empty lists of modifiers for initializing their planes, we can infer that they allow framebuffer modifiers and set the driver's allow_fb_modifiers mode config element. In case the allow_fb_modifiers element was not set (some drivers tend to set them after registering planes), the modifiers will still be registered but won't be available to userspace unless the flag is set later. However in that case, the IN_FORMATS blob won't be created. In order to avoid this case and generally reduce the trouble associated with the flag, always set allow_fb_modifiers when a non-empty list of format modifiers is passed at plane init. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> 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/20190104085610.5829-1-paul.kocialkowski@bootlin.com
-
Paul Kocialkowski authored
Despite what the HVS documentation indicates, the VC4 does not actually support SAND tiling modes for any RGB format and only semiplanar YUV420 formats (NV12/NV21) can be used in these tiling modes. The driver currently claims to support RGB formats for the associated modifiers, so remove them from the supported list in the format_mod_supported helper for RGB formats. Remove further checks that are no longer necessary along the way, since semi-planar YUV420 formats support every SAND tiling mode. Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Maxime Ripard authored
drm-next has been forwarded to 5.0-rc1, and we need it to apply the damage helper for dirtyfb series from Noralf Trønnes. Signed-off-by: -
Daniel Vetter authored
Pure drive-by while reading code&docs. Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181012073441.21774-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's a legacy kms only thing, good to hide it better now that all those old drivers use the legacy crtc helpers directly. Reviewed-by:
-
Daniel Vetter authored
The correct way for legacy drivers to update properties that need to do a full modeset, is to do a full modeset. Note that we don't need to call the drm_mode_config_internal helper because we're not changing any of the refcounted paramters. v2: Fixup error handling (Ville). Since the old code didn't bother I decided to just delete it instead of adding even more code for just error handling. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Daniel Vetter authored
The correct way for legacy drivers to update properties that need to do a full modeset, is to do a full modeset. Note that we don't need to call the drm_mode_config_internal helper because we're not changing any of the refcounted paramters. v2: Fixup error handling (Ville). Since the old code didn't bother I decided to just delete it instead of adding even more code for just error handling. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Signed-off-by:
-
Lyude Paul authored
Currently, nouveau uses the yolo method of setting up MST displays: it uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the display configuration. These helpers don't take care to make sure they take a reference to the mstb port that they're checking, and additionally don't actually check whether or not the topology still has enough bandwidth to provide the VCPI tokens required. So, drop usage of the old helpers and move entirely over to the atomic helpers. Changes since v6: * Cleanup atomic check logic and remove a bunch of unneeded checks - danvet Changes since v5: * Update nv50_msto_atomic_check() and nv50_mstc_atomic_check() to the new requirements for drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-21-lyude@redhat.com
-
Lyude Paul authored
It occurred to me that we never actually check this! So let's start doing that. Signed-off-by:
-
Lyude Paul authored
There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking * per-port slot allocation in drm_dp_mst_topology_state instead of * depending on the caller to tell us how many slots to release. */ That's not the only reason we should fix this: forcing the driver to track the VCPI allocations throughout a state's atomic check is error prone, because it means that extra care has to be taken with the order that drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() are called in in order to ensure idempotency. Currently the only driver actually using these helpers, i915, doesn't even do this correctly: multiple ->best_encoder() checks with i915's current implementation would not be idempotent and would over-allocate VCPI slots, something I learned trying to implement fallback retraining in MST. So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for each port. This allows us to ensure idempotency without having to rely on the driver as much. Additionally: the driver doesn't need to do any kind of VCPI slot tracking anymore if it doesn't need it for it's own internal state. Additionally; this adds a new drm_dp_mst_atomic_check() helper which must be used by atomic drivers to perform validity checks for the new VCPI allocations incurred by a state. Also: update the documentation and make it more obvious that these /must/ be called by /all/ atomic drivers supporting MST. Changes since v9: * Add some missing changes that were requested by danvet that I forgot about after I redid all of the kref stuff: * Remove unnecessary state changes in intel_dp_mst_atomic_check * Cleanup atomic check logic for VCPI allocations - all we need to check in compute_config is whether or not this state disables a CRTC, then free VCPI based off that Changes since v8: * Fix compile errors, whoops! Changes since v7: - Don't check for mixed stale/valid VCPI allocations, just rely on connector registration to stop such erroneous modesets Changes since v6: - Keep a kref to all of the ports we have allocations on. This required a good bit of changing to when we call drm_dp_find_vcpi_slots(), mainly that we need to ensure that we only redo VCPI allocations on actual mode or CRTC changes, not crtc_state->active changes. Additionally, we no longer take the registration of the DRM connector for each port into account because so long as we have a kref to the port in the new or previous atomic state, the connector will stay registered. - Use the small changes to drm_dp_put_port() to add even more error checking to make misusage of the helpers more obvious. I added this after having to chase down various use-after-free conditions that started popping up from the new helpers so no one else has to troubleshoot that. - Move some accidental DRM_DEBUG_KMS() calls to DRM_DEBUG_ATOMIC() - Update documentation again, note that find/release() should both not be called on the same port in a single atomic check phase (but multiple calls to one or the other is OK) Changes since v4: - Don't skip the atomic checks for VCPI allocations if no new VCPI allocations happen in a state. This makes the next change I'm about to list here a lot easier to implement. - Don't ignore VCPI allocations on destroyed ports, instead ensure that when ports are destroyed and still have VCPI allocations in the topology state, the only state changes allowed are releasing said ports' VCPI. This prevents a state with a mix of VCPI allocations from destroyed ports, and allocations from valid ports. Changes since v3: - Don't release VCPI allocations in the topology state immediately in drm_dp_atomic_release_vcpi_slots(), instead mark them as 0 and skip over them in drm_dp_mst_duplicate_state(). This makes it so drm_dp_atomic_release_vcpi_slots() is still idempotent while also throwing warnings if the driver messes up it's book keeping and tries to release VCPI slots on a port that doesn't have any pre-existing VCPI allocation - danvet - Change mst_state/state in some debugging messages to "mst state" Changes since v2: - Use kmemdup() for duplicating MST state - danvet - Move port validation out of duplicate state callback - danvet - Handle looping through MST topology states in drm_dp_mst_atomic_check() so the driver doesn't have to do it - Fix documentation in drm_dp_atomic_find_vcpi_slots() - Move the atomic check for each individual topology state into it's own function, reduces indenting - Don't consider "stale" MST ports when calculating the bandwidth requirements. This is needed because originally we relied on the state duplication functions to prune any stale ports from the new state, which would prevent us from incorrectly considering their bandwidth requirements alongside legitimate new payloads. - Add function references in drm_dp_atomic_release_vcpi_slots() - danvet - Annotate atomic VCPI and atomic check functions with __must_check - danvet Changes since v1: - Don't use the now-removed ->atomic_check() for private objects hook, just give drivers a function to call themselves Signed-off-by:Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-19-lyude@redhat.com
-
Lyude Paul authored
Changes since v6: - Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this commit - Document __drm_dp_mst_state_iter_get() and note that it shouldn't be called directly Signed-off-by:
-
Lyude Paul authored
Going through the currently programmed payloads isn't safe without holding mgr->payload_lock, so actually do that and warn if anyone tries calling nv50_msto_payload() in the future without grabbing the right locks. Signed-off-by:
-
Lyude Paul authored
Same as we did for i915, but for nouveau this time. Additionally, we grab a malloc reference to the port that lasts for the entire lifetime of nv50_mstc, which gives us the guarantee that mstc->port will always point to valid memory for as long as the mstc stays around. Signed-off-by:
-
Lyude Paul authored
Now that we finally have a sane way to keep port allocations around, use it to fix the potential unchecked ->port accesses that nouveau makes by making sure we keep the mst port allocated for as long as it's drm_connector is accessible. Additionally, now that we've guaranteed that mstc->port is allocated for as long as we keep mstc around we can remove the connector registration checks for codepaths which release payloads, allowing us to release payloads on active topologies properly. These registration checks were only required before in order to avoid situations where mstc->port could technically be pointing at freed memory. Signed-off-by:
-
Lyude Paul authored
There is no need to look at the port's VCPI allocation before calling drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let us avoid cleaning up an msto more then once. The DP MST core will never call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what these checks are meant to protect against. More importantly though, we're about to stop clearing mstc->port in the next commit, which means if we could potentially hit a use-after-free error if we tried to check mstc->port->vcpi here. So to make life easier for anyone who bisects this code in the future, use msto->disabled instead to check whether or not we need to deallocate VCPI instead. Signed-off-by:
-
Lyude Paul authored
Trying to destroy the connector using mstc->connector.funcs->destroy() if connector initialization fails is wrong: there is no possible codepath in nv50_mstc_new where nv50_mstm_add_connector() would return <0 and mstc would be non-NULL. Signed-off-by:
-
Lyude Paul authored
Just like i915 and nouveau, it's a good idea for us to hold a malloc reference to the port here so that we never pass a freed pointer to any of the DP MST helper functions. Also, we stop unsetting aconnector->port in dm_dp_destroy_mst_connector(). There's literally no point to that assignment that I can see anyway. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-12-lyude@redhat.com
-
Lyude Paul authored
So that the ports stay around until we've destroyed the connectors, in order to ensure that we don't pass an invalid pointer to any MST helpers once we introduce the new MST VCPI helpers. Changes since v1: * Move drm_dp_mst_get_port_malloc() to where we assign intel_connector->port - danvet Signed-off-by:
-
Lyude Paul authored
Up until now, freeing payloads on remote MST hubs that just had ports removed has almost never worked because we've been relying on port validation in order to stop us from accessing ports that have already been freed from memory, but ports which need their payloads released due to being removed will never be a valid part of the topology after they've been removed. Since we've introduced malloc refs, we can replace all of the validation logic in payload helpers which are used for deallocation with some well-placed malloc krefs. This ensures that regardless of whether or not the ports are still valid and in the topology, any port which has an allocated payload will remain allocated in memory until it's payloads have been removed - finally allowing us to actually release said payloads correctly. Signed-off-by:
-
Lyude Paul authored
This has never actually worked, and isn't needed anyway: the driver's always going to try to deallocate VCPI when it tears down the display that the VCPI belongs to. Signed-off-by:
-
Lyude Paul authored
While this isn't a complete fix, this will improve the reliability of drm_dp_get_last_connected_port_and_mstb() pretty significantly during hotplug events, since there's a chance that the in-memory topology tree may not be fully updated when drm_dp_get_last_connected_port_and_mstb() is called and thus might end up causing our search to fail on an mstb whose topology refcount has reached 0, but has not yet been removed from it's parent. Ideally, we should further fix this problem by ensuring that we deal with the potential for racing with a hotplug event, which would look like this: * drm_dp_payload_send_msg() retrieves the last living relative of mstb with drm_dp_get_last_connected_port_and_mstb() * drm_dp_payload_send_msg() starts building payload message At the same time, mstb gets unplugged from the topology and is no longer the actual last living relative of the original mstb * drm_dp_payload_send_msg() tries sending the payload message, hub times out * Hub timed out, we give up and run away-resulting in the payload being leaked This could be fixed by restarting the drm_dp_get_last_connected_port_and_mstb() search whenever we get a timeout, sending the payload to the new mstb, then repeating until either the entire topology is removed from the system or drm_dp_get_last_connected_port_and_mstb() fails. But since the above race condition is not terribly likely, we'll address that in a later patch series once we've improved the recovery handling for VCPI allocations in the rest of the DP MST helpers. Changes since v1: * Convert kerneldoc for drm_dp_get_last_connected_port_and_mstb to normal comment - danvet Signed-off-by:
-
Lyude Paul authored
The current way of handling refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The intended purpose behind this is so that we can avoid problems like not being able to free a remote payload that might still be active, due to us having removed all of the port/branch device structures in memory, as per: commit 91a25e46 ("drm/dp/mst: deallocate payload on port destruction") Which may have worked, but then it caused use-after-free errors. Being new to MST at the time, I tried fixing it; commit 263efde3 ("drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()") But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs are validated in almost every DP MST helper function. Simply put, this means we go through the topology and try to see if the given drm_dp_mst_branch or drm_dp_mst_port is still attached to something before trying to use it in order to avoid dereferencing freed memory (something that has happened a LOT in the past with this library). Because of this it doesn't actually matter whether or not we keep keep the ports and branches around in memory as that's not enough, because any function that validates the branches and ports passed to it will still reject them anyway since they're no longer in the topology structure. So, use-after-free errors were fixed but payload deallocation was completely broken. Two years later, AMD informed me about this issue and I attempted to come up with a temporary fix, pending a long-overdue cleanup of this library: commit c54c7374 ("drm/dp_mst: Skip validating ports during destruction, just ref") But then that introduced use-after-free errors, so I quickly reverted it: commit 9765635b ("Revert "drm/dp_mst: Skip validating ports during destruction, just ref"") And in the process, learned that there is just no simple fix for this: the design is just broken. Unfortunately, the usage of these helpers are quite broken as well. Some drivers like i915 have been smart enough to avoid accessing any kind of information from MST port structures, but others like nouveau have assumed, understandably so, that drm_dp_mst_port structures are normal and can just be accessed at any time without worrying about use-after-free errors. After a lot of discussion, me and Daniel Vetter came up with a better idea to replace all of this. To summarize, since this is documented far more indepth in the documentation this patch introduces, we make it so that drm_dp_mst_port and drm_dp_mst_branch structures have two different classes of refcounts: topology_kref, and malloc_kref. topology_kref corresponds to the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's given topology. Once it hits zero, any associated connectors are removed and the branch or port can no longer be validated. malloc_kref corresponds to the lifetime of the memory allocation for the actual structure, and will always be non-zero so long as the topology_kref is non-zero. This gives us a way to allow callers to hold onto port and branch device structures past their topology lifetime, and dramatically simplifies the lifetimes of both structures. This also finally fixes the port deallocation problem, properly. Additionally: since this now means that we can keep ports and branch devices allocated in memory for however long we need, we no longer need a significant amount of the port validation that we currently do. Additionally, there is one last scenario that this fixes, which couldn't have been fixed properly beforehand: - CPU1 unrefs port from topology (refcount 1->0) - CPU2 refs port in topology(refcount 0->1) Since we now can guarantee memory safety for ports and branches as-needed, we also can make our main reference counting functions fix this problem by using kref_get_unless_zero() internally so that topology refcounts can only ever reach 0 once. Changes since v4: * Change the kernel-figure summary for dp-mst/topology-figure-1.dot a bit - danvet * Remove figure numbers - danvet Changes since v3: * Remove rebase detritus - danvet * Split out purely style changes into separate patches - hwentlan Changes since v2: * Fix commit message - checkpatch * s/)-1/) - 1/g - checkpatch Changes since v1: * Remove forward declarations - danvet * Move "Branch device and port refcounting" section from documentation into kernel-doc comments - danvet * Export internal topology lifetime functions into their own section in the kernel-docs - danvet * s/@/&/g for struct references in kernel-docs - danvet * Drop the "when they are no longer being used" bits from the kernel docs - danvet * Modify diagrams to show how the DRM driver interacts with the topology and payloads - danvet * Make suggested documentation changes for drm_dp_mst_topology_get_mstb() and drm_dp_mst_topology_get_port() - danvet * Better explain the relationship between malloc refs and topology krefs in the documentation for drm_dp_mst_topology_get_port() and drm_dp_mst_topology_get_mstb() - danvet * Fix "See also" in drm_dp_mst_topology_get_mstb() - danvet * Rename drm_dp_mst_topology_get_(port|mstb)() -> drm_dp_mst_topology_try_get_(port|mstb)() and drm_dp_mst_topology_ref_(port|mstb)() -> drm_dp_mst_topology_get_(port|mstb)() - danvet * s/should/must in docs - danvet * WARN_ON(refcount == 0) in topology_get_(mstb|port) - danvet * Move kdocs for mstb/port structs inline - danvet * Split drm_dp_get_last_connected_port_and_mstb() changes into their own commit - danvet Signed-off-by:
-
Lyude Paul authored
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/ s/drm_dp_put_port/drm_dp_mst_topology_put_port/ s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/ s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/ This is a much more consistent naming scheme, and will make even more sense once we redesign how the current refcounting scheme here works. Signed-off-by:
-
Lyude Paul authored
Split some stuff across multiple lines Signed-off-by:
-
Lyude Paul authored
Fix some indenting, split some stuff across multiple lines. Signed-off-by:
-
Lyude Paul authored
Split some stuff across multiple lines, remove some unnecessary braces Signed-off-by:
-
Lyude Paul authored
Reindent some stuff, and split some stuff across multiple lines so we aren't going over the text width limit. Signed-off-by:
-
- 10 Jan, 2019 8 commits
-
-
Daniele Castagna authored
Add the KMS plane rotation property to the DRM rockchip driver, for SoCs RK3328, RK3368 and RK3399. RK3288 only supports rotation at the display level (i.e. CRTC), but for now we are only interested in plane rotation. This commit only adds support for the value of reflect-y and reflect-x (i.e. mirroring). Note that y-mirroring is not compatible with YUV. The following modetest commands would test this feature, where 30 is the plane ID, and 49 = rotate_0 + relect_y + reflect_x. X mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:17 Y mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:33 XY mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:49 Signed-off-by:
Daniele Castagna <dcastagna@chromium.org> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190109185639.5093-4-ezequiel@collabora.com
-
Ezequiel Garcia authored
This commit splits the registers for RK3288 from those for RK3328, RK3368 and RK3399. It seems RK3288 does not support plane x-y-mirroring, and so in order to support this for the other SoCs, we need to have separate set of registers for win0 and win1. Signed-off-by:
-
Ezequiel Garcia authored
Fix a small typo in the macros VOP argument. The macro argument is currently wrongly named "x", and then never used. The code built fine almost by accident, as the macros are always used in a context where a proper "vop" symbol exists. This fix is almost cosmetic, as the resulting code shouldn't change. Signed-off-by:
-
Daniele Castagna authored
Currently, YUV hardware overlays are converted to RGB using a color space conversion different than BT.601. The result is that colors of e.g. NV12 buffers don't match colors of YUV hardware overlays. In order to fix this, enable YUV2YUV and set appropriate coefficients for formats such as NV12 to be displayed correctly. This commit was tested using modetest, gstreamer and chromeos (hardware accelerated video playback). Before the commit, tests rendering with NV12 format resulted in colors not displayed correctly. Test examples (Tested on RK3399 and RK3288 boards connected to HDMI monitor): $ modetest 39@32:1920x1080@NV12 $ gst-launch-1.0 videotestrc ! video/x-raw,format=NV12 ! kmssink Signed-off-by:
-
Enric Balletbo i Serra authored
Add support to async updates of cursors by using the new atomic interface for that. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> [updated for upstream] Signed-off-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
https://github.com/jsarha/linuxDave Airlie authored
tilcdc pull request for Linux v4.22 Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Jyri Sarha <jsarha@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/cdf82a00-4e40-20a6-cc7d-3278dc23473e@ti.com
-
Shayenne Moura authored
This patch adjust the print string of drm_display_mode object to remove drm_mode_object dependency in msm files. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Shayenne Moura <shayenneluzmoura@gmail.com> Signed-off-by:
-
Linus Walleij authored
The following happened when migrating an old fbdev driver to DRM: The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555 or XRGB1555/XBGR1555 i.e. the maximum depth is 15. This makes the initialization of the framebuffer fail since the code in drm_fb_helper_single_fb_probe() assigns the same value to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes a 1-to-1 mapping between BPP and depth, which is true in most cases but not for this hardware that only support odd formats. To support the odd case of a driver supporting 16BPP with only 15 bits of depth, this patch will make the code loop over the formats supported on the primary plane on each CRTC managed by the FB helper and cap the depth to the maximum supported on any primary plane. On the PL110 Integrator, this makes drm_mode_legacy_fb_format() select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and thus we get framebuffer, penguin and console on the Integrator/CP. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
