- 13 Aug, 2020 1 commit
-
-
Tian Tao authored
Add missing include to fix build error: hibmc_drm_drv.c:385:1: warning: data definition has no type or storage class [enabled by default] hibmc_drm_drv.c:385:1: error: type defaults to ‘int’ in declaration of ‘module_init’ [-Werror=implicit-int] hibmc_drm_drv.c:385:1: warning: parameter names (without types) in function of ‘module_exit’ [-Werror=implicit-int] hibmc_drm_drv.c:385:292:1: warning: parameter names (without types) in function declaration [enabled by default] Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1597289955-27381-1-git-send-email-tiantao6@hisilicon.com
-
- 12 Aug, 2020 10 commits
-
-
Marek Vasut authored
Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived from tc358764 driver and panel-raspberrypi-touchscreen. This driver is meant to replace the panel-raspberrypi-touchscreen too, as the bridge connection can be described in DT too. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: dri-devel@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Sam Ravnborg <sam.ravnborg@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200809105705.6334-2-marex@denx.de
-
Marek Vasut authored
Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this one is used in the Raspberry Pi 7" touchscreen display unit. Signed-off-by:
Rob Herring <robh@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by:
-
Thomas Zimmermann authored
Backmerging drm-next into drm-misc-next for nouveau and panel updates. Resolves a conflict between ttm and nouveau, where struct ttm_mem_res got renamed to struct ttm_resource. Signed-off-by: -
Christian König authored
The object flags created in radeon_ttm_placement_from_domain take care that we use the correct caching for AGP, this is just superflous. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/384336/?series=80346&rev=1
-
Christian König authored
This is a separate object we work within TTM. Signed-off-by:
-
Christian König authored
The names get/put are associated with reference counting in the Linux kernel, use alloc/free instead. Signed-off-by:
-
Tian Tao authored
The memory used to be allocated with devres helpers and released automatically. In rare circumstances, the memory's release could have happened before the DRM device got released, which would have caused memory corruption of some kind. Now we're embedding the data structures in struct hibmc_drm_private. The whole release problem has been resolved, because struct hibmc_drm_private is allocated with drmm_kzalloc and always released with the DRM device. Signed-off-by:
-
Tian Tao authored
Remove some unused include statements. Signed-off-by:
-
Christian König authored
This reverts commit 2ddef176. As it turned out VMWGFX needs a much wider audit to fix this. Signed-off-by:
-
git://people.freedesktop.org/~sroland/linuxDave Airlie authored
The drm_mode_config_reset patches are very important fixing a recently introduced kernel crash, the others fix various older issues which are a bit less serious in practice. Signed-off-by:
-
- 11 Aug, 2020 18 commits
-
-
Linus Walleij authored
In order to successfully read ID of the MTP panel the panel MTP control page must be unlocked. Previously this wasn't encountered because in the setup with this panel the power wasn't ever really dropped. When power gets dropped from the panel, MTP needs to be unlocked. Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Cc: newbytee@protonmail.com Cc: Stephan Gerhold <stephan@gerhold.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200808224322.1507713-1-linus.walleij@linaro.org
-
Oleg Vasilev authored
Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Display Core already has the subconnector information, we only need to expose it through DRM property. v2:rebase v3: renamed a function call Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: David (ChunMing) Zhou <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by:
Jeevan B <jeevan.b@intel.com> Signed-off-by:
Oleg Vasilev <oleg.vasilev@intel.com> Tested-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1587732655-17544-5-git-send-email-jeevan.b@intel.com
-
Oleg Vasilev authored
Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: rebase v3: renamed a function call Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: David (ChunMing) Zhou <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
-
Oleg Vasilev authored
Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: updates to match previous commit changes v3: rebase v4: renamed a function call Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
-
Oleg Vasilev authored
Currently, downstream port type is only reported in debugfs. This information should be considered important since it reflects the actual physical connector type. Some userspace (e.g. window compositors) may want to show this info to a user. The 'subconnector' property is already utilized for DVI-I and TV-out for reporting connector subtype. The initial motivation for this feature came from i2c test [1]. It is supposed to be skipped on VGA connectors, but it cannot detect VGA over DP and fails instead. v2: - Ville: utilized drm_dp_is_branch() - Ville: implement DP 1.0 downstream type info - Replaced create_dp_properties with add_dp_subconnector_property - Added dp_set_subconnector_property helper v4: - Ville: add DP1.0 best assumption about subconnector - Ville: assume DVI is DVI-D - Ville: reuse Writeback enum value for Virtual subconnector - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort v5: rebase v6: - Jani Nikula: renamed a function name - Jani Nikula: addressed the issues with documentation [1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-fixes-5.9-2020-08-07: amdgpu: - Re-add spelling typo fix - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes - SMU i2c fix - Power fixes Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
* backmerge from drm-fixes at v5.8-rc7 * add orientation quirk for ASUS T103HAF * drm/omap: force runtime PM suspend on system suspend * drm/tidss: fix modeset init for DPI panels * re-added docs for drm_gem_flink_ioctl() * ttm: fix page-offset calculation within TTM Signed-off-by:
-
Dave Airlie authored
I need to backmerge 5.8 as I've got a bunch of fixes sitting on an rc7 base that I want to land. Signed-off-by: -
Dave Airlie authored
I fixed the init path, but missed the cleanup path. Fixes: e0830704 ("drm/vmwgfx: takedown vram manager") Reviewed-by:
-
Colin Ian King authored
There is a spelling mistake in a DRM_ERROR message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Roland Scheidegger <sroland@vmware.com>
-
Colin Ian King authored
There is a spelling mistake in a DRM_ERROR message. Fix it. Signed-off-by:
-
Roland Scheidegger authored
Same problem as in stdu, same fix. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Acked-by:
Charmaine Lee <charmainel@vmware.com> Reviewed-by:
Zack Rusin <zackr@vmware.com> Signed-off-by:
-
Roland Scheidegger authored
Same problem as in stdu, same fix. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Acked-by:
-
Daniel Vetter authored
When converting to atomic the state reset was done by directly calling the functions, and before the modeset object was fully initialized. This means the various ->dev pointers weren't set up. After commit 51f644b4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 12 18:00:49 2020 +0200 drm/atomic-helper: reset vblank on crtc reset this started to oops because now we're trying to derefence drm_crtc->dev. Fix this up by entirely switching over to drm_mode_config_reset, called once everything is set up. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Reported-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Tested-by:
-
Dan Carpenter authored
These if statements are supposed to be true if we ended the list_for_each_entry() loops without hitting a break statement but they don't work. In the first loop, we increment "i" after the "if (i == unit)" condition so we don't necessarily know that "i" is not equal to unit at the end of the loop. In the second loop we exit when mode is not pointing to a valid drm_display_mode struct so it doesn't make sense to check "mode->type". Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Dan Carpenter authored
The "entry" pointer is an offset from the list head and it doesn't point to a valid vmw_legacy_display_unit struct. Presumably the intent was to point to the last entry. Also the "i++" wasn't used so I have removed that as well. Fixes: d7e1958d ("drm/vmwgfx: Support older hardware.") Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2020-08-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next-fixes for v5.9-rc1: - Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi - Fix a fbcon OOB read in fbdev, found by syzbot. - Mark vga_tryget static as it's not used elsewhere. - Small fixes to xlnx. - Remove null check for kfree in drm_dev_release. - Fix DRM_FORMAT_MOD_AMLOGIC_FBC definition. - Fix mode initialization in omap_connector_mode_valid(). Signed-off-by:
-
- 10 Aug, 2020 9 commits
-
-
Vinay Simha BN authored
This driver is tested with two panels individually with Apq8016-IFC6309 board https://www.inforcecomputing.com/products/single-board-computers-sbc/qualcomm-snapdragon-410-inforce-6309-micro-sbc 1. 1366x768@60 auo,b101xtn01 data-mapping = "jeida-24" 2. 800x480@60 innolux,at070tn92 data-mapping = "vesa-24" - power off sequence in proper order - put_unaligned_be16, put_unaligned_le32 macros used - static function for mode_valid - len initialized - MODE_CLOCK_HIGH handled properly - bus_formats handled in mode_valid - GENMASK and FIELD_PREP used - Kconfig proper indentation - error handling endpoint data-lanes - check for bus_formats unsupported - display_timings naming local variables - help modified - ~vsdelay dynamic value set based on the calculation of dsi speed, output speed, blanking - panel->connector_type removed - dual port implemented - devm_drm_panel_bridge_add method used instead of panel description modified - regulator enable and disable with proper orders and delays as per the spec - removed drm_connector_status - added bus_formats - mdelay to usleep_range - magic number to macros for CLRSI and mux registers description modified - replaced u32 instead of uint32_t - updated alphabetic order of headers - added SPDX identifier license Signed-off-by:
Vinay Simha BN <simhavcs@gmail.com> Reviewed-by:
-
Vinay Simha BN authored
- license modified to (GPL-2.0-only OR BSD-2-Clause) - single-link and dual-link lvds description and examples are added - proper indentation - VESA/JEIDA formats picked from panel-lvds dts - dsi data-lanes property removed, it will be picked from dsi0 ports - dual-link lvds port added and implemented - converted from .txt to .yaml Signed-off-by:
-
Qinglang Miao authored
Get rid of boilerplate code by using module_platform_driver macro for v3d_drm. Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
Qinglang Miao authored
When vkms_init() get into out_put, the unregister call of vkms_device->platform is missing. So add it before return. Fixes: ac19f140 ("drm/vkms: Use drmm_add_final_kfree") Signed-off-by:
-
Qinglang Miao authored
When vgem_init() get into out_put, the unregister call of vgem_device->platform is missing. So add it before return. Fixes: 363de9e7 ("drm/vgem: Use drmm_add_final_kfree") Signed-off-by:
-
Melissa Wen authored
VKMS needs vblank interrupts enabled to capture CRC. When vblank is disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck waiting for a capture that will not occur until vkms wakes up. This patch adds a helper to set composer and ensure that vblank remains enabled as long as the CRC capture is needed. It clears the execution of the following kms_cursor_crc subtests: 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding, random, fast-moving])] - successful when running individually. 2. pipe-A-cursor-dpms passes again 3. pipe-A-cursor-suspend also passes The issue was initially tracked in the sequential execution of IGT kms_cursor_crc subtests: when running the test sequence or one of its subtests twice, the odd execs complete and the pairs get stuck in an endless wait. In the IGT code, calling a wait_for_vblank on preparing for CRC capture prevented the busy-wait. But the problem persisted in the pipe-A-cursor-dpms and -suspend subtests. Checking the history, the pipe-A-cursor-dpms subtest was successful when, in vkms_atomic_commit_tail, instead of using the flip_done op, it used wait_for_vblanks. Another way to prevent blocking was wait_one_vblank when enabling crtc. However, in both cases, pipe-A-cursor-suspend persisted blocking in the 2nd start of CRC capture, which may indicate that something got stuck in the step of CRC setup. Indeed, wait_one_vblank in the crc setup was able to sync things and free all kms_cursor_crc subtests. Besides, other alternatives to force enabling vblanks or prevent disabling them such as calling drm_crtc_put_vblank or modeset_enables before commit_planes + offdelay = 0, also unlock all subtests executions. Finally, due to vkms's dependence on vblank interruptions to perform tasks, this patch uses refcount to ensure that vblanks happen when enabling composer and while crc capture is needed. Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> v2: - extract a vkms_set_composer helper - fix vblank refcounting for the disabling case v3: - make the vkms_set_composer helper static - review the credit tags Co-debugged-by:
Sidong Yang <realwakka@gmail.com> Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Reviewed-by:
-
Colin Ian King authored
There a handful of spelling mistakes. fix them. Signed-off-by:
-
Dave Airlie authored
There is no need for that now since it's embedded. Reviewed-by:
-
Dave Airlie authored
Christian suggested this and it makes sense. Reviewed-by:
-
- 08 Aug, 2020 1 commit
-
-
Joe Perches authored
These functions are now empty and no longer useful so remove the functions and their uses. Signed-off-by:
Joe Perches <joe@perches.com> Cc: Bernard Zhao <bernard@vivo.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org>, Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Icenowy Zheng <icenowy@aosc.io>, Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Robert Chiras <robert.chiras@nxp.com> Cc: dri-devel@lists.freedesktop.org, Cc: linux-kernel@vger.kernel.org Cc: opensource.kernel@vivo.com Signed-off-by: Sam Ravnborg <sam@ravnborg.org> # Fixed build and a few warnings Link: https://patchwork.freedesktop.org/patch/msgid/9e13761020750b1ce2f1fabee23ef6e2a2942882.camel@perches.com
-
- 07 Aug, 2020 1 commit
-
-
Sandeep Raghuraman authored
Reproducing bug report here: After hibernating and resuming, DPM is not enabled. This remains the case even if you test hibernate using the steps here: https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html I debugged the problem, and figured out that in the file hardwaremanager.c, in the function, phm_enable_dynamic_state_management(), the check 'if (!hwmgr->pp_one_vf && smum_is_dpm_running(hwmgr) && !amdgpu_passthrough(adev) && adev->in_suspend)' returns true for the hibernate case, and false for the suspend case. This means that for the hibernate case, the AMDGPU driver doesn't enable DPM (even though it should) and simply returns from that function. In the suspend case, it goes ahead and enables DPM, even though it doesn't need to. I debugged further, and found out that in the case of suspend, for the CIK/Hawaii GPUs, smum_is_dpm_running(hwmgr) returns false, while in the case of hibernate, smum_is_dpm_running(hwmgr) returns true. For CIK, the ci_is_dpm_running() function calls the ci_is_smc_ram_running() function, which is ultimately used to determine if DPM is currently enabled or not, and this seems to provide the wrong answer. I've changed the ci_is_dpm_running() function to instead use the same method that some other AMD GPU chips do (e.g Fiji), which seems to read the voltage controller. I've tested on my R9 390 and it seems to work correctly for both suspend and hibernate use cases, and has been stable so far. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208839Signed-off-by:
Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by:
-
