- 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 <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117015837.402239-2-jose.souza@intel.com
-
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:
Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200117205149.97262-1-lyude@redhat.com
-
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:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200116033636.512461-4-icenowy@aosc.io
-
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:
Rob Herring <robh@kernel.org> 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 <jitao.shi@mediatek.com> Reviewed-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:
Christian König <christian.koenig@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/348265/
-
- 15 Jan, 2020 14 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:
-
Chuhong Yuan authored
The driver forgets to disable the regulator in remove like what is done in probe failure. Add the missed call to fix it. Signed-off-by:
Michal Vokáč <michal.vokac@ysoft.com> Signed-off-by:
-
Colin Ian King authored
There is a block of statements that are indented too deeply, remove the extraneous tabs. Signed-off-by:
Michael Kelley <mikelley@microsoft.com> Cc: "K . Y . Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Sasha Levin <sashal@kernel.org> [b.zolnierkie: minor patch summary fixup] Signed-off-by:
-
Dan Carpenter authored
The "fix" struct has a 2 byte hole after ->ywrapstep and the "fix = info->fix;" assignment doesn't necessarily clear it. It depends on the compiler. The solution is just to replace the assignment with an memcpy(). Fixes: 1f5e31d7 ("fbmem: don't call copy_from/to_user() with mutex held") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrea Righi <righi.andrea@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Peter Rosin <peda@axentia.se> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
- 14 Jan, 2020 1 commit
-
-
Daniel Stone authored
getfb2 allows us to pass multiple planes and modifiers, just like addfb2 over addfb. Changes since v2: - add privilege checks from getfb1 since handles should only be returned to master/root Changes since v1: - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID - update ioctl number Signed-off-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Juston Li <juston.li@intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 13 Jan, 2020 5 commits
-
-
Paul Cercueil authored
The FRD350H54004 is a simple 3.5" 320x240 24-bit TFT panel, found for instance inside the Anbernic RG-350 handheld gaming console. v2: Order alphabetically v3: Add connector_type, and update timings according to the constraints listed in the datasheet Signed-off-by:Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Paul Cercueil authored
Add bindings documentation for the Frida 3.5" (320x240 pixels) 24-bit TFT LCD panel. v2: Switch documentation from plain text to YAML v3: Simply add new compatible to panel-simple.yaml file instead of adding new file Signed-off-by: -
Paul Cercueil authored
Add an entry for Shenzhen Frida LCD Co., Ltd. v2: No change v3: No change Signed-off-by:
-
Krzysztof Kozlowski authored
The Rockship DRM GEM code uses vmap()/vunmap() so vmalloc header must be included to avoid warnings like (on IA64, compile tested): drivers/gpu/drm/rockchip/rockchip_drm_gem.c: In function ‘rockchip_gem_alloc_iommu’: drivers/gpu/drm/rockchip/rockchip_drm_gem.c:134:20: error: implicit declaration of function ‘vmap’ [-Werror=implicit-function-declaration] Reported-by:kbuild test robot <lkp@intel.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1577779956-7612-1-git-send-email-krzk@kernel.org
-
Wambui Karuga authored
Replace the open coded calculation with the more concise and readable DIV_ROUND_UP macro. Signed-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
- 12 Jan, 2020 2 commits
-
-
Arnd Bergmann authored
Making this IS_REACHABLE() was still wrong, as that just determines whether the lower-level backlight code would be reachable from the panel driver. However, with CONFIG_DRM=y and CONFIG_BACKLIGHT_CLASS_DEVICE=m, the drm_panel_of_backlight is left out of drm_panel.o but the condition tells the driver that it is there, leading to multiple link errors such as ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-sitronix-st7701.ko] undefined! ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-sharp-ls043t1le01.ko] undefined! ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-seiko-43wvf1g.ko] undefined! ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-ronbo-rb070d30.ko] undefined! ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-rocktech-jh057n00900.ko] undefined! ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.ko] undefined! ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.ko] undefined! Change the condition to check for whether the function was actually part of the drm module. This version of the patch survived a few hundred randconfig builds, so I have a good feeling this might be the last one for the export. Fixes: 4a34a9dc ("drm/drm_panel: Fix EXPORT of drm_panel_of_backlight() one more time") Fixes: 907aa265 ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight") Fixes: 152dbdea ("drm/panel: add backlight support") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
With gcc -O3 in combination with the structleak plug, the compiler can inline very aggressively, leading to rather large stack usage: drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function 'td028ttec1_prepare': drivers/gpu/drm/panel/panel-tpo-td028ttec1.c:233:1: error: the frame size of 2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] } Marking jbt_reg_write_*() as noinline avoids the case where multiple instances of this function get inlined into the same stack frame and each one adds a copy of 'tx_buf'. The compiler is clearly making some bad decisions here, but I did not open a new bug report as this only happens in combination with the structleak plugin. This fixes mmtom ("init/Kconfig: enable -O3 for all arches") Link: https://lore.kernel.org/lkml/CAK8P3a3jAnFZA3GFRtdYdg1-i-oih3pOQzkkrK-X3BGsFrMiZQ@mail.gmail.com/Signed-off-by:
-
- 11 Jan, 2020 2 commits
-
-
Hans de Goede authored
If the new video=... panel_orientation option is set for a connector, honor it and setup a matching "panel orientation" property on the connector. Changes in v2: -Improve DRM_INFO message to make it clear that the panel_orientation is being forced from the commandline BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200105155120.96466-2-hdegoede@redhat.com
-
Derek Basehore authored
Not every platform needs quirk detection for panel orientation, so split the drm_connector_init_panel_orientation_property into two functions. One for platforms without the need for quirks, and the other for platforms that need quirks. Hans de Goede (changes in v2): Rename the function from drm_connector_init_panel_orientation_property to drm_connector_set_panel_orientation[_with_quirk] and pass in the panel-orientation to set. Beside the rename, also make the function set the passed in value only once, if the value was set before (to a value other then DRM_MODE_PANEL_ORIENTATION_UNKNOWN) make any further set calls a no-op. This change is preparation for allowing the user to override the panel-orientation for any connector from the kernel commandline. When the panel-orientation is overridden this way, then we must ignore the panel-orientation detection done by the driver. Reviewed-by:
Derek Basehore <dbasehore@chromium.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200105155120.96466-1-hdegoede@redhat.com
-
- 10 Jan, 2020 2 commits
-
-
Oleg Vasilev authored
The helper should always be used. Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
Oleg Vasilev <oleg.vasilev@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
-
Oleg Vasilev authored
DP_MAX_DOWNSTREAM_PORTS=0x10 is a vendor-independent constant. Reviewed-by:
-
- 09 Jan, 2020 3 commits
-
-
Miquel Raynal authored
Add support for the Satoz SAT050AT40H12R2 panel. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Miquel Raynal authored
Satoz is a Chinese TFT manufacturer. Website: http://www.sat-sz.com/English/index.html Add the compatible for its SAT050AT40H12R2 5.0 inch LCD panel. Signed-off-by:
-
Maxime Ripard authored
The Allwinner SoCs have a display engine composed of several controllers assembled differently depending on the SoC, the number and type of output they have, and the additional features they provide. A number of those are supported in Linux, with the matching bindings. Now that we have the DT validation in place, let's split into separate file and convert the device tree bindings for those controllers to schemas. Reviewed-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200103152801.47254-1-maxime@cerno.tech
-
