summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_atomic_uapi.c
AgeCommit message (Collapse)Author
2020-07-02drm : Insert blank lines after declarations.Suraj Upadhyay
Resolve checkpatch issues for missing blank lines after declarations. Issues found in multiple files with checkpatch.pl. Signed-off-by: Suraj Upadhyay <usuraj35@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200702131749.GA25710@blackclown
2019-12-22drm/atomic: Spell CRTC consistentlyThierry Reding
CRTC is an abbreviation and should be all caps in prose. Update all kerneldoc comments to use a consistent spelling. v2: remove hunk unrelated to the CRTC spelling fixes Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191206135336.2084564-2-thierry.reding@gmail.com
2019-10-03Merge drm/drm-next into drm-misc-nextMaxime Ripard
We haven't done any backmerge for a while due to the merge window, and it starts to become an issue for komeda. Let's bring 5.4-rc1 in. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-10-02drm/print: add drm_debug_enabled()Jani Nikula
Add helper to check if a drm debug category is enabled. Convert drm core to use it. No functional changes. v2: Move unlikely() to drm_debug_enabled() (Eric) v3: Keep unlikely() when combined with other conditions (Eric) Cc: Eric Engestrom <eric@engestrom.ch> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Eric Engestrom <eric@engestrom.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191001140614.26909-1-jani.nikula@intel.com
2019-09-18drm/atomic: Reject FLIP_ASYNC unconditionallyDaniel Vetter
It's never been wired up. Only userspace that tried to use it (and didn't actually check whether anything works, but hey it builds) is the -modesetting atomic implementation. And we just shut that up. If there's anyone else then we need to silently accept this flag no matter what, and find a new one. Because once a flag is tainted, it's lost. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Michel Dänzer <michel@daenzer.net> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190903190642.32588-2-daniel.vetter@ffwll.ch
2019-08-13dma-buf: rename reservation_object to dma_resvChristian König
Be more consistent with the naming of the other DMA-buf objects. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/323401/
2019-08-06drm: Add Content protection type propertyRamalingam C
This patch adds a DRM ENUM property to the selected connectors. This property is used for mentioning the protected content's type from userspace to kernel HDCP authentication. Type of the stream is decided by the protected content providers. Type 0 content can be rendered on any HDCP protected display wires. But Type 1 content can be rendered only on HDCP2.2 protected paths. So when a userspace sets this property to Type 1 and starts the HDCP enable, kernel will honour it only if HDCP2.2 authentication is through for type 1. Else HDCP enable will be failed. Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: cp_content_type is replaced with content_protection_type [daniel] check at atomic_set_property is removed [Maarten] v3: %s/content_protection_type/hdcp_content_type [Pekka] v4: property is created for the first requested connector and then reused. [Danvet] v5: kernel doc nits addressed [Daniel] Rebased as part of patch reordering. v6: Kernel docs are modified [pekka] v7: More details in Kernel docs. [pekka] v8: Few more clarification into kernel doc of content type [pekka] v9: Small fixes in coding style. v10: Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14
2019-06-13drm: Add helpers to kick off self refresh mode in driversSean Paul
This patch adds a new drm helper library to help drivers implement self refresh. Drivers choosing to use it will register crtcs and will receive callbacks when it's time to enter or exit self refresh mode. In its current form, it has a timer which will trigger after a driver-specified amount of inactivity. When the timer triggers, the helpers will submit a new atomic commit to shut the refreshing pipe off. On the next atomic commit, the drm core will revert the self refresh state and bring everything back up to be actively driven. From the driver's perspective, this works like a regular disable/enable cycle. The driver need only check the 'self_refresh_active' state in crtc_state. It should initiate self refresh mode on the panel and enter an off or low-power state. Changes in v2: - s/psr/self_refresh/ (Daniel) - integrated the psr exit into the commit that wakes it up (Jose/Daniel) - made the psr state per-crtc (Jose/Daniel) Changes in v3: - Remove the self_refresh_(active|changed) from connector state (Daniel) - Simplify loop in drm_self_refresh_helper_alter_state (Daniel) - Improve self_refresh_aware comment (Daniel) - s/self_refresh_state/self_refresh_data/ (Daniel) Changes in v4: - Move docbook location below panel (Daniel) - Improve docbook with references and more detailed explanation (Daniel) - Instead of register/unregister, use init/cleanup (Daniel) Changes in v5: - Resolved conflict in drm_atomic_helper.c #include block - Resolved conflict in rst with HDCP helper docs Changes in v6: - Fix include ordering, clean up forward declarations (Sam) Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-2-sean@poorly.run Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-1-sean@poorly.run Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-6-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-6-sean@poorly.run Link to v5: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-6-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jose Souza <jose.souza@intel.com> Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190612145026.191846-1-sean@poorly.run
2019-05-28Merge tag 'drm-intel-next-2019-05-24' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next Features: - Engine discovery query (Tvrtko) - Support for DP YCbCr4:2:0 outputs (Gwan-gyeong) - HDCP revocation support, refactoring (Ramalingam) - Remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW (Christian König) - Asynchronous display power disabling (Imre) - Perma-pin uC firmware and re-enable global reset (Fernando) - GTT remapping for display, for bigger fb size and stride (Ville) - Enable pipe HDR mode on ICL if only HDR planes are used (Ville) - Kconfig to tweak the busyspin durations for i915_wait_request (Chris) - Allow multiple user handles to the same VM (Chris) - GT/GEM runtime pm improvements using wakerefs (Chris) - Gen 4&5 render context support (Chris) - Allow userspace to clone contexts on creation (Chris) - SINGLE_TIMELINE flags for context creation (Chris) - Allow specification of parallel execbuf (Chris) Refactoring: - Header refactoring (Jani) - Move GraphicsTechnology files under gt/ (Chris) - Sideband code refactoring (Chris) Fixes: - ICL DSI state readout and checker fixes (Vandita) - GLK DSI picture corruption fix (Stanislav) - HDMI deep color fixes (Clinton, Aditya) - Fix driver unbinding from a device in use (Janusz) - Fix clock gating with pipe scaling (Radhakrishna) - Disable broken FBC on GLK (Daniel Drake) - Miscellaneous GuC fixes (Michal) - Fix MG PHY DP register programming (Imre) - Add missing combo PHY lane power setup (Imre) - Workarounds for early ICL VBT issues (Imre) - Fix fastset vs. pfit on/off on HSW EDP transcoder (Ville) - Add readout and state check for pch_pfit.force_thru (Ville) - Miscellaneous display fixes and refactoring (Ville) - Display workaround fixes (Ville) - Enable audio even if ELD is bogus (Ville) - Fix use-after-free in reporting create.size (Chris) - Sideband fixes to avoid BYT hard lockups (Chris) - Workaround fixes and improvements (Chris) Maintainer shortcomings: - Failure to adequately describe and give credit for all changes (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87sgt3n45z.fsf@intel.com
2019-05-22drm: Add HDR source metadata propertyUma Shankar
This patch adds a blob property to get HDR metadata information from userspace. This will be send as part of AVI Infoframe to panel. It also implements get() and set() functions for HDR output metadata property.The blob data is received from userspace and saved in connector state, the same is returned as blob in get property call to userspace. v2: Rebase and modified the metadata structure elements as per Ville's POC changes. v3: No Change v4: Addressed Shashank's review comments v5: Rebase. v6: Addressed Brian Starkey's review comments, defined new structure with header for dynamic metadata scalability. Merge get/set property functions for metadata in this patch. v7: Addressed Jonas Karlman review comments and defined separate structure for infoframe to better align with CTA 861.G spec. Added Shashank's RB. v8: Addressed Ville's review comments. Moved sink metadata structure out of uapi headers as suggested by Jonas Karlman. v9: Rebase and addressed Jonas Karlman review comments. v10: Addressed Ville's review comments, dropped the metdata_changed state variable as its not needed anymore. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1558015817-12025-2-git-send-email-uma.shankar@intel.com
2019-05-09drm: move content protection property to mode_configRamalingam C
Content protection property is created once and stored in drm_mode_config. And attached to all HDCP capable connectors. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190507162745.25600-2-ramalingam.c@intel.com
2019-04-24drm/atomic: -EACCESS for lease-denied crtc lookupDaniel Vetter
With the previous patch drm_crtc_find will return NULL when the crtc isn't in our lease, which will then disable the plane/connector. No longer an issue since the lessor can't escape their lease terms anymore, but not quite great semantics yet either. Catch this and return -EACCES, so that at least evil test cases have a better chance of making sure the kernel works correctly. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-8-daniel.vetter@ffwll.ch
2019-04-24drm/atomic: Wire file_priv through for property changesDaniel Vetter
We need this to make sure lessees can only connect their plane/connectors to crtc objects they own. And note that this is irrespective of whether the lessor is atomic or not, lessor cannot prevent lessees from enabling atomic. Cc: stable@vger.kernel.org Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-7-daniel.vetter@ffwll.ch
2019-03-25Merge tag 'drm-misc-next-2019-03-21' of ↵Daniel Vetter
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.2: UAPI Changes: - Add Colorspace connector property (Uma) - fourcc: Several new YUV formats from ARM (Brian & Ayan) - fourcc: Fix merge conflicts between new formats above and Swati's that went in via topic/hdr-formats-2019-03-07 branch (Maarten) Cross-subsystem Changes: - Typed component support via topic/component-typed-2019-02-11 (Maxime/Daniel) Core Changes: - Improve component helper documentation (Daniel) - Avoid calling drm_dev_unregister() twice on unplugged devices (Noralf) - Add device managed (devm) drm_device init function (Noralf) - Graduate TINYDRM_MODE to DRM_SIMPLE_MODE in core (Noralf) - Move MIPI/DSI rate control params computation into core from i915 (David) - Add support for shmem backed gem objects (Noralf) Driver Changes: - various: Use of_node_name_eq for node name comparisons (Rob Herring) - sun4i: Add DSI burst mode support (Konstantin) - panel: Add Ronbo RB070D30 MIPI/DSI panel support (Konstantin) - virtio: A few prime improvements (Gerd) - tinydrm: Remove tinydrm_device (Noralf) - vc4: Add load tracker to driver to detect underflow in atomic check (Boris) - vboxvideo: Move it out of staging \o/ (Hans) - v3d: Add support for V3D v4.2 (Eric) Cc: Konstantin Sudakov <k.sudakov@integrasources.com> Cc: Rob Herring <robh@kernel.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: David Francis <David.Francis@amd.com> Cc: Boris Brezillon <boris.brezillon@bootlin.com> Cc: Eric Anholt <eric@anholt.net> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190321170805.GA50145@art_vandelay
2019-03-18drm: writeback: Add job prepare and cleanup operationsLaurent Pinchart
As writeback jobs contain a framebuffer, drivers may need to prepare and cleanup them the same way they can prepare and cleanup framebuffers for planes. Add two new optional connector helper operations, .prepare_writeback_job() and .cleanup_writeback_job() to support this. The job prepare operation is called from drm_atomic_helper_prepare_planes() to avoid a new atomic commit helper that would need to be called by all drivers not using drm_atomic_helper_commit(). The job cleanup operation is called from the existing drm_writeback_cleanup_job() function, invoked both when destroying the job as part of a aborted commit, or when the job completes. The drm_writeback_job structure is extended with a priv field to let drivers store per-job data, such as mappings related to the writeback framebuffer. For internal plumbing reasons the drm_writeback_job structure needs to store a back-pointer to the drm_writeback_connector. To avoid pushing too much writeback-specific knowledge to drm_atomic_uapi.c, create a drm_writeback_set_fb() function, move the writeback job setup code there, and set the connector backpointer. The prepare_signaling() function doesn't need to allocate writeback jobs and can ignore connectors without a job, as it is called after the writeback jobs are allocated to store framebuffers, and a writeback fence with a framebuffer is an invalid configuration that gets rejected by the commit check. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
2019-02-19drm: Add HDMI colorspace propertyUma Shankar
Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-18Merge v5.0-rc7 into drm-nextDave Airlie
Backmerging for nouveau and imx that needed some fixes for next pulls. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-02-04drm: Trivial comment grammar cleanupsMatt Roper
Most of these are just cases where code comments used contractions (it's, who's) where they actually mean to use a possessive pronoun (its, whose) or vice-versa. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190202012326.20096-1-matthew.d.roper@intel.com
2019-01-10gpu/drm: Fix lock held when returning to user space.Tetsuo Handa
We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc() failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc() succeeded. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: syzbot <syzbot+6ea337c427f5083ebdf2@syzkaller.appspotmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1547115571-21219-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
2018-12-06Merge tag 'vmwgfx-next-2018-12-05' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-next Pull request of 2018-12-05 Page flip with damage by Deepak and others, Various vmwgfx minor fixes anc cleanups. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181205103554.3675-1-thellstrom@vmware.com
2018-12-06Merge branch 'drm-next-4.21' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next amdgpu and amdkfd: - Freesync support - ABM support in DC - KFD support for vega12 and polaris12 - Add sdma paging queue support for vega - Use ACPI to query backlight range on supported platforms - Clean up doorbell handling - KFD fix for pasid handling under non-HWS - Misc cleanups and fixes scheduler: - Revert "fix timeout handling v2" radeon: - Fix possible overflow on 32 bit ttm: - Fix for LRU handling for ghost objects Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181130192505.2946-1-alexander.deucher@amd.com
2018-12-05drm: Add a new plane property to send damage during plane updateLukasz Spintzyk
FB_DAMAGE_CLIPS is an optional plane property to mark damaged regions on the plane in framebuffer coordinates of the framebuffer attached to the plane. The layout of blob data is simply an array of "struct drm_mode_rect". Unlike plane src coordinates, damage clips are not in 16.16 fixed point. As plane src in framebuffer cannot be negative so are damage clips. In damage clip, x1/y1 are inclusive and x2/y2 are exclusive. This patch also exports the kernel internal drm_rect to userspace as drm_mode_rect. This is because "struct drm_clip_rect" is not sufficient to represent damage for current plane size. Driver which are interested in enabling FB_DAMAGE_CLIPS property for a plane should enable this property using drm_plane_enable_damage_clips. v2: - Input validation on damage clips against framebuffer size. - Doc update, other minor changes. Signed-off-by: Lukasz Spintzyk <lukasz.spintzyk@displaylink.com> Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2018-11-28drm: Add vrr_enabled property to drm CRTCNicholas Kazlauskas
This patch introduces the 'vrr_enabled' CRTC property to allow dynamic control over variable refresh rate support for a CRTC. This property should be treated like a content hint to the driver - if the hardware or driver is not capable of driving variable refresh timings then this is not considered an error. Capability for variable refresh rate support should be determined by querying the vrr_capable drm connector property. It is worth noting that while the property is intended for atomic use it isn't filtered from legacy userspace queries. This allows for Xorg userspace drivers to implement support. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-11-02drm: Add connector property to limit max bpcRadhakrishna Sripada
At times 12bpc HDMI cannot be driven due to faulty cables, dongles level shifters etc. To workaround them we may need to drive the output at a lower bpc. Currently the user space does not have a way to limit the bpc. The default bpc to be programmed is decided by the driver and is run against connector limitations. Creating a new connector property "max bpc" in order to limit the bpc. xrandr can make use of this connector property to make sure that bpc does not exceed the configured value. This property can be used by userspace to set the bpc. V2: Initialize max_bpc to satisfy kms_properties V3: Move the property to drm_connector V4: Split drm and i915 components(Ville) V5: Make the property per connector(Ville) V6: Compare the requested bpc to connector bpc(Daniel) Move the attach_property function to core(Ville) V7: Fix checkpatch warnings V8: Simplify the connector check code(Ville) V9: Const display_info(Ville) V10,V11: Fix CI issues. V12: Add the Kernel documentation(Daniel) V14: Crossreference the function name in the doc(Daniel) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Kishore Kadiyala <kishore.kadiyala@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Sunpeng Li <sunpeng.li@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181012184233.29250-1-radhakrishna.sripada@intel.com
2018-10-17drm/atomic_helper: Stop modesets on unregistered connectors harderLyude Paul
Unfortunately, it appears our fix in: commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Which attempted to work around the problems introduced by: commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Is still not the right solution, as modesets can still be triggered outside of drm_atomic_set_crtc_for_connector(). So in order to fix this, while still being careful that we don't break modesets that a driver may perform before being registered with userspace, we replace connector->registered with a tristate member, connector->registration_state. This allows us to keep track of whether or not a connector is still initializing and hasn't been exposed to userspace, is currently registered and exposed to userspace, or has been legitimately removed from the system after having once been present. Using this info, we can prevent userspace from performing new modesets on unregistered connectors while still allowing the driver to perform modesets on unregistered connectors before the driver has finished being registered. Changes since v1: - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this patchset in igt@drv_module_reload@basic-reload-inject and igt@drv_module_reload@basic-reload by checking if the connector is registered instead of unregistered, as calling drm_connector_cleanup() on a connector that hasn't been registered with userspace yet should stay valid. - Remove unregistered_connector_check(), and just go back to what we were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") except replacing READ_ONCE(connector->registered) with drm_connector_is_unregistered(). This gets rid of the behavior of allowing DPMS On<->Off, but that should be fine as it's more consistent with the UAPI we had before - danvet - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet - Update documentation, fix some typos. Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-10drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectorsLyude Paul
It appears when testing my previous fix for some of the legacy modesetting issues with MST, I misattributed some kernel splats that started appearing on my machine after a rebase as being from upstream. But it appears they actually came from my patch series: [ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1] [ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered [ 2.980516] ------------[ cut here ]------------ [ 2.980519] Could not determine valid watermarks for inherited state [ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd [ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1 [ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016 [ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00 [ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282 [ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006 [ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0 [ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065 [ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000 [ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800 [ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000 [ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0 [ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.980645] Call Trace: [ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915] [ 2.980681] ? kernfs_add_one+0xe7/0x130 [ 2.980709] i915_pci_probe+0x46/0x60 [i915] [ 2.980715] pci_device_probe+0xd4/0x150 [ 2.980719] really_probe+0x243/0x3b0 [ 2.980722] driver_probe_device+0xba/0x100 [ 2.980726] __driver_attach+0xe4/0x110 [ 2.980729] ? driver_probe_device+0x100/0x100 [ 2.980733] bus_for_each_dev+0x74/0xb0 [ 2.980736] driver_attach+0x1e/0x20 [ 2.980739] bus_add_driver+0x159/0x230 [ 2.980743] ? 0xffffffffa0393000 [ 2.980746] driver_register+0x70/0xc0 [ 2.980749] ? 0xffffffffa0393000 [ 2.980753] __pci_register_driver+0x57/0x60 [ 2.980780] i915_init+0x55/0x58 [i915] [ 2.980785] do_one_initcall+0x4a/0x1c4 [ 2.980789] ? do_init_module+0x27/0x210 [ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190 [ 2.980797] do_init_module+0x60/0x210 [ 2.980800] load_module+0x2063/0x22e0 [ 2.980804] ? vfs_read+0x116/0x140 [ 2.980807] ? vfs_read+0x116/0x140 [ 2.980811] __do_sys_finit_module+0xbd/0x120 [ 2.980814] ? __do_sys_finit_module+0xbd/0x120 [ 2.980818] __x64_sys_finit_module+0x1a/0x20 [ 2.980821] do_syscall_64+0x5a/0x110 [ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2.980826] RIP: 0033:0x7f4754e32879 [ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48 [ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879 [ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018 [ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000 [ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 [ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000 [ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980884] ---[ end trace 5eb47a76277d4731 ]--- The cause of this appears to be due to the fact that if there's pre-existing display state that was set by the BIOS when i915 loads, it will attempt to perform a modeset before the driver is registered with userspace. Since this happens before the driver's registered with userspace, it's connectors are also unregistered and thus-states which would turn on DPMS on a connector end up getting rejected since the connector isn't registered. These bugs managed to get past Intel's CI partially due to the fact it never ran a full test on my patches for some reason, but also because all of the tests unload the GPU once before running. Since this bug is only really triggered when the drivers tries to perform a modeset before it's been fully registered with userspace when coming from whatever display configuration the firmware left us with, it likely would never have been picked up by CI in the first place. After some discussion with vsyrjala, we decided the best course of action would be to just move the unregistered connector checks out of update_connector_routing() and into drm_atomic_set_crtc_for_connector(). The reason for this being that legacy modesetting isn't going to be expecting failures anywhere (at least this is the case with X), so ideally we want to ensure that any DPMS changes will still work even on unregistered connectors. Instead, we now only reject new modesets which would change the current CRTC assigned to an unregistered connector unless no new CRTC is being assigned to replace the connector's previous one. Signed-off-by: Lyude Paul <lyude@redhat.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@redhat.com
2018-09-14drm: Differentiate the lack of an interface from invalid parameterChris Wilson
If the ioctl is not supported on a particular piece of HW/driver combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily distinguished from both the lack of the ioctl and from a regular invalid parameter. v2: Across all the kms ioctls we had a mixture of reporting EINVAL, ENODEV and a few ENOTSUPP (most where EINVAL) for a failed drm_core_check_feature(). Update everybody to report ENOTSUPP. v3: ENOTSUPP is an internal errno! It's value (524) does not correspond to a POSIX errno, the one we want is ENOTSUP. However, uapi/asm-generic/errno.h doesn't include ENOTSUP but man errno says "ENOTSUP and EOPNOTSUPP have the same value on Linux, but according to POSIX.1 these error values should be distinct." so use EOPNOTSUPP as its equivalent. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20180913192050.24812-1-chris@chris-wilson.co.uk
2018-09-09drm: extract drm_atomic_uapi.cDaniel Vetter
This leaves all the commit/check and state handling in drm_atomic.c, while pulling all the uapi glue and the huge ioctl itself into a seprate file. This seems to almost perfectly split the rather big drm_atomic.c file into 2 equal sizes. Also adjust the kerneldoc and type a very terse overview text. v2: Rebase. v3: Fix tiny typo. v4: - Fixup armada, newly converted atomic driver hooray! - Fixup msm/dpu1, newly added too. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Eric Anholt <eric@anholt.net> Cc: intel-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180905135711.28370-7-daniel.vetter@ffwll.ch