aboutsummaryrefslogtreecommitdiff
path: root/include/drm
AgeCommit message (Collapse)AuthorFilesLines
2020-04-03drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connectorLyude Paul1-2/+0
Now that we've removed the last user of this callback, get rid of it and drm_dp_destroy_connector(). Signed-off-by: Lyude Paul <[email protected]> Cc: Pankaj Bharadiya <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Alex Deucher <[email protected]>
2020-04-03drm: delete drm_pci.hDaniel Vetter1-37/+0
It's empty! After more than 20 years of OS abstraction layer for pci devices, it's kinda gone now. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-03drm/pci: Move drm_pci_alloc/free under CONFIG_DRM_LEGACYDaniel Vetter2-26/+15
All other users have been removed, yay! Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> [fix checkpatch warning] Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-03Merge branch 'ttm-transhuge' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie2-1/+11
into drm-next Huge page-table entries for TTM In order to reduce CPU usage [1] and in theory TLB misses this patchset enables huge- and giant page-table entries for TTM and TTM-enabled graphics drivers. Signed-off-by: Dave Airlie <[email protected]> From: Thomas Hellstrom (VMware) <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-01drm/core: Calculate bpp in afbc helperAndrzej Pietrasiewicz1-7/+0
Some drivers (komeda, malidp) don't set anything in cpp. If that is the case the right value can be inferred from the format. Then the "bpp" member can be eliminated from struct drm_afbc_framebuffer. Signed-off-by: Andrzej Pietrasiewicz <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-31Merge v5.6 into drm-nextDave Airlie1-2/+2
msm needed rc6, so I just went and merged release (msm has been in drm-next outside of this tree) Signed-off-by: Dave Airlie <[email protected]>
2020-03-30drm/fb: fix kernel-doc in drm_framebuffer.hSam Ravnborg1-2/+2
Fix following warnings: drm_framebuffer.h:342: warning: Function parameter or member 'block_width' not described in 'drm_afbc_framebuffer' drm_framebuffer.h:342: warning: Function parameter or member 'block_height' not described in 'drm_afbc_framebuffer' Trivial spelling mistakes. Signed-off-by: Sam Ravnborg <[email protected]> Acked-by: Andrzej Pietrasiewicz <[email protected]> Fixes: 55f7f72753ab ("drm/core: Add drm_afbc_framebuffer and a corresponding helper") Cc: Andrzej Pietrasiewicz <[email protected]> Cc: Emil Velikov <[email protected]> Cc: James Qian Wang <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-30drm/dp_mst: add kernel-doc for drm_dp_mst_port.fec_capableSam Ravnborg1-0/+4
Fix kernel-doc warnings for drm_dp_mst_port.fec_capable. This fixed the following warning: drm_dp_mst_helper.h:162: warning: Function parameter or member 'fec_capable' not described in 'drm_dp_mst_port' Signed-off-by: Sam Ravnborg <[email protected]> Cc: David Francis <[email protected]> Cc: Lyude Paul <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Mikita Lipski <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> [Wrapped commit msg + s/network/topology] Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-30drm: rework SET_MASTER and DROP_MASTER perm handlingEmil Velikov1-0/+11
This commit reworks the permission handling of the two ioctls. In particular it enforced the CAP_SYS_ADMIN check only, if: - we're issuing the ioctl from process other than the one which opened the node, and - we are, or were master in the past This ensures that we: - do not regress the systemd-logind style of DRM_MASTER arbitrator - allow applications which do not use systemd-logind to drop their master capabilities (and regain them at later point) ... w/o running as root. See the comment above drm_master_check_perm() for more details. v1: - Tweak wording, fixup all checks, add igt test v2: - Add a few more comments, grammar nitpicks. Cc: Adam Jackson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Pekka Paalanen <[email protected]> Testcase: igt/core_setmaster/master-drop-set-user Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Adam Jackson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-27drm/dp_mst: Remove single tx msg restriction.Sean Paul1-5/+0
Now that we can support multiple simultaneous replies, remove the restrictions placed on sending new tx msgs. This patch essentially just reverts commit 5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time") now that the problem is solved in a different way. Cc: Wayne Lin <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-27drm/mst: Support simultaneous down repliesSean Paul1-29/+30
Currently we have one down reply message servicing the mst manager, so we need to serialize all tx msgs to ensure we only have one message in flight at a time. For obvious reasons this is suboptimal (but less suboptimal than the free-for-all we had before serialization). This patch removes the single down_rep_recv message from manager and adds 2 replies in the branch structure. The 2 replies mirrors the tx_slots which we use to rate-limit outgoing messages and correspond to seqno in the packet headers. Cc: Wayne Lin <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Add docs for managed resourcesDaniel Vetter2-0/+59
All collected together to provide a consistent story in one patch, instead of the somewhat bumpy refactor-evolution leading to this. Also some thoughts on what the next steps could be: - Create a macro called devm_drm_dev_alloc() which essentially wraps the kzalloc(); devm_drm_dev_init(); drmm_add_final_kfree() combo. Needs to be a macro since we'll have to do some typeof trickery and casting to make this fully generic for all drivers that embed struct drm_device into their own thing. - A lot of the simple drivers now have essentially just drm_dev_unplug(); drm_atomic_helper_shutdown(); as their $bus_driver->remove hook. We could create a devm_mode_config_reset which sets drm_atomic_helper_shutdown as it's cleanup action, and a devm_drm_dev_register with drm_dev_unplug as it's cleanup action, and simple drivers wouldn't have a need for a ->remove function at all, and we could delete them. - For more complicated drivers we need drmm_ versions of a _lot_ more things. All the userspace visible objects (crtc, plane, encoder, crtc), anything else hanging of those (maybe a drmm_get_edid, at least for panels and other built-in stuff). Also some more thoughts on why we're not reusing devm_ with maybe a fake struct device embedded into the drm_device (we can't use the kdev, since that's in each drm_minor). - Code review gets extremely tricky, since every time you see a devm_ you need to carefully check whether the fake device (with the drm_device lifetim) or the real device (with the lifetim of the underlying physical device and driver binding) are used. That's not going to help at all, and we have enormous amounts of drivers who use devm_ where they really shouldn't. Having different types makes sure the compiler type checks this for us and ensures correctness. - The set of functions are very much non-overlapping. E.g. devm_ioremap makes total sense, drmm_ioremap has the wrong lifetime, since hw resources need to be cleaned out at driver unbind and wont outlive that like a drm_device. Similar, but other way round for drmm_connector_init (which is the only correct version, devm_ for drm_connector is just buggy). Simply not having the wrong version again prevents bugs. Finally I guess this opens a huge todo for all the drivers. I'm semi-tempted to do a tree-wide s/devm_kzalloc/drmm_kzalloc/ since most likely that'll fix an enormous amount of bugs and most likely not cause any issues at all (aside from maybe holding onto memory slightly too long). v2: - Doc improvements from Laurent. - Also add kerneldoc for the new drmm_add_action_or_reset. v3: - Remove kerneldoc for drmm_remove_action. Reviewed-by: Sam Ravnborg <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: [email protected] Cc: Laurent Pinchart <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> fixup docs Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm/mipi-dbi: Drop explicit drm_mode_config_cleanup callDaniel Vetter1-1/+0
Allows us to drop the drm_driver.release callback from all drivers, and remove the mipi_dbi_release() function. This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Cc: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Laurent Pinchart <[email protected]> Reviewed-by: Noralf Trønnes <[email protected]> (v2) Tested-by: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Eric Anholt <[email protected]> Cc: David Lechner <[email protected]> Cc: Kamlesh Gurudasani <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Manage drm_mode_config_init with drmm_Daniel Vetter1-1/+17
drm_mode_config_cleanup is idempotent, so no harm in calling this twice. This allows us to gradually switch drivers over by removing explicit drm_mode_config_cleanup calls. With this step it's now also possible that (at least for simple drivers) automatic resource cleanup can be done correctly without a drm_driver->release hook. Therefore allow this now in devm_drm_dev_init(). Also with drmm_ explicit drm_driver->release hooks are kinda not the best option: Drivers can always just register their current release hook with drmm_add_action, but even better they could split them up to simplify the unwinding for the driver load failure case. So deprecate that hook to discourage future users. v2: Fixup the example in the kerneldoc too. v3: - For paranoia, double check that minor->dev == dev in the release hook, because I botched the pointer math in the drmm library. - Call drm_mode_config_cleanup when drmm_add_action fails, we'd be missing some mutex_destroy and ida_cleanup otherwise (Laurent) v4: Add a drmm_add_action_or_reset (like devm_ has) to encapsulate this pattern (Noralf). v5: Fix oversight in the new drmm_add_action_or_reset macro (Noralf) v4: Review from Sam: - drmm_mode_config_init wrapper (also suggested by Thomas) - improve commit message, explain better why ->relase is deprecated v5: - Make drmm_ the main function, with the old one as compat wrapper (Sam) - Add FIXME comments to drm_mode_config_cleanup/init() that drivers shouldn't use these anymore. - Move drmm_add_action_or_reset helper to an earlier patch. Reviewed-by: Sam Ravnborg <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Garbage collect drm_dev_finiDaniel Vetter1-4/+1
It has become empty. Given the few users I figured not much point splitting this up. v2: Rebase over i915 changes. v3: Rebase over patch split fix. Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: Manage drm_vblank_cleanup with drmm_Daniel Vetter1-0/+16
Nothing special here, except that this is the first time that we automatically clean up something that's initialized with an explicit driver call. But the cleanup was done at the very end of the release sequence for all drivers, and that's still the case. At least without more uses of drmm_ through explicit driver calls. Also for this one we need drmm_kcalloc, so lets add those. The motivation here is to allow us to remove the explicit calls to drm_dev_fini() from all drivers. v2: Sort includes (Laurent) v3: Motivate the change in the commit message better (Sam) Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-26drm: manage drm_minor cleanup with drmm_Daniel Vetter1-1/+8
The cleanup here is somewhat tricky, since we can't tell apart the allocated minor index from 0. So register a cleanup action first, and if the index allocation fails, unregister that cleanup action again to avoid bad mistakes. The kdev for the minor already handles NULL, so no problem there. Hence add drmm_remove_action() to the drm_managed library. v2: Make pointer math around void ** consistent with what Laurent suggested. v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed because of some questions from Thomas. This also means we need to move the drmm_add_action_or_reset helper earlier in the series. v4: Uh ... fix slightly embarrassing bug CI spotted. Acked-by: Thomas Zimmermann <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
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 <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Neil Armstrong <[email protected] Cc: Greg Kroah-Hartman <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Cc: Michal Hocko <[email protected]> Cc: "Matthew Wilcox (Oracle)" <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Ralph Campbell <[email protected]> Cc: "Jérôme Glisse" <[email protected]> Cc: "Christian König" <[email protected]> Cc: Dan Williams <[email protected]> Signed-off-by: Thomas Hellstrom (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Acked-by: Christian König <[email protected]>
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 <[email protected]> Cc: Michal Hocko <[email protected]> Cc: "Matthew Wilcox (Oracle)" <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Ralph Campbell <[email protected]> Cc: "Jérôme Glisse" <[email protected]> Cc: "Christian König" <[email protected]> Cc: Dan Williams <[email protected]> Signed-off-by: Thomas Hellstrom (VMware) <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Christian König <[email protected]>
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 <[email protected]> Reviewed-by: Noralf Trønnes <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-20Merge tag 'amd-drm-next-5.7-2020-03-19' of ↵Dave Airlie1-3/+6
git://people.freedesktop.org/~agd5f/linux into drm-next 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 <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matt Roper <[email protected]>
2020-03-19Merge tag 'drm-misc-next-2020-03-17' of ↵Dave Airlie5-7/+34
git://anongit.freedesktop.org/drm/drm-misc into drm-next 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 <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-19Merge tag 'drm-intel-next-2020-03-13' of ↵Dave Airlie2-4/+18
git://anongit.freedesktop.org/drm/drm-intel into drm-next 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 <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Tested-by: Mario Kleiner <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
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 <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
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 <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
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 <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Alex Deucher <[email protected]>
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Alex Deucher <[email protected]>
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 <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: James Qian Wang <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: James Qian Wang <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
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 <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
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 <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
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 <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Cc: Wayne Lin <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-13Merge tag 'amd-drm-next-5.7-2020-03-10' of ↵Dave Airlie1-0/+4
git://people.freedesktop.org/~agd5f/linux into drm-next 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 <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") Cc: Mikita Lipski <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Sean Paul <[email protected]> Reviewed-by: Mikita Lipski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Alex Deucher <[email protected]> Tested-by: Hans de Goede <[email protected]>
2020-03-12Merge tag 'drm-misc-next-2020-03-09' of ↵Dave Airlie5-41/+11
git://anongit.freedesktop.org/drm/drm-misc into drm-next 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 <[email protected]> From: Maxime Ripard <[email protected]> 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 <[email protected]> Suggested-by: Emil Velikov <[email protected]> Suggested-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lyude Paul <[email protected]>
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ä <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Clinton A Taylor <[email protected]> Cc: Kazlauskas Nicholas <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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ä <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Clinton A Taylor <[email protected]> Cc: Kazlauskas Nicholas <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.