- 23 Jan, 2020 2 commits
-
-
Maxime Ripard authored
Merge tag 'topic/drm-warn-2020-01-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next struct drm_device based drm_WARN* macros Signed-off-by:
Maxime Ripard <maxime@cerno.tech> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87eevrecnf.fsf@intel.com
-
Lyude Paul authored
Mention that the size of these two structs is determined by max_payloads. Suggested by Ville Syrjälä. Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200122194321.14953-2-lyude@redhat.com
-
- 22 Jan, 2020 7 commits
-
-
Lyude Paul authored
The issues caused by: commit 64e62bdf ("drm/dp_mst: Remove VCPI while disabling topology mgr") Prompted me to take a closer look at how we clear the payload state in general when disabling the topology, and it turns out there's actually two subtle issues here. The first is that we're not grabbing &mgr.payload_lock when clearing the payloads in drm_dp_mst_topology_mgr_set_mst(). Seeing as the canonical lock order is &mgr.payload_lock -> &mgr.lock (because we always want &mgr.lock to be the inner-most lock so topology validation always works), this makes perfect sense. It also means that -technically- there could be racing between someone calling drm_dp_mst_topology_mgr_set_mst() to disable the topology, along with a modeset occurring that's modifying the payload state at the same time. The second is the more obvious issue that Wayne Lin discovered, that we're not clearing proposed_payloads when disabling the topology. I actually can't see any obvious places where the racing caused by the first issue would break something, and it could be that some of our higher-level locks already prevent this by happenstance, but better safe then sorry. So, let's make it so that drm_dp_mst_topology_mgr_set_mst() first grabs &mgr.payload_lock followed by &mgr.lock so that we never race when modifying the payload state. Then, we also clear proposed_payloads to fix the original issue of enabling a new topology with a dirty payload state. This doesn't clear any of the drm_dp_vcpi structures, but those are getting destroyed along with the ports anyway. Changes since v1: * Use sizeof(mgr->payloads[0])/sizeof(mgr->proposed_vcpis[0]) instead - vsyrjala Cc: Sean Paul <sean@poorly.run> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Lyude Paul authored
This has always bugged me but somehow I've never remembered to actually fix it. So let's do that. Signed-off-by:
-
Jitao Shi authored
This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by:
Jitao Shi <jitao.shi@mediatek.com> Reviewed-by:
Daniel Kurtz <djkurtz@chromium.org> [uli: followed API changes, removed FW update feature] Signed-off-by:
Ulrich Hecht <uli@fpond.eu> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191230090419.137141-3-enric.balletbo@collabora.com
-
Jitao Shi authored
Add documentation for DT properties supported by ps8640 DSI-eDP converter. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Pankaj Bharadiya authored
Add new struct drm_device based WARN* macros. These are modeled after the core kernel device based WARN* macros. These would be preferred over the regular WARN* macros, where possible. These macros include device information in the backtrace, so we know what device the warnings originate from. Knowing the device specific information in the backtrace would be helpful in development all around. Signed-off-by:
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Maxime Ripard <mripard@kernel.org> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by:
Sean Paul <sean@poorly.run> Signed-off-by:
-
xinhui pan authored
As we move the ttm_bo_individualize_resv() upwards, we need flush the copied fence too. Otherwise the driver keeps waiting for fence. run&Kill kfdtest, then perf top. 25.53% [ttm] [k] ttm_bo_delayed_delete 24.29% [kernel] [k] dma_resv_test_signaled_rcu 19.72% [kernel] [k] ww_mutex_lock Fix: 378e2d5b("drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more") Signed-off-by:
xinhui pan <xinhui.pan@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/series/72339/Signed-off-by:
-
Bo YU authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/drm_dp_mst_topology.c:3693:16: warning: variable ‘origlen’ set but not used [-Wunused-but-set-variable] int replylen, origlen, curreply; It looks like never use variable origlen after assign value to it. Fixes: ad7f8a1f ("drm/helper: add Displayport multi-stream helper (v0.6)") Signed-off-by:
Bo YU <tsu.yubo@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200118080628.mxcx7bfwdas5m7un@kaowomen.cn
-
- 21 Jan, 2020 2 commits
-
-
Ezequiel Garcia authored
Currently, the interrupt lines requested by Panfrost use unmeaningful names, which adds some obscurity to interrupt introspection (i.e. any tool based on procfs' interrupts file). In order to improve this, prefix each requested interrupt with the module name: panfrost-{gpu,job,mmu}. Signed-off-by:Steven Price <steven.price@arm.com> Reviewed-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by:
-
Steven Price authored
Explicit management of the GPU's core stacks is only necessary in the case of a broken integration with the PDC. Since there are no known platforms which have such a broken integration let's remove the explicit control from the driver since this apparently causes problems on other platforms and will have a small performance penality. The out of tree mali_kbase driver contains this text regarding controlling the core stack (CONFIGMALI_CORESTACK): Enabling this feature on supported GPUs will let the driver powering on/off the GPU core stack independently without involving the Power Domain Controller. This should only be enabled on platforms which integration of the PDC to the Mali GPU is known to be problematic. This feature is currently only supported on t-Six and t-HEx GPUs. If unsure, say N. Signed-off-by:
Nicolas Boichat <drinkcat@chromium.org> Tested-by:
-
- 20 Jan, 2020 1 commit
-
-
Lionel Landwerlin authored
We've added a set of new APIs to manipulate syncobjs holding timelines of dma_fence. This adds a bit of documentation about how this works. v2: Small language nits (Lionel) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
- 19 Jan, 2020 5 commits
-
-
Geert Uytterhoeven authored
Add support for the Okaya RH128128T display to the st7735r driver on DT-enabled systems. The RH128128T is a 128x128 1.44" TFT display driven by a Sitronix ST7715R TFT Controller/Driver. The latter is very similar to the ST7735R, and can be handled by the existing st7735r driver. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
-
Geert Uytterhoeven authored
Currently the st7735r driver supports only a single display panel. Prepare for adding support for other display panels by factoring out the display-specific parameters in struct st7735r_cfg. For now, the following parameters can be configured: - Display resolution, - Horizontal/vertical display offsets, - Read-write versus read-only controllers, - RGB versus BGR color component ordering. Rename jd_t18003_t01_pipe_enable() and jd_t18003_t01_pipe_funcs() to st7735r_pipe_enable() resp. st7735r_pipe_funcs(), as they are not really specific to the Jianda JD-T18003-T01 display anymore. Signed-off-by:
-
Geert Uytterhoeven authored
If the resolution of the TFT display is smaller than the maximum resolution supported by the display controller, the display may be connected to the driver output arrays with a horizontal and/or vertical offset, leading to a shifted image. Add support for specifying these offsets. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
Geert Uytterhoeven authored
Document support for the Okaya RH128128T display, which is a 128x128 1.44" TFT display driven by a Sitronix ST7715R TFT Controller/Driver. It can be found on e.g. the Renesas YRSK-LCD-PMOD extension board, which comes with various Renesas development kits (e.g. Renesas Starter Kit+ for RZ/A1H[1]). ST7715R and ST7735R are very similar. Their major difference is that the former is restricted to displays of up to 132x132 pixels, while the latter supports displays up to 132x162 pixels. [1] https://renesasrulz.com/the_vault/f/archive-forum/4981/upgrading-to-the-renesas-rz-a1hSigned-off-by:
-
Geert Uytterhoeven authored
Convert the DT binding documentation for Sitronix ST7735R displays to DT schema. Add a reference to the Adafruit 1.8" LCD while at it. Signed-off-by:
-
- 18 Jan, 2020 1 commit
-
-
Benjamin Gaignard authored
Remove old documentation style and use new one to avoid warnings when compiling with W=1 Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
- 17 Jan, 2020 10 commits
-
-
José Roberto de Souza authored
Removing this lose code block and removing unnecessary bracket. Cc: Lyude Paul <lyude@redhat.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Lyude Paul authored
This reverts commit 64e62bdf. This commit ends up causing some lockdep splats due to trying to grab the payload lock while holding the mgr's lock: [ 54.010099] [ 54.011765] ====================================================== [ 54.018670] WARNING: possible circular locking dependency detected [ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted [ 54.031610] ------------------------------------------------------ [ 54.038516] kworker/1:6/1040 is trying to acquire lock: [ 54.044354] ffff888272af3228 (&mgr->payload_lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.054957] [ 54.054957] but task is already holding lock: [ 54.061473] ffff888272af3060 (&mgr->lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4 [ 54.071193] [ 54.071193] which lock already depends on the new lock. [ 54.071193] [ 54.080334] [ 54.080334] the existing dependency chain (in reverse order) is: [ 54.088697] [ 54.088697] -> #1 (&mgr->lock){+.+.}: [ 54.094440] __mutex_lock+0xc3/0x498 [ 54.099015] drm_dp_mst_topology_get_port_validated+0x25/0x80 [ 54.106018] drm_dp_update_payload_part1+0xa2/0x2e2 [ 54.112051] intel_mst_pre_enable_dp+0x144/0x18f [ 54.117791] intel_encoders_pre_enable+0x63/0x70 [ 54.123532] hsw_crtc_enable+0xa1/0x722 [ 54.128396] intel_update_crtc+0x50/0x194 [ 54.133455] skl_commit_modeset_enables+0x40c/0x540 [ 54.139485] intel_atomic_commit_tail+0x5f7/0x130d [ 54.145418] intel_atomic_commit+0x2c8/0x2d8 [ 54.150770] drm_atomic_helper_set_config+0x5a/0x70 [ 54.156801] drm_mode_setcrtc+0x2ab/0x833 [ 54.161862] drm_ioctl+0x2e5/0x424 [ 54.166242] vfs_ioctl+0x21/0x2f [ 54.170426] do_vfs_ioctl+0x5fb/0x61e [ 54.175096] ksys_ioctl+0x55/0x75 [ 54.179377] __x64_sys_ioctl+0x1a/0x1e [ 54.184146] do_syscall_64+0x5c/0x6d [ 54.188721] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 54.194946] [ 54.194946] -> #0 (&mgr->payload_lock){+.+.}: [ 54.201463] [ 54.201463] other info that might help us debug this: [ 54.201463] [ 54.210410] Possible unsafe locking scenario: [ 54.210410] [ 54.217025] CPU0 CPU1 [ 54.222082] ---- ---- [ 54.227138] lock(&mgr->lock); [ 54.230643] lock(&mgr->payload_lock); [ 54.237742] lock(&mgr->lock); [ 54.244062] lock(&mgr->payload_lock); [ 54.248346] [ 54.248346] *** DEADLOCK *** [ 54.248346] [ 54.254959] 7 locks held by kworker/1:6/1040: [ 54.259822] #0: ffff888275c4f528 ((wq_completion)events){+.+.}, at: worker_thread+0x455/0x6e2 [ 54.269451] #1: ffffc9000119beb0 ((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.}, at: worker_thread+0x455/0x6e2 [ 54.282768] #2: ffff888272a403f0 (&dev->mode_config.mutex){+.+.}, at: i915_hotplug_work_func+0x4b/0x2be [ 54.293368] #3: ffffffff824fc6c0 (drm_connector_list_iter){.+.+}, at: i915_hotplug_work_func+0x17e/0x2be [ 54.304061] #4: ffffc9000119bc58 (crtc_ww_class_acquire){+.+.}, at: drm_helper_probe_detect_ctx+0x40/0xfd [ 54.314855] #5: ffff888272a40470 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_lock+0x74/0xe2 [ 54.324385] #6: ffff888272af3060 (&mgr->lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4 [ 54.334597] [ 54.334597] stack backtrace: [ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted 5.5.0-rc6-02274-g77381c23ee63 #47 [ 54.348893] Hardware name: Google Fizz/Fizz, BIOS Google_Fizz.10139.39.0 01/04/2018 [ 54.357451] Workqueue: events i915_hotplug_work_func [ 54.362995] Call Trace: [ 54.365724] dump_stack+0x71/0x9c [ 54.369427] check_noncircular+0x91/0xbc [ 54.373809] ? __lock_acquire+0xc9e/0xf66 [ 54.378286] ? __lock_acquire+0xc9e/0xf66 [ 54.382763] ? lock_acquire+0x175/0x1ac [ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.393177] ? __mutex_lock+0xc3/0x498 [ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101 [ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.426645] ? intel_digital_port_connected+0x34d/0x35c [ 54.432482] ? intel_dp_detect+0x227/0x44e [ 54.437056] ? ww_mutex_lock+0x49/0x9a [ 54.441242] ? drm_helper_probe_detect_ctx+0x75/0xfd [ 54.446789] ? intel_encoder_hotplug+0x4b/0x97 [ 54.451752] ? intel_ddi_hotplug+0x61/0x2e0 [ 54.456423] ? mark_held_locks+0x53/0x68 [ 54.460803] ? _raw_spin_unlock_irqrestore+0x3a/0x51 [ 54.466347] ? lockdep_hardirqs_on+0x187/0x1a4 [ 54.471310] ? drm_connector_list_iter_next+0x89/0x9a [ 54.476953] ? i915_hotplug_work_func+0x206/0x2be [ 54.482208] ? worker_thread+0x4d5/0x6e2 [ 54.486587] ? worker_thread+0x455/0x6e2 [ 54.490966] ? queue_work_on+0x64/0x64 [ 54.495151] ? kthread+0x1e9/0x1f1 [ 54.498946] ? queue_work_on+0x64/0x64 [ 54.503130] ? kthread_unpark+0x5e/0x5e [ 54.507413] ? ret_from_fork+0x3a/0x50 The proper fix for this is probably cleanup the VCPI allocations when we're enabling the topology, or on the first payload allocation. For now though, let's just revert. Signed-off-by:
-
Icenowy Zheng authored
Feixin K101 IM2BA02 is a 800x1280 4-lane MIPI-DSI LCD panel. Add a panel driver for it. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Signed-off-by:
-
Icenowy Zheng authored
Feixin K101 IM2BA02 is a 10.1" 800x1280 4-lane MIPI-DSI panel. Add device tree binding for it. Signed-off-by:
-
Icenowy Zheng authored
Shenzhen Feixin Photoelectics Co., Ltd is a company to provide LCD modules. Add its vendor prefix. Signed-off-by:
-
Jitao Shi authored
Auo,auo,b101uan08.3's connector is same as boe,tv101wum-nl6. The most codes can be reuse. So auo,b101uan08.3 and boe,tv101wum-nl6 use one driver file. Add the different parts in driver data. Signed-off-by:
-
Jitao Shi authored
Boe,tv101wum-n53's connector is same as boe,tv101wum-nl6. The most codes can be reuse. So boe,tv101wum-n53 and boe,tv101wum-nl6 use one driver file. Add the different parts in driver data. Signed-off-by:
-
Jitao Shi authored
Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6. The most codes can be reuse. So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file. Add the different parts in driver data. Signed-off-by:
-
Jitao Shi authored
Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel. Signed-off-by:
-
Jitao Shi authored
Add documentation for "boe,tv101wum-n16", "auo,kd101n80-45na", "boe,tv101wum-n53" and "auo,b101uan08.3" panels. Signed-off-by:
-
- 16 Jan, 2020 1 commit
-
-
Christian König authored
Another completely unused feature. Signed-off-by:
Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/348265/
-
- 15 Jan, 2020 11 commits
-
-
Colin Ian King authored
There is a hunk of code that is incorrectly indented, clean up the indentation and a comment block. Also remove block braces around a one line statement on an if condition and add missing spaces after if keywords. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Cc: Antonino Daplas <adaplas@gmail.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200113144627.219967-1-colin.king@canonical.com
-
Masahiro Yamada authored
The objects in $(fb-objs) $(fb-y) $(fb-m) are linked to fb.ko . This line adds $(fb-y) to fb-objs, so the objects from $(fb-y) are listed twice as the dependency of the module. It works because Kbuild trims the duplicated objects from linking, but there is no good reason to have this line. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Fix up inconsistent usage of upper and lowercase letters in "Exynos" name. "EXYNOS" is not an abbreviation but a regular trademarked name. Therefore it should be written with lowercase letters starting with capital letter. The lowercase "Exynos" name is promoted by its manufacturer Samsung Electronics Co., Ltd., in advertisement materials and on website. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Julia Lawall authored
Use resource_size rather than a verbose computation on the end and start fields. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) <smpl> @@ struct resource ptr; @@ - (ptr.end - ptr.start + 1) + resource_size(&ptr) </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> [b.zolnierkie: minor patch summary fixup] Signed-off-by:
-
Julia Lawall authored
Use resource_size rather than a verbose computation on the end and start fields. The semantic patch that makes these changes is as follows: (http://coccinelle.lip6.fr/) <smpl> @@ struct resource ptr; @@ - (ptr.end - ptr.start + 1) + resource_size(&ptr) </smpl> Signed-off-by:
-
Julia Lawall authored
The monspecs structure is only copied into another structure, so make it const. The opportunity for this change was found using Coccinelle. Signed-off-by:
-
Nathan Chancellor authored
Clang warns: ../drivers/video/fbdev/core/fbmem.c:665:3: warning: misleading indentation; statement is not part of the previous 'else' [-Wmisleading-indentation] if (fb_logo.depth > 4 && depth > 4) { ^ ../drivers/video/fbdev/core/fbmem.c:661:2: note: previous statement is here else ^ ../drivers/video/fbdev/core/fbmem.c:1075:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] return ret; ^ ../drivers/video/fbdev/core/fbmem.c:1072:2: note: previous statement is here if (!ret) ^ 2 warnings generated. This warning occurs because there are spaces before the tabs on these lines. Normalize the indentation in these functions so that it is consistent with the Linux kernel coding style and clang no longer warns. Fixes: 1692b37c ("fbdev: Fix logo if logo depth is less than framebuffer depth") Link: https://github.com/ClangBuiltLinux/linux/issues/825Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Nathan Chancellor authored
Clang warns: ../drivers/video/fbdev/core/fbcon.c:915:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] return err; ^ ../drivers/video/fbdev/core/fbcon.c:912:2: note: previous statement is here if (!search_fb_in_map(info_idx)) ^ 1 warning generated. This warning occurs because there is a space before the tab on this line. This happens on several lines in this function; normalize them so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. This warning was introduced before the beginning of git history so no fixes tab. Link: https://github.com/ClangBuiltLinux/linux/issues/824Signed-off-by: -
Chuhong Yuan authored
The driver uses kfree() to release the resource allocated by framebuffer_alloc(), which does not match. Use framebuffer_release() instead to fix it. Fixes: 638772c7 ("fb: add support of LCD display controller on pxa168/910 (base layer)") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
Colin Ian King authored
Variable r is being initialized to zero, so the check of a non-zero rv is redundant and can be removed. It appears that the previous case statements set r to be -EINVAL and the "Fallthrough" comment afterwards suggested it was going to fall through to this non-zero check but won't because of the break statement. Remove the confusion by removing the Fallthrough comment too. Addresses-Coverity: ("Logically dead code") Fixes: b39a982d ("OMAP: DSS2: omapfb driver") Signed-off-by: -
Krzysztof Kozlowski authored
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by:
-
