- 07 Jun, 2019 2 commits
-
-
Neil Armstrong authored
Add missing XBGR8888 & ABGR8888 formats variants from the primary plane. Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190429075238.7884-1-narmstrong@baylibre.com
-
Neil Armstrong authored
Add immutable zpos property to primary and overlay planes to specify the current fixed zpos position. Fixes: f9a23481 ("drm/meson: Support Overlay plane for video rendering") Signed-off-by:
-
- 06 Jun, 2019 12 commits
-
-
Daniel Vetter authored
In commit def35e7c Author: Shayenne Moura <shayenneluzmoura@gmail.com> Date: Wed Jan 30 14:06:36 2019 -0200 drm/vkms: Bugfix extra vblank frame we fixed the vblank counter to give accurate results outside of drm_crtc_handle_vblank, which fixed bugs around vblank timestamps being off-by-one and causing the vblank counter to jump when it shouldn't. The trouble is that this completely broke crc generation. Shayenne and Rodrigo tracked this down to the vblank timestamp going backwards in time somehow. Which then resulted in an underflow in drm_vblank.c code, which resulted in all kinds of things breaking really badly. The reason for this is that once we've called drm_crtc_handle_vblank and the hrtimer isn't forwarded yet, we're returning a vblank timestamp in the past. This race is really hard to hit since it's small, except when you enable crc generation: In that case there's a call to drm_crtc_accurate_vblank right in-betwen, so we're guaranteed to hit the bug. The fix is to roll the hrtimer forward _before_ we do the vblank processing (which has a side-effect of incrementing the vblank counter), and we always subtract one frame from the hrtimer - since now it's always one frame in the future. To make sure we don't hit this again also add a WARN_ON checking for whether our timestamp is somehow moving into the past, which is never should. This also aligns more with how real hw works: 1. first all registers are updated with the new timestamp/vblank counter values. 2. then an interrupt is generated 3. kernel interrupt handler eventually fires. So doing this aligns vkms closer with what drm_vblank.c expects. Document this also in a comment. Cc: Shayenne Moura <shayenneluzmoura@gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Tested-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by:
-
Rodrigo Siqueira authored
The function vkms_output_init() is invoked during the module initialization, and it handles the creation/configuration of the vkms essential elements (e.g., connectors, encoder, etc). Among the initializations, this function tries to initialize a connector and register it by calling drm_connector_register(). However, inside the drm_connector_register(), at the beginning of this function there is the following validation: if (!connector->dev->registered) return 0; In this sense, invoke drm_connector_register() after initializing the connector has no effect because the register field is false. The connector register happens when drm_dev_register() is invoked; the same issue exists with drm_connector_unregister(). Therefore, this commit removes the unnecessary call to drm_connector_register() and drm_connector_unregister(). Changes since v2: * Remove unnecessary call to drm_connector_unregister() * Remove unused label Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190315161142.23gfu32lueyqrmyq@smtp.gmail.com
-
Sam Ravnborg authored
Stop using the deprecated drmP.h header file. Replaced with relevant forwards or headers files. Header files sorted in all files touched. Build tested with allyesconfig, allmodconfig for a number of architectures. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190605134835.25112-2-sam@ravnborg.org
-
Ville Syrjälä authored
From VESA EDID implementation guide v1.0: "For EDID version 1 revision 2 or earlier data structures when offset 14h bit 7 is set to one, the value of bits 6-0 are undefined, and therefore cannot be interpreted to mean anything." And since EDID 1.4 redefines that bit let's consult it only for EDID 1.3. Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190529110204.2384-2-ville.syrjala@linux.intel.comReviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Mario Kleiner <mario.kleiner.de@gmail.com>
-
Ville Syrjälä authored
Give the "DFP 1.x" bit a proper name, and clean up the rest of the bits defines as well. Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
Hans de Goede authored
GPD has done it again, make a nice device (good), use way too generic DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly). Because of the too generic DMI strings this entry is also doing bios-date matching, so the gpd_micropc data struct may very well need to be updated with some extra bios-dates in the future. Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190524125759.14131-2-hdegoede@redhat.com
-
Hans de Goede authored
GPD has done it again, make a nice device (good), use way too generic DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly). Because of the too generic DMI strings this entry is also doing bios-date matching, so the gpd_pocket2 data struct may very well need to be updated with some extra bios-dates in the future. Changes in v2: -Add one more known BIOS date to the list of BIOS dates Cc: Jurgen Kramer <gtmkramer@xs4all.nl> Reported-by:
Jurgen Kramer <gtmkramer@xs4all.nl> Acked-by:
-
Daniel Vetter authored
We can be called from any context, we need to be prepared. Noticed this while hacking on vkms, which calls this function from a normal worker. Which really upsets lockdep. Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by:
-
Thomas Zimmermann authored
The documentation tools interpret drm_gem_vram_mm_funcs as function and there appears to be no way of inline-documenting constants. This results in a warning by 'make htmldocs'. For now, removing drm_gem_vram_mm_funcs from generated documentation works around the issue. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20190604111330.25324-1-tzimmermann@suse.de Fixes: 5c9dcacf ("drm: Add default instance for VRAM MM callback functions") Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
David Riley authored
virtio_gpu_cmd_get_capset would check for the existence of an entry under lock. If it was not found, it would unlock and call virtio_gpu_cmd_get_capset to create a new entry. The new entry would be added it to the list without checking if it was added by another task during the period where the lock was not held resulting in duplicate entries. Compounding this issue, virtio_gpu_cmd_capset_cb would stop iterating after find the first matching entry. Multiple callbacks would modify the first entry, but any subsequent entries and their associated waiters would eventually timeout since they don't become valid, also wasting memory along the way. Signed-off-by:
David Riley <davidriley@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190605234423.11348-3-davidriley@chromium.orgSigned-off-by:
-
David Riley authored
If multiple callers occur simultaneously, wake them all up. Signed-off-by:
-
David Riley authored
virtio_gpu_get_caps_ioctl could return success with invalid data if a second caller to the function occurred after the entry was created in virtio_gpu_cmd_get_capset but prior to the virtio_gpu_cmd_capset_cb callback being called. This could leak contents of memory as well since the caps_cache allocation is done without zeroing. Signed-off-by:
-
- 05 Jun, 2019 10 commits
-
-
Douglas Anderson authored
See the PhD thesis in the comments in this patch for details, but to summarize this adds a hacky "unwedge" feature to the dw_hdmi i2c bus to workaround what appears to be a hardware errata. This relies on a pinctrl entry to help change around muxing to perform the unwedge. NOTE that the specific TV this was tested on was the "Samsung UN40HU6950FXZA" and the specific port was the "STB" port. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190502225336.206885-2-dianders@chromium.org
-
Douglas Anderson authored
In certain situations it was seen that we could wedge up the DDC bus on the HDMI adapter on rk3288. The only way to unwedge was to mux one of the pins over to GPIO output-driven-low temporarily and then quickly mux back. Full details can be found in the patch ("drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus"). Since unwedge requires remuxing the pins, we first need to add to the bindings so that we can specify what state the pins should be in for unwedging. Reviewed-by:Rob Herring <robh@kernel.org> Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header file. Replace it with relevant include files. Sort include files in files touched. Signed-off-by:
-
Sam Ravnborg authored
Drop use of drm_os_linux macros. Simple 1:1 replacements of - DRM_UDELAY - DRM_CURRENTPID - DRM_READ - DRM_WRITE With this change we do not need to introduce the deprecated drm_os_linux.h header when we drop use of drmP.h. Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header file. Replace it with the necessary includes of other headers. Signed-off-by:
-
Sam Ravnborg authored
Drop use of macros from the deprecated drm_os_linux header. Simple 1:1 replacements of - DRM_UDELAY - DRM_CURRENTPID - DRM_READ - DRM_WRITE With this change we do not need to introduce the deprecated drm_os_linux.h header when we drop use of drmP.h. Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header. Repalced with relevant header files and sorted header files in all files touched. Replaced DRM_{READ,WRITE} to avoid the drm_os_linux header. Build tested with allyesconfig, allmodconfig on various architectures. Signed-off-by: -
Gurchetan Singh authored
Other DRM drivers use it too. Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190604234428.23252-1-gurchetansingh@chromium.orgSigned-off-by:
-
Vivek Gautam authored
MTP SDM845 panel seems to need additional delay to bring panel to a workable state. Running modetest without this change displays blurry artifacts. Signed-off-by:
Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by:
-
Chris Wilson authored
If we have to drop the seqcount & rcu lock to perform a krealloc, we have to restart the loop. In doing so, be careful not to lose track of the already acquired exclusive fence. Fixes: fedf5413 ("dma-buf: Restart reservation_object_get_fences_rcu() after writes") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: stable@vger.kernel.org #v4.10 Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190604125323.21396-1-chris@chris-wilson.co.uk
-
- 04 Jun, 2019 10 commits
-
-
Claudiu Beznea authored
Revert shift by 8 of state->base.alpha. This introduced a regression on planes. Fixes: 7f73c10b ("drm/atmel-hclcdc: Convert to the new generic alpha property") Cc: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
-
Sandeep Sheriker Mallikarjun authored
Add the LCD controller for SAM9X60. Signed-off-by:
Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com> [claudiu.beznea@microchip.com: add fixed_clksrc option to atmel_hlcdc_dc_sam9x60] Signed-off-by:
-
Sandeep Sheriker Mallikarjun authored
For SAM9X60 SoC, sys_clk is through lcd_gclk clock source and this needs to be enabled before enabling lcd_clk. Signed-off-by:
-
Claudiu Beznea authored
Remove cfg initialization with zero and read state with drm_crtc_state_to_atmel_hlcdc_crtc_state() so that cfg to be initialized with state's output_mode. Signed-off-by:
-
Claudiu Beznea authored
SAM9x60 LCD Controller has no option to select clock source as previous controllers have. To be able to use the same driver even for this LCD controller add a config option to know if controller supports this. Signed-off-by:
-
Chris Wilson authored
We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:ffffc900006cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: 0000000000000000 RBX: ffff88826759a168 RCX: 0000000000000000 <4> [341.846589] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffffff8112844c <4> [341.846595] RBP: ffff8882708fa548 R08: 0000000000000000 R09: 0000000000039600 <4> [341.846601] R10: 0000000000000000 R11: 0000000000000ce4 R12: ffffffffa07de1e0 <4> [341.846607] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa07de2d0 <4> [341.846613] FS: 00007f62b5ae0e40(0000) GS:ffff888276380000(0000) knlGS:0000000000000000 <4> [341.846620] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.846626] CR2: 000055a4e064f4a0 CR3: 0000000266b16006 CR4: 00000000003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:00007ffe7a227138 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 <4> [341.846904] RAX: ffffffffffffffda RBX: 00007ffe7a2272b0 RCX: 00007f62b51871b7 <4> [341.846910] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000557cd6b55948 <4> [341.846916] RBP: 0000557cd6b558e0 R08: 0000557cd6b5594c R09: 00007ffe7a227160 <4> [341.846922] R10: 00007ffe7a226134 R11: 0000000000000206 R12: 0000000000000000 <4> [341.846927] R13: 00007ffe7a227820 R14: 0000000000000000 R15: 0000000000000000 <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [<ffffffff819aad2c>] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [<ffffffff819aab9d>] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [<ffffffff810b6379>] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: 0000 [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.890655] Workqueue: events output_poll_execute <4> [341.890663] RIP: 0010:drm_setup_crtcs+0x13e/0xbe0 <4> [341.890669] Code: 00 41 8b 44 24 58 85 c0 0f 8e f9 01 00 00 44 8b 6c 24 20 44 8b 74 24 28 31 db 31 ed 49 8b 44 24 60 48 63 d5 44 89 ee 83 c5 01 <48> 8b 04 d0 44 89 f2 48 8b 38 48 8b 87 88 01 00 00 48 8b 40 20 e8 <4> [341.890686] RSP: 0018:ffffc9000033fd40 EFLAGS: 00010202 <4> [341.890692] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000000 <4> [341.890700] RDX: 0000000000000001 RSI: 0000000000000c80 RDI: 00000000ffffffff <4> [341.890707] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 <4> [341.890715] R10: 0000000000000c80 R11: 0000000000000000 R12: ffff888267599fe8 <4> [341.890722] R13: 0000000000000c80 R14: 0000000000000708 R15: 0000000000000007 <4> [341.890730] FS: 0000000000000000(0000) GS:ffff888276200000(0000) knlGS:0000000000000000 <4> [341.890739] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.890745] CR2: 000055a4e064f4a0 CR3: 000000026d234003 CR4: 00000000003606f0 <4> [341.890752] Call Trace: <4> [341.890760] drm_fb_helper_hotplug_event.part.24+0x89/0xb0 <4> [341.890768] drm_kms_helper_hotplug_event+0x21/0x30 <4> [341.890774] output_poll_execute+0x9d/0x1a0 <4> [341.890782] process_one_work+0x245/0x610 <4> [341.890790] worker_thread+0x37/0x380 <4> [341.890796] ? process_one_work+0x610/0x610 <4> [341.890802] kthread+0x119/0x130 <4> [341.890808] ? kthread_park+0x80/0x80 <4> [341.890815] ret_from_fork+0x3a/0x50 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603135910.15979-2-chris@chris-wilson.co.uk
-
Uma Shankar authored
Dropped static functions from kernel documentation. v2: Dropped the comments altogether for static functions, as the definitions seems self explanatory. Suggested-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1559567330-25182-4-git-send-email-uma.shankar@intel.com
-
Uma Shankar authored
Fixes the following warnings: ./include/drm/drm_mode_config.h:841: warning: Incorrect use of kernel-doc format: * hdr_output_metadata_property: Connector property containing hdr ./include/drm/drm_mode_config.h:918: warning: Function parameter or member 'hdr_output_metadata_property' not described in 'drm_mode_config' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_output_metadata' not described in 'drm_connector' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_sink_metadata' not described in 'drm_connector' Also adds some property documentation for HDR Metadata Connector Property in connector property create function. v2: Fixed Sean Paul's review comments. v3: Fixed Daniel Vetter's review comments, added the UAPI structure definition section in kernel docs. v4: Fixed Daniel Vetter's review comments. v5: Added structure member references as per Daniel's suggestion. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: "Ville Syrjä" <ville.syrjala@linux.intel.com> Cc: Hans Verkuil <hansverk@cisco.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Reviewed-by: Sean Paul <sean@poorly.run> (v1) Signed-off-by:
-
Uma Shankar authored
Add a new section for UAPI structure and helper definitions in kernel docbook. Suggested-by:
-
Noralf Trønnes authored
struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so use that directly instead and attach it as a modeset array onto drm_client_dev. drm_fb_helper will use this array to store its modesets which means it will always initialize a drm_client, but it will not register the client (callbacks) unless it's the generic fbdev emulation. Code will later be moved to drm_client, so add code there in a new file drm_client_modeset.c with MIT license to match drm_fb_helper.c. The modeset connector array size is hardcoded for the cloned case to avoid having to pass in a value from the driver. A value of 8 is chosen to err on the safe side. This means that the max connector argument for drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore, a todo entry for this is added. In pan_display_atomic() restore_fbdev_mode_force() is used instead of restore_fbdev_mode_atomic() because that one will later become internal to drm_client_modeset. Locking order: 1. drm_fb_helper->lock 2. drm_master_internal_acquire 3. drm_client_dev->modeset_mutex v6: Improve commit message (Sam Ravnborg) v3: - Use full drm_client_init/release for the modesets (Daniel Vetter) - drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter) - Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter) v2: - Add modesets array to drm_client (Daniel Vetter) - Use a new file for the modeset code (Daniel Vetter) - File has to be MIT licensed (Emmanuel Vadot) - Add copyrights from drm_fb_helper.c Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
-
- 03 Jun, 2019 6 commits
-
-
Daniel Vetter authored
drm_atomic_set_fence_for_plane() contains the main discussion from a driver pov, link to that from more places. Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] We can issue HDR static metadata as part of stream updates for non-modesets as long as we force a modeset when entering or exiting HDR. This avoids unnecessary blanking for simple metadata updates. [How] When changing scaling and abm for the stream also check if HDR has changed and send the stream update. This will only happen in non-modeset cases. Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] For userspace to send static HDR metadata to the display we need to attach the property on the connector and send it to DC. [How] The property is attached to HDMI and DP connectors. Since the metadata isn't actually available when creating the connector this isn't a property we can dynamically support based on the extension block being available or not. When the HDR metadata is changed a modeset will be forced for now. We need to switch from 8bpc to 10bpc in most cases anyway, and we want to fully exit HDR mode when userspace gives us a NULL metadata, so this isn't completely unnecessary. The requirement can later be reduced to just entering and exiting HDR or switching max bpc. Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Uma Shankar authored
Fixed doc warnings in drm uapi header. All the UAPI structures are now documented in kernel doc. Signed-off-by:
-
Uma Shankar authored
Drop a redundant and unused variable "hdr_output_metadata" from drm_connector. Suggested-by:
-
Daniel Vetter authored
With Eric's patch commit ba6e798e Author: Eric Anholt <eric@anholt.net> Date: Wed Apr 24 11:56:17 2019 -0700 drm/doc: Document expectation that userspace review looks at kernel uAPI. there's been concerns raised that we expect userspace people to do in-depth kernel patch review. That's not reasonable, same way kernel people can't review all the userspace we have. Try to clarify expectations a bit more. Cc: Eric Anholt <eric@anholt.net> Cc: Pekka Paalanen <ppaalanen@gmail.com> Cc: contact@emersion.fr Cc: wayland-devel@lists.freedesktop.org Acked-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
-
