aboutsummaryrefslogtreecommitdiffstats
path: root/include/drm (follow)
AgeCommit message (Collapse)AuthorFilesLines
2020-03-26drm: Handle dev->unique with drmm_Daniel Vetter1-0/+1
We need to add a drmm_kstrdup for this, but let's start somewhere. This is not exactly perfect onion unwinding, but it's jsut a kfree so doesn't really matter at all. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-21-daniel.vetter@ffwll.ch
2020-03-26Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst3-7/+24
Requested for getting some i915 fixes back into drm-misc-next by danvet. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2020-03-26drm: add managed resources tied to drm_deviceDaniel Vetter3-0/+51
We have lots of these. And the cleanup code tends to be of dubious quality. The biggest wrong pattern is that developers use devm_, which ties the release action to the underlying struct device, whereas all the userspace visible stuff attached to a drm_device can long outlive that one (e.g. after a hotunplug while userspace has open files and mmap'ed buffers). Give people what they want, but with more correctness. Mostly copied from devres.c, with types adjusted to fit drm_device and a few simplifications - I didn't (yet) copy over everything. Since the types don't match code sharing looked like a hopeless endeavour. For now it's only super simplified, no groups, you can't remove actions (but kfree exists, we'll need that soon). Plus all specific to drm_device ofc, including the logging. Which I didn't bother to make compile-time optional, since none of the other drm logging is compile time optional either. One tricky bit here is the chicken&egg between allocating your drm_device structure and initiliazing it with drm_dev_init. For perfect onion unwinding we'd need to have the action to kfree the allocation registered before drm_dev_init registers any of its own release handlers. But drm_dev_init doesn't know where exactly the drm_device is emebedded into the overall structure, and by the time it returns it'll all be too late. And forcing drivers to be able clean up everything except the one kzalloc is silly. Work around this by having a very special final_kfree pointer. This also avoids troubles with the list head possibly disappearing from underneath us when we release all resources attached to the drm_device. v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless shuffling while getting everything into shape. v3: Add static to add/del_dr (Neil) Move typo fix to the right patch (Neil) v4: Enforce contract for drmm_add_final_kfree: Use ksize() to check that the drm_device is indeed contained somewhere in the final kfree(). Because we need that or the entire managed release logic blows up in a pile of use-after-frees. Motivated by a discussion with Laurent. v5: Review from Laurent: - %zu instead of casting size_t - header guards - sorting of includes - guarding of data assignment if we didn't allocate it for a NULL pointer - delete spurious newline - cast void* data parameter correctly in ->release call, no idea how this even worked before v6: Review from Sam - Add the kerneldoc for the managed sub-struct back in, even if it doesn't show up in the generated html somehow. - Explain why __always_inline. - Fix bisectability around the final kfree() in drm_dev_relase(). This is just interim code which will disappear again. - Some whitespace polish. - Add debug output when drmm_add_action or drmm_kmalloc fail. v7: My bisectability fix wasn't up to par as noticed by smatch. v8: Remove unecessary {} around if else v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr() helper (Thomas). v10: kfree_const goes boom on the plain "kmalloc" assignment, somehow we need to wrap that in kstrdup_const() too!! Also renumber revision log, I somehow reset it midway thruh. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Neil Armstrong <narmstrong@baylibre.com Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch
2020-03-24drm: Add a drm_get_unmapped_area() helperThomas Hellstrom (VMware)1-0/+9
Unaligned virtual addresses makes it unlikely that huge page-table entries can be used. So align virtual buffer object address huge page boundaries to the underlying physical address huge page boundaries taking buffer object sizes into account to determine when it might be possible to use huge page-table entries. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Thomas Hellstrom (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Acked-by: Christian König <christian.koenig@amd.com>
2020-03-24drm/ttm, drm/vmwgfx: Support huge TTM pagefaultsThomas Hellstrom (VMware)1-1/+2
Support huge (PMD-size and PUD-size) page-table entries by providing a huge_fault() callback. We still support private mappings and write-notify by splitting the huge page-table entries on write-access. Note that for huge page-faults to occur, either the kernel needs to be compiled with trans-huge-pages always enabled, or the kernel needs to be compiled with trans-huge-pages enabled using madvise, and the user-space app needs to call madvise() to enable trans-huge pages on a per-mapping basis. Furthermore huge page-faults will not succeed unless buffer objects and user-space addresses are aligned on huge page size boundaries. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Thomas Hellstrom (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2020-03-21drm/mipi-dbi: Make mipi_dbi_command_stackbuf() data parameter constGeert Uytterhoeven1-2/+3
mipi_dbi_command_stackbuf() copies the passed buffer data, so it can be const. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200316164249.6234-1-geert+renesas@glider.be
2020-03-20drm: Add DP1.4 VSC SDP Payload related Data StructuresGwan-gyeong Mun1-0/+130
It adds new enumeration definitions for VSC SDP Payload for Pixel Encoding/Colorimetry Format. And it adds a new drm data structure for DP VSC SDP. enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range". And enum dp_content_type corresponds "Content Type" All of them are based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through DB18]. v3: Add a new drm data structure for DP VSC SDP v5: Addressed review comments from Uma - Add kernel docs for added data structures - Rename enum dp_colorspace to dp_pixelformat - Polish commit message - Fix typos - Drop self-explanatory comments Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-2-gwan-gyeong.mun@intel.com
2020-03-20Merge tag 'amd-drm-next-5.7-2020-03-19' of git://people.freedesktop.org/~agd5f/linux into drm-nextDave Airlie1-3/+6
amd-drm-next-5.7-2020-03-19: amdgpu: - SR-IOV fixes - RAS fixes - Fallthrough cleanups - Kconfig fix for ACP - Fix load balancing with VCN - DC fixes - GPU reset fixes - Various cleanups scheduler: - Revert job distribution optimization - Add a helper to pick the least loaded scheduler Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200319175418.4237-1-alexander.deucher@amd.com
2020-03-18drm/i915/tgl: Add new PCI IDs to TGLSwathi Dhanavanthri1-2/+6
Adding 4 new PCI IDs to TGL Bspec: 44455 Signed-off-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318221240.8180-1-swathi.dhanavanthri@intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2020-03-19Merge tag 'drm-misc-next-2020-03-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-nextDave Airlie5-7/+34
drm-misc-next for 5.7: UAPI Changes: Cross-subsystem Changes: Core Changes: - dp-mst: Remove register_connector callback, add drm_dp_destroy_connector - Changes to scnprintf on multiple instances Driver Changes: - meson: Support for YUV420 - panel: Support Ortustech COM37H3M, idk-1110wr and idk-2121wr, multiple dotclock fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200317082858.lubmvlmvoprn2tuh@gilmour.lan
2020-03-19Merge tag 'drm-intel-next-2020-03-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-nextDave Airlie2-4/+18
UAPI Changes: On i915 we have a new UAPI to allow userspace to specify CS ring buffer size on construction (I915_CONTEXT_PARAM_RINGSIZE) and also new sysfs entries exposing various engine properties GVT Changes: VFIO edid getting expanded to all platforms and a big cleanup around attr group, unused vblank complete, kvmgt, Intel engine and dev_priv usages. i915 Changes: - new UAPI to allow userspace to specify CS ring buffer size on construction (I915_CONTEXT_PARAM_RINGSIZE) - (Chris) - New sysfs entries exposing various engine properties (Chris) - Tiger Lake is out of require_force_probe protection (Jose) - Changes in many places around active requests, reset and heartbeat (Chris) - Stop assigning drm-dev_private pointer (Jani) - Many code refactor in many places, including intel_modeset_init, increasing use of intel_uncore_*, vgpu, and gvt stuff (Jani) - Fixes around display pipe iterators (Anshuman) - Tigerlake enabling work (Matt Ropper, Matt Atwood, Ville, Lucas, Daniele, Jose, Anusha, Vivek, Swathi, Caz. Kai) - Code clean-up like reducing use of drm/i915_drv.h, removing unused registers, removing garbage warns, and some other code polishing (Jani, Lucas, Ville) - Selftests fixes, improvements and additions (Chris, Dan, Aditya, Matt Auld) - Fix plane possible_crtcs bit mask (Anshuman) - Fixes and cleanup on GLK pre production identification and w/a (Ville) - Fix display orientation on few cases (Hans, Ville) - dbuf clean-up and improvements for slice arrays handling (Ville) - Improvement around min cdclk calculation (Stanislav) - Fixes and refactor around display PLLs (Imre) - Other execlists and perf fixes (Chris) - Documentation fixes (Jani, Chris) - Fix build issue (Anshuman) - Many more fixes around the locking mechanisms (Chris) - Other fixes and debugability info around preemption (Chris, Tvrtko) - Add mechanism to submit a context WA on ring submission (Mika) - Clear all Eu/L3 resitual context (Prathap) - More changes around local memory (Abdiel, Matt, Chris) - Fix RPS (Chris) - DP MST fix (Lyude) - Display FBC fixes (Jose, RK) - debugfs cleanup (Tvrtko) - More convertion towards drm_debive based loggin (Wambui, Ram) - Avoid potential buffer overflow (Takashi) - Ice Lake and Elkhart Lake workarounds (Matt Roper) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200314001535.GA2969344@intel.com
2020-03-18drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v3)Mario Kleiner1-0/+7
This fixes a problem found on the MacBookPro 2017 Retina panel. The panel reports 10 bpc color depth in its EDID, and the firmware chooses link settings at boot which support enough bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc), but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps (multiplier value 0xa) as possible, in direct contradiction of what the firmware successfully set up. This restricts the panel to 8 bpc, not providing the full color depth of the panel. This patch adds a quirk specific to the MBP 2017 15" Retina panel to add the additiional 324000 kbps link rate during edp setup. Link to previous discussion of a different attempted fix with Ville and Jani: https://patchwork.kernel.org/patch/11325935/ v2: Follow Jani's proposal of defining quirk_rates[] instead of just appending 324000. This for better clarity. v3: Rebased onto current drm-tip, as of 16-March-2020. Adapt to new edid_quirks parameter of drm_dp_has_quirk(). Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200316042340.4783-1-mario.kleiner.de@gmail.com
2020-03-18drm: convert .debugfs_init() hook to return void.Wambui Karuga4-4/+4
As a result of commit 987d65d01356 (drm: debugfs: make drm_debugfs_create_files() never fail) and changes to various debugfs functions in drm/core and across various drivers, there is no need for the drm_driver.debugfs_init() hook to have a return value. Therefore, declare it as void. This also includes refactoring all users of the .debugfs_init() hook to return void across the subsystem. v2: include changes to the hook and drivers that use it in one patch to prevent driver breakage and enable individual successful compilation of this change. References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200310133121.27913-18-wambui.karugax@gmail.com
2020-03-18drm: Validate encoder->possible_crtcsVille Syrjälä1-1/+1
WARN if the encoder possible_crtcs is effectively empty or contains bits for non-existing crtcs. v2: Move to drm_mode_config_validate() (Daniel) Make the docs say we WARN when this is wrong (Daniel) Extract full_crtc_mask() Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211162208.16224-7-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-03-18drm: Validate encoder->possible_clonesVille Syrjälä1-0/+2
Many drivers are populating encoder->possible_clones wrong. Let's persuade them to get it right by adding some loud WARNs. We'll cross check the bits between any two encoders. So either both encoders can clone with the other, or neither can. We'll also complain about effectively empty possible_clones, and possible_clones containing bits for encoders that don't exist. v2: encoder->possible_clones now includes the encoder itelf v3: Move to drm_mode_config_validate() (Daniel) Document that you get a WARN when this is wrong (Daniel) Extract full_encoder_mask() v4: !! instead of ! (Daniel) Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211162208.16224-6-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-03-18drm: Include the encoder itself in possible_clonesVille Syrjälä1-1/+3
The docs say possible_clones should always include the encoder itself. Since most drivers don't want to deal with the complexities of cloning let's allow them to set possible_clones=0 and instead we'll fix that up in the core. We can't put this special case into drm_encoder_init() because drivers will have to fill up possible_clones after adding all the relevant encoders. Otherwise they wouldn't know the proper encoder indexes to use. So we'll just do it just before registering the device. v2: Don't set the bit if possible_clones!=0 so that the validation (coming soon) will WARN (Thomas) Fix up the docs to allow possible_clones==0 (Daniel) .late_register() is too late, introduce drm_mode_config_validate() which gets called _before_ we register the char device (Daniel) Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211162208.16224-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-03-18drm/debugfs: remove checks for return value of drm_debugfs functions.Wambui Karuga1-9/+7
Since 987d65d01356 (drm: debugfs: make drm_debugfs_create_files() never fail), there is no need to check the return value of drm_debugfs_create_files(). Therefore, remove remove unnecessary checks and error handling statement blocks for its return value. These changes also enable changing drm_debugfs_create_files() to return void. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200310133121.27913-17-wambui.karugax@gmail.com
2020-03-18drm/edid: Swap some operands in for_each_displayid_db()Ville Syrjälä1-1/+1
A+B on the previous line, B+A on the next line. Brain hurts. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-3-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-18drm: Constify topology idVille Syrjälä1-2/+2
Make the topology id const since we don't want to change it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-2-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-18drm/core: Add drm_afbc_framebuffer and a corresponding helperAndrzej Pietrasiewicz2-0/+55
The new struct contains afbc-specific data. The new function can be used by drivers which support afbc to complete the preparation of struct drm_afbc_framebuffer. It must be called after allocating the said struct and calling drm_gem_fb_init_with_funcs(). Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: James Qian Wang <james.qian.wang@arm.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200311145541.29186-3-andrzej.p@collabora.com
2020-03-18drm/core: Allow drivers allocate a subclass of struct drm_framebufferAndrzej Pietrasiewicz1-0/+5
Allow allocating a specialized version of struct drm_framebuffer by moving the actual fb allocation out of drm_gem_fb_create_with_funcs(); the respective functions names are adjusted to reflect that fact. Please note, though, that standard size checks are performed on buffers, so the drm_gem_fb_init_with_funcs() is useful for cases where those standard size checks are appropriate or at least don't conflict the checks to be performed in the specialized case. Thanks to this change the drivers can call drm_gem_fb_init_with_funcs() having allocated their special version of struct drm_framebuffer, exactly the way the new version of drm_gem_fb_create_with_funcs() does. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: James Qian Wang <james.qian.wang@arm.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200311145541.29186-2-andrzej.p@collabora.com
2020-03-17Merge drm/drm-next into drm-misc-nextMaxime Ripard2-0/+9
Jernej needs some patches that got merged in -rc5. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2020-03-16drm/sched: implement and export drm_sched_pick_bestNirmoy Das1-0/+3
Remove drm_sched_entity_get_free_sched() and use the logic of picking the least loaded drm scheduler from a drm scheduler list to implement drm_sched_pick_best(). This patch also exports drm_sched_pick_best() so that it can be utilized by other drm drivers. Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-16Revert "drm/scheduler: improve job distribution with multiple queues"changzhu1-3/+3
It needs to revert this patch to avoid amdgpu_test compute hang problem on picasso. This reverts commit 56822db194232c089601728d68ed078dccb97f8b. Signed-off-by: changzhu <Changfeng.Zhu@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-16drm/mm: Allow drm_mm_initialized() to be used outside of the locksChris Wilson1-1/+1
Mark up the potential racy read in drm_mm_initialized(), as we want a cheap and cheerful check: [ 121.098731] BUG: KCSAN: data-race in _i915_gem_object_create_stolen [i915] / rm_hole [ 121.098766] [ 121.098789] write (marked) to 0xffff8881f01ed330 of 8 bytes by task 3568 on cpu 3: [ 121.098831] rm_hole+0x64/0x140 [ 121.098860] drm_mm_insert_node_in_range+0x3d3/0x6c0 [ 121.099254] i915_gem_stolen_insert_node_in_range+0x91/0xe0 [i915] [ 121.099646] _i915_gem_object_create_stolen+0x9d/0x100 [i915] [ 121.100047] i915_gem_object_create_region+0x7a/0xa0 [i915] [ 121.100451] i915_gem_object_create_stolen+0x33/0x50 [i915] [ 121.100849] intel_engine_create_ring+0x1af/0x280 [i915] [ 121.101242] __execlists_context_alloc+0xce/0x3d0 [i915] [ 121.101635] execlists_context_alloc+0x25/0x40 [i915] [ 121.102030] intel_context_alloc_state+0xb6/0xf0 [i915] [ 121.102420] __intel_context_do_pin+0x1ff/0x220 [i915] [ 121.102815] i915_gem_do_execbuffer+0x46b4/0x4c20 [i915] [ 121.103211] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 121.103244] drm_ioctl_kernel+0xe4/0x120 [ 121.103269] drm_ioctl+0x297/0x4c7 [ 121.103296] ksys_ioctl+0x89/0xb0 [ 121.103321] __x64_sys_ioctl+0x42/0x60 [ 121.103349] do_syscall_64+0x6e/0x2c0 [ 121.103377] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 121.103403] [ 121.103426] read to 0xffff8881f01ed330 of 8 bytes by task 3109 on cpu 1: [ 121.103819] _i915_gem_object_create_stolen+0x30/0x100 [i915] [ 121.104228] i915_gem_object_create_region+0x7a/0xa0 [i915] [ 121.104631] i915_gem_object_create_stolen+0x33/0x50 [i915] [ 121.105025] intel_engine_create_ring+0x1af/0x280 [i915] [ 121.105420] __execlists_context_alloc+0xce/0x3d0 [i915] [ 121.105818] execlists_context_alloc+0x25/0x40 [i915] [ 121.106202] intel_context_alloc_state+0xb6/0xf0 [i915] [ 121.106595] __intel_context_do_pin+0x1ff/0x220 [i915] [ 121.106985] i915_gem_do_execbuffer+0x46b4/0x4c20 [i915] [ 121.107375] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 121.107409] drm_ioctl_kernel+0xe4/0x120 [ 121.107437] drm_ioctl+0x297/0x4c7 [ 121.107464] ksys_ioctl+0x89/0xb0 [ 121.107489] __x64_sys_ioctl+0x42/0x60 [ 121.107511] do_syscall_64+0x6e/0x2c0 [ 121.107535] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200309121529.16497-1-chris@chris-wilson.co.uk
2020-03-13drm/dp_mst: Convert drm_dp_mst_topology_mgr.is_waiting_for_dwn_reply to bitfieldLyude Paul1-5/+5
Small nitpick that I noticed a second ago - we can save some space in the struct by making this a bitfield and sticking it with the rest of the bitfields. Also, some small cleanup to the kdocs for this member. There should be no functional changes in this patch. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200122194846.16025-1-lyude@redhat.com
2020-03-13Merge tag 'amd-drm-next-5.7-2020-03-10' of git://people.freedesktop.org/~agd5f/linux into drm-nextDave Airlie1-0/+4
amd-drm-next-5.7-2020-03-10: amdgpu: - SR-IOV fixes - Fix up fallout from drm load/unload callback removal - Navi, renoir power management watermark fixes - Refactor smu parameter handling - Display FEC fixes - Display DCC fixes - HDCP fixes - Add support for USB-C PD firmware updates - Pollock detection fix - Rework compute ring priority handling - RAS fixes - Misc cleanups amdkfd: - Consolidate more gfx config details in amdgpu - Consolidate bo alloc flags - Improve code comments - SDMA MQD fixes - Misc cleanups gpu scheduler: - Add suport for modifying the sched list uapi: - Clarify comments about GEM_CREATE flags that are not used by userspace. The kernel driver has always prevented userspace from using these. They are only used internally in the kernel driver. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310212748.4519-1-alexander.deucher@amd.com
2020-03-12drm/dp_mst: Use full_pbn instead of available_pbn for bandwidth checksLyude Paul1-2/+2
DisplayPort specifications are fun. For a while, it's been really unclear to us what available_pbn actually does. There's a somewhat vague explanation in the DisplayPort spec (starting from 1.2) that partially explains it: The minimum payload bandwidth number supported by the path. Each node updates this number with its available payload bandwidth number if its payload bandwidth number is less than that in the Message Transaction reply. So, it sounds like available_pbn represents the smallest link rate in use between the source and the branch device. Cool, so full_pbn is just the highest possible PBN that the branch device supports right? Well, we assumed that for quite a while until Sean Paul noticed that on some MST hubs, available_pbn will actually get set to 0 whenever there's any active payloads on the respective branch device. This caused quite a bit of confusion since clearing the payload ID table would end up fixing the available_pbn value. So, we just went with that until commit cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") started breaking people's setups due to us getting erroneous available_pbn values. So, we did some more digging and got confused until we finally looked at the definition for full_pbn: The bandwidth of the link at the trained link rate and lane count between the DP Source device and the DP Sink device with no time slots allocated to VC Payloads, represented as a Payload Bandwidth Number. As with the Available_Payload_Bandwidth_Number, this number is determined by the link with the lowest lane count and link rate. That's what we get for not reading specs closely enough, hehe. So, since full_pbn is definitely what we want for doing bandwidth restriction checks - let's start using that instead and ignore available_pbn entirely. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Sean Paul <sean@poorly.run> Reviewed-by: Mikita Lipski <mikita.lipski@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234623.547525-3-lyude@redhat.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Hans de Goede <hdegoede@redhat.com>
2020-03-12Merge tag 'drm-misc-next-2020-03-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-nextDave Airlie5-41/+11
drm-misc-next for 5.7: UAPI Changes: Cross-subsystem Changes: Core Changes: Driver Changes: - fb-helper: Remove drm_fb_helper_{add,add_all,remove}_one_connector - fbdev: some cleanups and dead-code removal - Conversions to simple-encoder - zero-length array removal - Panel: panel-dpi support in panel-simple, Novatek NT35510, Elida KD35T133, Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200309135439.dicfnbo4ikj4tkz7@gilmour
2020-03-11drm/dp_mst: Remove register_connector callbackPankaj Bharadiya1-1/+0
Now drm_dp_mst_topology_cbs.register_connector callback is not getting used anymore hence remove it. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-4-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-03-11drm/edid: Add function to parse EDID descriptors for monitor rangeManasi Navare1-0/+22
Adaptive Sync is a VESA feature so add a DRM core helper to parse the EDID's detailed descritors to obtain the adaptive sync monitor range. Store this info as part fo drm_display_info so it can be used across all drivers. This part of the code is stripped out of amdgpu's function amdgpu_dm_update_freesync_caps() to make it generic and be used across all DRM drivers v6: * Call it monitor_range (Ville) v5: * Use the renamed flags v4: * Use is_display_descriptor() (Ville) * Name the monitor range flags (Ville) v3: * Remove the edid parsing restriction for just DP (Nicholas) * Use drm_for_each_detailed_block (Ville) * Make the drm_get_adaptive_sync_range function static (Harry, Jani) v2: * Change vmin and vmax to use u8 (Ville) * Dont store pixel clock since that is just a max dotclock and not related to VRR mode (Manasi) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-2-manasi.d.navare@intel.com
2020-03-11drm/edid: Name the detailed monitor range flagsManasi Navare1-0/+5
This patch adds defines for the detailed monitor range flags as per the EDID specification. v2: * Rename the flags with DRM_EDID_ (Jani N) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-1-manasi.d.navare@intel.com
2020-03-11Merge v5.6-rc5 into drm-nextDave Airlie1-0/+5
Requested my mripard for some misc patches that need this as a base. Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-03-10drm/bridge: synopsys: dw-hdmi: allow ycbcr420 modes for >= 0x200aNeil Armstrong1-0/+1
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support for these modes in the connector if the platform supports them. We limit these modes to DW-HDMI IP version >= 0x200a which are designed to support HDMI2.0 display modes. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-6-narmstrong@baylibre.com
2020-03-09drm/scheduler: implement a function to modify sched listNirmoy Das1-0/+4
Implement drm_sched_entity_modify_sched() which modifies existing sched_list with a different one. This is going to be helpful when userspace changes priority of a ctx/entity then the driver can switch to the corresponding HW scheduler list for that priority. Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-06drm/pci: Unexport drm_get_pci_devDaniel Vetter1-11/+0
Only user left is the shadow attach for legacy drivers. v2: Shift the #ifdef CONFIG_DRM_LEGACY to now also include drm_get_pci_dev() (Thomas) Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225165835.2394442-1-daniel.vetter@ffwll.ch
2020-03-06drm/fb-helper: Remove drm_fb_helper add, add_all and remove connector functionsPankaj Bharadiya1-21/+0
drm_fb_helper_single_add_all_connectors(), drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector() don't keep an array of connectors anymore and are just dummy. Now we have no callers to these functions hence remove them. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-7-pankaj.laxminarayan.bharadiya@intel.com
2020-03-06drm: Remove unused arg from drm_fb_helper_initPankaj Bharadiya1-4/+2
The max connector argument for drm_fb_helper_init() isn't used anymore hence remove it. All the drm_fb_helper_init() calls are modified with below sementic patch. @@ expression E1, E2, E3; @@ - drm_fb_helper_init(E1,E2, E3) + drm_fb_helper_init(E1,E2) Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-2-pankaj.laxminarayan.bharadiya@intel.com
2020-03-06drm/bridge/mhl.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-2/+2
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305110011.GA21056@embeddedor
2020-03-03drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panelLyude Paul1-0/+10
The X1 Extreme is one of the systems that lies about which backlight interface that it uses in its VBIOS as PWM backlight controls don't work at all on this machine. It's possible that this panel could be one of the infamous ones that can switch between PWM mode and DPCD backlight control mode, but we haven't gotten any more details on this from Lenovo just yet. For the time being though, making sure the backlight 'just works' is a bit more important. So, add a quirk to force DPCD backlight controls on for these systems based on EDID (since this panel doesn't appear to fill in the device ID). Hopefully in the future we'll figure out a better way of probing this. Changes since v2: * The bugzilla URL is deprecated, bug reporting happens on gitlab now. Update the messages we print to reflect this * Also, take the opportunity to move FDO_BUG_URL out of i915_utils.c and into i915_utils.h so that other places which print things that aren't traditional errors but are worth filing bugs about, can actually use it. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303215320.93491-1-lyude@redhat.com
2020-03-03drm/dp: Introduce EDID-based quirksLyude Paul1-3/+8
The whole point of using OUIs is so that we can recognize certain devices and potentially apply quirks for them. Normally this should work quite well, but there appears to be quite a number of laptop panels out there that will fill the OUI but not the device ID. As such, for devices like this I can't imagine it's a very good idea to try relying on OUIs for applying quirks. As well, some laptop vendors have confirmed to us that their panels have this exact issue. So, let's introduce the ability to apply DP quirks based on EDID identification. We reuse the same quirk bits for OUI-based quirks, so that callers can simply check all possible quirks using drm_dp_has_quirk(). Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-2-lyude@redhat.com
2020-03-04drm/hdcp: fix DRM_HDCP_2_KSV_COUNT_2_LSBITSRamalingam C1-1/+1
Need to extract the 2 most significant bits from a byte for constructing the revoked KSV count of the SRM. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212102942.26568-3-ramalingam.c@intel.com
2020-03-04drm/hdcp: optimizing the srm handlingRamalingam C1-2/+2
As we are not using the sysfs infrastructure anymore, link to it is removed. And global srm data and mutex to protect it are removed, with required handling at revocation check function. v2: srm_data is dropped and few more comments are addressed. v3: ptr passing around is fixed with functional testing. v4: fix htmldoc [lkp] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Suggested-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200212102942.26568-2-ramalingam.c@intel.com
2020-03-02drm/simple-kms: Add drm_simple_encoder_{init,create}()Thomas Zimmermann1-0/+4
This patch makes the internal encoder implementation of the simple KMS helpers available to drivers. These simple-encoder helpers initialize an encoder with an empty implementation. This covers the requirements of most of the existing DRM drivers. A call to drm_simple_encoder_create() allocates and initializes an encoder instance, a call to drm_simple_encoder_init() initializes a pre-allocated instance. v3: * remove drm_simple_encoder_create(); not required yet * provide more precise documentation v2: * move simple encoder to KMS helpers * remove name argument; simplifies implementation * don't allocate with devm_ interfaces; unsafe with DRM Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200228081828.18463-2-tzimmermann@suse.de
2020-02-27drm/shmem: add support for per object caching flags.Gerd Hoffmann1-0/+5
Add map_cached bool to drm_gem_shmem_object, to request cached mappings on a per-object base. Check the flag before adding writecombine to pgprot bits. Cc: stable@vger.kernel.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Guillaume Gardet <Guillaume.Gardet@arm.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200226154752.24328-2-kraxel@redhat.com
2020-02-27drm/i915: significantly reduce the use of <drm/i915_drm.h>Jani Nikula1-1/+0
The #include has been splattered all over the place, but there are precious few places, all .c files, that actually need it. v2: remove leftover double newlines Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225133131.3301-1-jani.nikula@intel.com
2020-02-26drm: Add helper to create a connector for a chain of bridgesLaurent Pinchart1-0/+18
Most bridge drivers create a DRM connector to model the connector at the output of the bridge. This model is historical and has worked pretty well so far, but causes several issues: - It prevents supporting more complex display pipelines where DRM connector operations are split over multiple components. For instance a pipeline with a bridge connected to the DDC signals to read EDID data, and another one connected to the HPD signal to detect connection and disconnection, will not be possible to support through this model. - It requires every bridge driver to implement similar connector handling code, resulting in code duplication. - It assumes that a bridge will either be wired to a connector or to another bridge, but doesn't support bridges that can be used in both positions very well (although there is some ad-hoc support for this in the analogix_dp bridge driver). In order to solve these issues, ownership of the connector needs to be moved to the display controller driver. To avoid code duplication in display controller drivers, add a new helper to create and manage a DRM connector backed by a chain of bridges. All connector operations are delegating to the appropriate bridge in the chain. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-21-laurent.pinchart@ideasonboard.com
2020-02-26drm/bridge: Extend bridge API to disable connector creationLaurent Pinchart1-3/+17
Most bridge drivers create a DRM connector to model the connector at the output of the bridge. This model is historical and has worked pretty well so far, but causes several issues: - It prevents supporting more complex display pipelines where DRM connector operations are split over multiple components. For instance a pipeline with a bridge connected to the DDC signals to read EDID data, and another one connected to the HPD signal to detect connection and disconnection, will not be possible to support through this model. - It requires every bridge driver to implement similar connector handling code, resulting in code duplication. - It assumes that a bridge will either be wired to a connector or to another bridge, but doesn't support bridges that can be used in both positions very well (although there is some ad-hoc support for this in the analogix_dp bridge driver). In order to solve these issues, ownership of the connector should be moved to the display controller driver (where it can be implemented using helpers provided by the core). Extend the bridge API to allow disabling connector creation in bridge drivers as a first step towards the new model. The new flags argument to the bridge .attach() operation allows instructing the bridge driver to skip creating a connector. Unconditionally set the new flags argument to 0 for now to keep the existing behaviour, and modify all existing bridge drivers to return an error when connector creation is not requested as they don't support this feature yet. The change is based on the following semantic patch, with manual review and edits. @ rule1 @ identifier funcs; identifier fn; @@ struct drm_bridge_funcs funcs = { ..., .attach = fn }; @ depends on rule1 @ identifier rule1.fn; identifier bridge; statement S, S1; @@ int fn( struct drm_bridge *bridge + , enum drm_bridge_attach_flags flags ) { ... when != S + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) { + DRM_ERROR("Fix bridge driver to make connector optional!"); + return -EINVAL; + } + S1 ... } @ depends on rule1 @ identifier rule1.fn; identifier bridge, flags; expression E1, E2, E3; @@ int fn( struct drm_bridge *bridge, enum drm_bridge_attach_flags flags ) { <... drm_bridge_attach(E1, E2, E3 + , flags ) ...> } @@ expression E1, E2, E3; @@ drm_bridge_attach(E1, E2, E3 + , 0 ) Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com
2020-02-26drm/bridge: Add interlace_allowed flag to drm_bridgeLaurent Pinchart1-0/+5
In preparation for a connector creation helper based on a chain of bridges, add a flag to the drm_bridge structure to report support for interlaced modes. This will be used to set the connector's interlace_allowed flag. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-9-laurent.pinchart@ideasonboard.com
2020-02-26drm/bridge: Add connector-related bridge operations and dataLaurent Pinchart1-1/+191
To support implementation of DRM connectors on top of DRM bridges instead of by bridges, the drm_bridge needs to expose new operations and data: - Output detection, hot-plug notification, mode retrieval and EDID retrieval operations - Bitmask of supported operations - Bridge output type - I2C adapter for DDC access Add and document these. Three new bridge helper functions are also added to handle hot plug notification in a way that is as transparent as possible for the bridges. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-8-laurent.pinchart@ideasonboard.com
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.