- 09 Dec, 2019 14 commits
-
-
Sam Ravnborg authored
Today the bridge creates the drm_connector, but that is planned to be moved to the display drivers. To facilitate this, update drm_panel_funcs.get_modes() to take drm_connector as an argument. All panel drivers implementing get_modes() are updated. v2: - drop accidental change (Laurent) - update docs for get_modes (Laurent) Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Stefan Mavrodiev <stefan@olimex.com> Cc: Robert Chiras <robert.chiras@nxp.com> Cc: "Guido Günther" <agx@sigxcpu.org> Cc: Purism Kernel Team <kernel@puri.sm> Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-6-sam@ravnborg.org
-
Sam Ravnborg authored
The drm_connector created by drm_panel_bridge was accessed via drm_panel.connector. Avoid the detour around drm_panel by providing a simple get method. This avoids direct access to the connector field in drm_panel in the two users. The change is done in preparation for removal of drm_panel.connector. Update pl111 and tve200 to use the new helper. Signed-off-by:
-
Sam Ravnborg authored
Use drm_panel infrastructure for backlight. Replace direct calls with drm_panel_*() calls to utilize the drm_panel support. Signed-off-by:
-
Sam Ravnborg authored
Panels often support backlight as specified in a device tree. Update the drm_panel infrastructure to support this to simplify the drivers. With this the panel driver just needs to add the following to the probe() function: err = drm_panel_of_backlight(panel); if (err) return err; Then drm_panel will handle all the rest. There is one caveat with the backlight support. If drm_panel_(enable|disable) are called multiple times in a row then backlight_(enable|disable) will be called multiple times. The above will happen when a panel drivers unconditionally calls drm_panel_disable() in their shutdown() function, whan the panel is already disabled and then shutdown() is called. Reading the backlight code it seems safe to call the backlight_(enable|disable) several times. v3: - Improve comments, fix grammar (Laurent) - Do not fail in drm_panel_of_backlight() if no DT support (Laurent) - Log if backlight_(enable|disable) fails (Laurent) - Improve drm_panel_of_backlight() docs - Updated changelog with backlight analysis (triggered by Laurent) v2: - Drop test of CONFIG_DRM_PANEL in header-file (Laurent) - do not enable backlight if ->enable() returns an error Signed-off-by: -
Sam Ravnborg authored
The callbacks in drm_panel_funcs are optional, so do not return an error just because no callback is assigned. v2: - Document what functions in drm_panel_funcs are optional (Laurent) - Return -EOPNOTSUPP if get_modes() is not assigned (Laurent) (Sam: -EOPNOTSUPP seems to best error code in this situation) Signed-off-by:
-
Chuhong Yuan authored
oaktrail_lvds_mode_set() misses a gma_power_end() in an error path. Add the call to fix it. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191209085747.16057-1-hslester96@gmail.com
-
Jani Nikula authored
Now that the fbops member of struct fb_info is const, we can start making the ops const as well. v2: fix typo (Christophe de Dinechin) Cc: Bruno Prémont <bonbons@linux-vserver.org> Cc: linux-input@vger.kernel.org Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Bruno Prémont <bonbons@linux-vserver.org> Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f415010cd52cce7d8a1250d4eca582ec64e67956.1575390741.git.jani.nikula@intel.com
-
Boris Brezillon authored
The [pre_]enable/[post_]disable hooks are passed the old atomic state. Update the doc and rename the arguments to make it clear. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-8-boris.brezillon@collabora.com
-
Boris Brezillon authored
The drm_bridge_get_prev_bridge() helper will be useful for bridge drivers that want to do bus format negotiation with their neighbours. Signed-off-by:
-
Boris Brezillon authored
To iterate over all bridges attached to a specific encoder. Suggested-by:
-
Boris Brezillon authored
So that each element in the chain can easily access its predecessor. This will be needed to support bus format negotiation between elements of the bridge chain. Signed-off-by:
-
Boris Brezillon authored
We are about to replace the single-linked bridge list by a double-linked one based on list.h, leading to the suppression of the encoder->bridge field. But before we can do that we must provide a drm_bridge_chain_get_first_bridge() bridge helper and patch all drivers and core helpers to use it instead of directly accessing encoder->bridge. Note that we still have 2 drivers (VC4 and Exynos) manipulating the encoder->bridge field directly because they need to cut the bridge chain in order to control the enable/disable sequence. This is definitely not something we want to encourage, so let's keep those 2 oddities around until we find a better solution. Signed-off-by:
-
Boris Brezillon authored
And use it in drivers accessing the bridge->next field directly. This is part of our attempt to make the bridge chain a double-linked list based on the generic list helpers. Signed-off-by:
-
Boris Brezillon authored
Change the prefix of bridge helpers targeting a bridge chain from drm_bridge_ to drm_bridge_chain_ to better reflect the fact that the operation will happen on all elements of chain, starting at the bridge passed in argument. Signed-off-by:
-
- 06 Dec, 2019 13 commits
-
-
Wayne Lin authored
[Why] This patch is trying to address the issue observed when hotplug DP daisy chain monitors. e.g. src-mstb-mstb-sst -> src (unplug) mstb-mstb-sst -> src-mstb-mstb-sst (plug in again) Once unplug a DP MST capable device, driver will call drm_dp_mst_topology_mgr_set_mst() to disable MST. In this function, it cleans data of topology manager while disabling mst_state. However, it doesn't clean up the proposed_vcpis of topology manager. If proposed_vcpi is not reset, once plug in MST daisy chain monitors later, code will fail at checking port validation while trying to allocate payloads. When MST capable device is plugged in again and try to allocate payloads by calling drm_dp_update_payload_part1(), this function will iterate over all proposed virtual channels to see if any proposed VCPI's num_slots is greater than 0. If any proposed VCPI's num_slots is greater than 0 and the port which the specific virtual channel directed to is not in the topology, code then fails at the port validation. Since there are stale VCPI allocations from the previous topology enablement in proposed_vcpi[], code will fail at port validation and reurn EINVAL. [How] Clean up the data of stale proposed_vcpi[] and reset mgr->proposed_vcpis to NULL while disabling mst in drm_dp_mst_topology_mgr_set_mst(). Changes since v1: *Add on more details in commit message to describe the issue which the patch is trying to fix Signed-off-by:
Wayne Lin <Wayne.Lin@amd.com> [added cc to stable] Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191205090043.7580-1-Wayne.Lin@amd.com Cc: <stable@vger.kernel.org> # v3.17+
-
Robin Murphy authored
When we have devfreq, also try to register a basic cooling device in case GPU workloads manage to hit thermal throttling thresholds. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/21f228099321f460d62e0ab7c77b2d2213dd4da8.1574974319.git.robin.murphy@arm.com
-
Thomas Zimmermann authored
The field lost_pixels in struct udl_device was supposed to signal an error during USB transfers of the framebuffer data. The driver would have to schedule a re-transfer at a later point. This code was never implemented. Remove lost_pixels and return regular error codes instead. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191206085954.9697-8-tzimmermann@suse.de
-
Thomas Zimmermann authored
The damage-handler code now invokes dma_buf_{begin,end}_access() for imported buffers. These calls were missing from the page-flip and modesetting code paths. The patch also fixes an bug in the original where an error code was overwritten by the result of dma_buf_end_cpu_access(). v2: * only return an error code from dma_buf_end_cpu_access() if no other error code has been set before Signed-off-by: -
Thomas Zimmermann authored
Computing the cpp value's logarithm in a separate helper function makes the damage-handler code more readable. Signed-off-by:
-
Thomas Zimmermann authored
Computing the clip rectable in a separate helper function makes the damage-handler code more readable. Signed-off-by:
-
Thomas Zimmermann authored
We now do the fast tests before the potentially expensive vmap operation. Signed-off-by:
-
Thomas Zimmermann authored
A call to udl_render_hline() returns the number of identical and sent pixels. None of these values is used. Remove the parameters. Signed-off-by:
-
Thomas Zimmermann authored
None of the udl driver's statistics counters is used anywhere. Remove them. Signed-off-by:
-
Gerd Hoffmann authored
Use the shared address space of the drm device (see drm_open() in drm_file.c) for dma-bufs too. That removes a difference betweem drm device mmap vmas and dma-buf mmap vmas and fixes corner cases like dropping ptes (using madvise(DONTNEED) for example) not working properly. Also remove amdgpu driver's private dmabuf update. It is not needed any more now that we are doing this for everybody. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191127092523.5620-3-kraxel@redhat.com
-
Gerd Hoffmann authored
The fake offset is going to stay, so change the calling convention for drm_gem_object_funcs.mmap to include the fake offset. Update all users accordingly. Note that this reverts 83b8a6f2 ("drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap") and on top then adds the fake offset to drm_gem_prime_mmap to make sure all paths leading to obj->funcs->mmap are consistent. v3: move fake-offset tweak in drm_gem_prime_mmap() so we have this code only once in the function (Rob Herring). Fixes: 83b8a6f2 ("drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rob Herring <robh@kernel.org> Signed-off-by:
-
Rodrigo Siqueira authored
FEC is supported since DP 1.4, and it was expanded for LT-tunable in DP 1.4a. This commit adds the address registers for FEC_ERROR_COUNT_PHY_REPEATER1 and FEC_CAPABILITY_PHY_REPEATER1. Cc: Abdoulaye Berthe <Abdoulaye.Berthe@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Abdoulaye Berthe <Abdoulaye.Berthe@amd.com> Signed-off-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by:
Zhan Liu <zhan.liu@amd.com> Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191205135856.232784-1-Rodrigo.Siqueira@amd.com
-
Rodrigo Siqueira authored
Commit d7cd0e05 introduced a change at DP_DSC_THROUGHPUT_MODE_0_170 which is not aligned with the spec. This commit replace 15 << 4 by 15 << 0 for DP_DSC_THROUGHPUT_MODE_0_170 in order to make it follow the specification. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Nikola Cornij <nikola.cornij@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
- 05 Dec, 2019 13 commits
-
-
Gabriela Bittencourt authored
Fix typo in word 'blend' and in the word 'destination' and change preposition 'at' to 'of' in function 'blend' documentation. And change the task introduction word 'Todo' for the word all in uppercase - 'TODO'. With the TODO word all in uppercase (as it's the standard) it's easier to find the tasks that have to be done throughout the code. Changes since V3: Rodrigo: - Merge the patch series into a single patch since it contains one single logical change Changes since V2: - Add fix typo in word 'destination' - Add change of the preposition - Fix the name of the function in log message - Add the change in word 'Todo' Reviewed-by:
Gabriela Bittencourt <gabrielabittencourt00@gmail.com> Signed-off-by:
-
Gabriela Bittencourt authored
Add a description on VKMS module and the cases in which it should be used. There's a brief explanation on how to set it and use it in a VM, along with an example of running an igt-test. Changes since V3: Rodrigo: - Change the log message to imperative - Fix some bad spelling/writing - Add a blank line before enumeration Changes since V2: Andre: - Avoid repetition of words in the same sentence; - Make the explanation on 'setting the kernel' shorter, eliminate the 'make menuconfig' command; - Add tab on enumeration to have one line per item; - Clarify from each machine igt-tests commands should be ran on. Reviewed-by:
-
Sean Paul authored
It seems that on certain MST hubs, namely the CableMatters USB-C 2x DP hub, using the DP_PAYLOAD_ALLOCATE_SET and DP_PAYLOAD_TABLE_UPDATE_STATUS register ranges to clear any pre-existing payload allocations on the hub isn't always enough to reset things if the source device has been reset unexpectedly. Or at least, that's the current running theory. The precise behavior appears to be that when the source device gets reset unexpectedly, the hub begins reporting an available_pbn value of 0 for all of its ports. This is a bit inconsistent with the our theory, since this seems to happen even if previously set PBN allocations should have resulted in a non-zero available_pbn value. So, it's possible that something else may be going on here. Strangely though, sending a CLEAR_PAYLOAD_ID_TABLE broadcast request when initializing the MST topology seems to bring things into working order and make available_pbn work again. Since this is a pretty safe solution, let's go ahead and implement it. Changes since v1: * Change indenting on drm_dp_send_clear_payload_id_table() prototype * Remove some braces in drm_dp_send_clear_payload_id_table() * Reorganize some variable declarations in drm_dp_send_clear_payload_id_table() * Don't forget to handle DP_CLEAR_PAYLOAD_ID_TABLE in drm_dp_sideband_parse_reply() * Move drm_dp_send_clear_payload_id_table() call into drm_dp_mst_link_probe_work(), since we can't send sideband messages while under lock in drm_dp_mst_topology_mgr_set_mst() * Change commit message Acked-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Thomas Zimmermann authored
The behavior of MGA G200 SE depends on the rev id. Print the id when debugging is enabled. Signed-off-by:
-
Thomas Zimmermann authored
The load/unload callbacks in struct drm_driver are deprecated. Remove them and call functions explicitly. Signed-off-by:
-
Thomas Zimmermann authored
The load/unload callbacks in struct drm_driver are deprecated. Remove them and call functions explicitly. Signed-off-by:
-
Jani Nikula authored
Now that the fbops member of struct fb_info is const, we can start making the ops const as well. This does not cover all drivers; some actually modify the fbops struct, for example to adjust for different configurations, and others do more involved things that I'd rather not touch in practically obsolete drivers. Mostly this is the low hanging fruit where we can add "const" and be done with it. v3: - un-constify atyfb, mb862xx, nvidia and uvesabf (0day) v2: - fix typo (Christophe de Dinechin) - use "static const" instead of "const static" in mx3fb.c - also constify smscufx.c Cc: linux-fbdev@vger.kernel.org Reviewed-by:
-
Jani Nikula authored
Use const for fb_ops to let us make the fbops struct const in the future. Cc: linux-fbdev@vger.kernel.org Reviewed-by:
-
Jani Nikula authored
Now that the fbops member of struct fb_info is const, we can start making the ops const as well. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Jani Nikula authored
Now that we no longer modify the fbops, or hold non-const pointers to it, we can make it const. After this, we can start making the fbops const all over the place. 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
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
Avoid modifying the fb_ops via info->fbops to let us make the pointer const in the future. Drop the unnecessary EXPORT_SYMBOL() while at it. Cc: linux-fbdev@vger.kernel.org Reviewed-by:
-
