The reason behind the original indirection through the helper
functions was to allow existing drivers to overwrite how they handle
properties. For example when a vendor-specific userspace had
expectations that didn't match atomic. That seemed likely, since
atomic is standardizing a _lot_ more of the behaviour of a kms driver.
But 20 drivers later there's no such need at all. Worse, this forces
all drivers to hook up the default behaviour, breaking userspace if
they forget to do that. And it forces us to export a bunch of core
function just for those helpers.
And finally, these helpers are the last places using
drm_atomic_legacy_backoff() and the implicit acquire_ctx.
This patch here just implements the new behaviour and updates the
docs. Follow-up patches will garbage-collect all the dead code.
v2: Fixup docs even better!
v3: Make it actually work ...
v4: Drop the uses_atomic_modeset() checks from the previous patch
again, since they're now moved up in the callchain.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org> (v3)
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170725120204.2107-1-daniel.vetter@ffwll.ch
Drivers no longer have any need for these callbacks, and there are no
users. Zap. Zap-zap-zzzap-p-pp-p.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-15-peda@axentia.se
This removes the call to mipi_dbi_init() from mipi_dbi_spi_init() so that
drivers can have a driver-specific implementation if needed.
Suggested-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: David Lechner <david@lechnology.com>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1501799630-1650-2-git-send-email-david@lechnology.com
Updated blob layout (Rob, Daniel, Kristian, xerpi)
v2:
* Removed __packed, and alignment (.+)
* Fix indent in drm_format_modifier fields (Liviu)
* Remove duplicated modifier > 64 check (Liviu)
* Change comment about modifier (Liviu)
* Remove arguments to blob creation, use plane instead (Liviu)
* Fix data types (Ben)
* Make the blob part of uapi (Daniel)
v3:
Remove unused ret field.
Change i, and j to unsigned int (Emil)
v4:
Use plane->modifier_count instead of recounting (Daniel)
v5:
Rename modifiers to modifiers_property (Ville)
Use sizeof(__u32) instead to reflect UAPI nature (Ville)
Make BUILD_BUG_ON for blob header size
Cc: Rob Clark <robdclark@gmail.com>
Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Daniel Stone <daniels@collabora.com> (v2)
Reviewed-by: Liviu Dudau <liviu@dudau.co.uk> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v3)
Signed-off-by: Daniel Stone <daniels@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170724034641.13369-2-ben@bwidawsk.net
This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.
This patch simply allows the DRM drivers to initialize their list of
supported modifiers upon initializing the plane.
v2: A minor addition from Daniel
v3:
* Updated commit message
* s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
* Remove some excess newlines (Liviu)
* Update comment for > 64 modifiers (Liviu)
v4: Minor comment adjustments (Liviu)
v5: Some new platforms added due to rebase
v6: Add some missed plane inits (or maybe they're new - who knows at
this point) (Daniel)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Daniel Stone <daniels@collabora.com> (v2)
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes the following warnings when building docs:
../include/drm/drm_drv.h:553: warning: No description found for parameter 'debugfs_init'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_open_object'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_close_object'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'prime_handle_to_fd'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'prime_fd_to_handle'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_prime_export'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_prime_import'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_vm_ops'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'major'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'minor'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'patchlevel'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'name'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'desc'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'date'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'driver_features'
There are still a couple more warnings for prime helpers that are
documented elsewhere.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170720174746.29100-5-seanpaul@chromium.org
Add a common drm_driver.dumb_map_offset function for GEM backed drivers.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1500837417-40580-2-git-send-email-noralf@tronnes.org
This will let drivers reduce the error cleanup they need, in
particular the "is_panel_bridge" flag.
v2: Slight cleanup of remove function by Andrzej
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Philippe Cornu <philippe.cornu@st.com>
Tested-by: Philippe Cornu <philippe.cornu@st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170718210510.12229-2-eric@anholt.net
The current drm_atomic_helper_commit_tail helper works only if the CRTC is
accessible, and documents an alternative implementation that is supposed to
be used if that happens.
That implementation is then duplicated by some drivers. Instead of
documenting it, let's implement an helper that all the relevant users can
use directly.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/a8f92dc70048bab746e94dadd1c23200626aff60.1500555652.git-series.maxime.ripard@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fallback is in place because VGA connectors can happen to report an
unknown connection status even when they are in fact connected.
Some drivers have custom solutions in place to defer FB helper setup
until at least one output is connected. But the logic behind these
solutions is always the same and there is nothing driver-specific about
it, so a better alterative is to fix the FB helper core and add support
for all drivers automatically.
This patch adds support for deferred FB helper setup. It checks all the
connectors for their connection status, and if all of them report to be
disconnected marks the FB helper as needing deferred setup. Whet setup
is deferred, the FB helper core will automatically retry setup after a
hotplug event, and it will keep trying until it succeeds.
v2: Rebase onto my entirely reworked fbdev helper locking. One big
difference is that this version again drops&reacquires the fbdev lock
(which is now fb_helper->lock, but before this patch series it was
mode_config->mutex), because register_framebuffer must be able to
recurse back into fbdev helper code for the initial screen setup.
v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
return, I've fumbled that in the deferred setup case (Liviu).
v4: I was blind, redo this all. __drm_fb_helper_initial_config
shouldn't need to reacquire fb_helper->lock, that just confuses
callers. I myself got confused by kernel_fb_helper_lock and somehow
thought it's the same as fb_helper->lock. Tsk.
Also simplify the logic a bit (we don't need two functions to probe
connectors), we can stick much closer to the existing code. And update
some comments I've spotted that are outdated.
v5: Don't pass -EAGAIN to drivers, it's just an internal error code
(Liviu).
v6: Add _and_unlock suffix to clarify locking (Maarten)
Cc: Liviu Dudau <liviu@dudau.co.uk>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Reviewed-by: Liviu Dudau <liviu@dudau.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-3-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I need this to be able to apply the deferred fbdev setup patches, I
need the relevant prep work that landed through the drm-intel tree.
Also squash in conflict fixup from Laurent Pinchart.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that all drivers check the return value, convert swap_state to
__must_check. This is done separately to force build warnings if we
missed a driver.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-12-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds helper functions for YCBCR 420 handling.
These functions do:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 also mode.
V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.
V4: EXPORT_SYMBOL(drm_find_hdmi_output_type)
V5: Addressed review comments from Danvet:
- %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type
- %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output
- %s/drm_can_support_this_ycbcr_output/
drm_display_supports_this_ycbcr_output
- pass drm_display_info instead of drm_connector for consistency
- For drm_get_highest_quality_ycbcr_supported doc, move the variable
description above, and then the function description.
V6: Add only YCBCR420 helpers (Ville)
V7: Addressed review comments from Ville
- Remove cea_vic_valid() check.
- Fix indentation.
- Make input parameters to helpers, const.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-9-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix sparse indentation warn]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc_modes into this patch, where its used
(Ville)
V5: Optimize function, if(conditions) not reqd (Ville)
V6: Rebase
V7: Rebase
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-8-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix sparse indentation warn]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
V2: Addressed
Review comments from Emil:
- Use 1ULL<<i instead of 1<<i to make sure the output is 64bit.
- Use the suggested method for updating dbmap.
- Add documentation for YCBCR420_vcb_map to fix kbuild warning.
Review comments from Ville:
- Do not expose the YCBCR420 flags in uabi layer, keep it internal.
- Save a map of YCBCR420 modes for future reference.
- Check db length before trying to parse extended tag.
- Add a warning if there are > 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
add a separate helper function to prune ycbcr420-only modes from
connector's probed modes.
V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)
V8: Addressed review comments from Ville
- use cea_vic_valid check before adding cmdb/vdb modes
- add check for i < 64 while adding cmdb modes
- use 1ULL while checking bitmap
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix checkpatch complaints and indentation]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
connector. This function will help pruning the YCBCR420-only
modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connector structure.
While handling the EDID from HDMI 2.0 sinks, its important to know
if the source is capable of handling YCBCR420 output, so that no
YCBCR 420 modes will be listed for sources which can't handle it.
A driver should set this variable if it wants to see YCBCR420 modes
in the modedb.
V5: Introduced the patch in series.
V6: Squashed two patches (validate YCBCR420 and add YCBCR420
identifier)
V7: Addressed review comments from Vile:
- Move this patch before we add 420 modes from EDID.
- No need for drm_valid_cea_vic() check, function back to non-static.
- Update MODE_STATUS with NO_420 condition.
- Introduce y420_vdb_modes variable in this patch
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com
[vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
As CEA-861-F has already defined VICs for 4K videomodes, this
patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
until the mode is 3D.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
send only one of it.
V4: Rebase
V5: Added r-b from Neil.
Addressed review comments from Ville
- Do not block HDMI vendor IF, instead check for VIC while
handling AVI infoframes
V6: Rebase
V7: Rebase
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The function has little to do with atomic, it's just where it has so
far been needed. So, rename it to drm_property_replace_blob, move it
to drm_property.c and export it.
Change the semantics to return whether the blob was replaced instead
of using an extra argument for that.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-2-peda@axentia.se
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJZZvUdAAoJEAx081l5xIa+ZHQP/iFMSmu1H78hZ3amygQnCkyr
NSeeym+z2Aj4MADXjMM6mEmLxSAR3xzMeqD4yJjZTYcOiLoK2FI2t1yo216LVNm0
U4Ws5u1tLTBgr/tYSwCbAOsr1s4e7YvS4FdpK3echcTKp10TBSu3wd4utTidQAit
Q7h2+mnoj92WbBdbIcydIHpg931xbmEyRQIuOJuIAuYdG3iGlflQ1EsUAuozV8Hn
z9S93IwtTeDZMYEjQcCJFpGrnUzHP/oi2WatW6c8GXwykuI7e9px9KmxqO/kWibV
JfrVuDZFJKVyBga7cc3xHf8zmvnzsv0QhZBPb9hOGuH093RkUlF2Q6fswnvy9MPU
Ym1t/sb8kgF0tgPBxTt3F6m5mFSi/Rz9WTof8y/y4bN3z2LCCsv65VWaqpZUvnGD
x6my5wgCgXRNHxK031lMNOLItv2rg4rbkJcL+VE1No2TjbnjZxcFgMdihwCyrkYk
B1oeFUZk+oDS4ho0dL0LZr9OJkvF/X4yF0Ubx/CjYf5lTRr1Gtaha+qyaSqTbcEO
qm+aprNTm8QPKx9ZAVOZObEj7bt3R0r4HzxUTTy5VyYJqNx6NySINIoMgEi/e/wc
ScJVzI2EKmQh8xVtEle5wGz1gMGZMHj5Q/v/r1fkjXf07R931im+w3lxif4I5K1e
TOvgMJ2rBgYXQ55lssN/
=TGAC
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-for-v4.13-rc1' of git://people.freedesktop.org/~airlied/linux
Pull more drm updates from Dave Airlie:
"i915, amd and some core fixes + mediatek color support.
Some fixes tree came in since the main pull request for rc1, primarily
i915 and drm-misc and one amd fix. The drm core vblank regression fix
is probably the most important thing.
I've also added the mediatek feature pull, it wasn't that big and
didn't look like it would have any impact outside of mediatek, in fact
it looks to just be a single feature, and some cleanups"
* tag 'drm-fixes-for-v4.13-rc1' of git://people.freedesktop.org/~airlied/linux: (31 commits)
drm/i915: Make DP-MST connector info work
drm/i915/gvt: Use fence error from GVT request for workload status
drm/i915/gvt: remove scheduler_mutex in per-engine workload_thread
drm/i915/gvt: Revert "drm/i915/gvt: Fix possible recursive locking issue"
drm/i915/gvt: Audit the command buffer address
drm/i915/gvt: Fix a memory leak in intel_gvt_init_gtt()
drm/rockchip: fix NULL check on devm_kzalloc() return value
drm/i915/fbdev: Check for existence of ifbdev->vma before operations
drm/radeon: Fix eDP for single-display iMac10,1 (v2)
drm/i915: Hold RPM wakelock while initializing OA buffer
drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming
drm/i915/cfl: Fix Workarounds.
drm/i915: Avoid undefined behaviour of "u32 >> 32"
drm/i915: reintroduce VLV/CHV PFI programming power domain workaround
drm/i915: Fix an error checking test
drm/i915: Disable MSI for all pre-gen5
drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb
drm: vblank: Fix vblank timestamp update
drm/i915/gvt: Make function dpy_reg_mmio_readx safe
drm/mediatek: separate color module to fixup error memory reallocation
...
Make the atomic private object stuff less special by introducing proper
base classes for the object and its state. Drivers can embed these in
their own appropriate objects, after which these things will work
exactly like the plane/crtc/connector states during atomic operations.
v2: Reorder to not depend on drm_dynarray (Daniel)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170712155102.26276-3-ville.syrjala@linux.intel.com
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJZYseIAAoJEAx081l5xIa+85kP/0zKzKKVzZXSXG2TAGb5jNfk
Ex+TELG8tWk9KBxA7lEE5c0WEsnP79cNoXZLQu8wlUzO8+kwQK5Bz0zgNUkpSuo1
RthwdsxBQX1++UxB+HoSG+dOa7hkKVqlgQR3z9qyhsBXzetkJV0DoYcpMV0A1EWd
6Jzt+AvCShVkcW+21LqHPlc5EIVewrDMoA3oU6aYCLhyAOUTVvvQB2ML8YApH7TM
JrSrzCFHTrQEBbGUrZQhzR0sZzZzk9byntb/I/mdVbHeCyIHiL8sC4PfWSOyyazm
GkPnA8G3aFAY9haBRz9jG/VBr1yVb0mCBjkWQ1lGfIAOCDDSc+d7PDXdG+i4AewK
jZheXlrDIdGgmJLy4W3rdEqJvdf7UQHZOs8594OL19l4+FxCTrol1JSHSMeavCvr
8bUNil9Jb/ONU/wmp+q55U0k4TCTyerUA7gKnuaJAwBvd4n78/PKmQnbrWinDyJc
GQXp6zESk9bKt5DXSnVZuVf4POTzpuAsQkkfX1V2y145EHTQYfS3jLENWqEjyZUy
QtKCHZvRkJfGaFU4Pr+vBo9Iu1GlA5OiOv08QadldTT4OxUI0T6yaLDobHCQfKPE
sc3wCuCM+/dAnqoKDcGC4hAmF8zDdO0kw65P2m7uC6T9Jm1G35CioKbzo+fzUhuL
fg5TBpbp2Wwe2oPA5iBm
=2S5N
-----END PGP SIGNATURE-----
Merge tag 'drm-for-v4.13' of git://people.freedesktop.org/~airlied/linux
Pull drm updates from Dave Airlie:
"This is the main pull request for the drm, I think I've got one later
driver pull for mediatek SoC driver, I'm undecided on if it needs to
go to you yet.
Otherwise summary below:
Core drm:
- Atomic add driver private objects
- Deprecate preclose hook in modern drivers
- MST bandwidth tracking
- Use kvmalloc in more places
- Add mode_valid hook for crtc/encoder/bridge
- Reduce sync_file construction time
- Documentation updates
- New DRM synchronisation object support
New drivers:
- pl111 - pl111 CLCD display controller
Panel:
- Innolux P079ZCA panel driver
- Add NL12880B20-05, NL192108AC18-02D, P320HVN03 panels
- panel-samsung-s6e3ha2: Add s6e3hf2 panel support
i915:
- SKL+ watermark fixes
- G4x/G33 reset improvements
- DP AUX backlight improvements
- Buffer based GuC/host communication
- New getparam for (sub)slice infomation
- Cannonlake and Coffeelake initial patches
- Execbuf optimisations
radeon/amdgpu:
- Lots of Vega10 bug fixes
- Preliminary raven support
- KIQ support for compute rings
- MEC queue management rework
- DCE6 Audio support
- SR-IOV improvements
- Better radeon/amdgpu selection support
nouveau:
- HDMI stereoscopic support
- Display code rework for >= GM20x GPUs
msm:
- GEM rework for fine-grained locking
- Per-process pagetable work
- HDMI fixes for Snapdragon 820.
vc4:
- Remove 256MB CMA limit from vc4
- Add out-fence support
- Add support for cygnus
- Get/set tiling ioctls support
- Add T-format tiling support for scanout
zte:
- add VGA support.
etnaviv:
- Thermal throttle support for newer GPUs
- Restore userspace buffer cache performance
- dma-buf sync fix
stm:
- add stm32f429 display support
exynos:
- Rework vblank handling
- Fixup sw-trigger code
sun4i:
- V3s display engine support
- HDMI support for older SoCs
- Preliminary work on dual-pipeline SoCs.
rcar-du:
- VSP work
imx-drm:
- Remove counter load enable from PRE
- Double read/write reduction flag support
tegra:
- Documentation for the host1x and drm driver.
- Lots of staging ioctl fixes due to grate project work.
omapdrm:
- dma-buf fence support
- TILER rotation fixes"
* tag 'drm-for-v4.13' of git://people.freedesktop.org/~airlied/linux: (1270 commits)
drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()
drm/amd/powerplay: fix bug fail to remove sysfs when rmmod amdgpu.
amdgpu: Set cik/si_support to 1 by default if radeon isn't built
drm/amdgpu/gfx9: fix driver reload with KIQ
drm/amdgpu/gfx8: fix driver reload with KIQ
drm/amdgpu: Don't call amd_powerplay_destroy() if we don't have powerplay
drm/ttm: Fix use-after-free in ttm_bo_clean_mm
drm/amd/amdgpu: move get memory type function from early init to sw init
drm/amdgpu/cgs: always set reference clock in mode_info
drm/amdgpu: fix vblank_time when displays are off
drm/amd/powerplay: power value format change for Vega10
drm/amdgpu/gfx9: support the amdgpu.disable_cu option
drm/amd/powerplay: change PPSMC_MSG_GetCurrPkgPwr for Vega10
drm/amdgpu: Make amdgpu_cs_parser_init static (v2)
drm/amdgpu/cs: fix a typo in a comment
drm/amdgpu: Fix the exported always on CU bitmap
drm/amdgpu/gfx9: gfx_v9_0_enable_gfx_static_mg_power_gating() can be static
drm/amdgpu/psp: upper_32_bits/lower_32_bits for address setup
drm/amd/powerplay/cz: print message if smc message fails
drm/amdgpu: fix typo in amdgpu_debugfs_test_ib_init
...
Pull DRM compat ioctl handling updates from Al Viro:
"This kills the double-copies in there and tons of field-by-field
copyin/copyout.
Several dead ioctls put to rest, while we are at it - the native
counterparts had been gone for a decade, so we can bloody well fail
early on the compat side. No point rearranging the 32bit structure
into 64bit one (and back) only to be told "piss off, I don't know that
ioctl" by the native code..."
* 'work.drm' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (29 commits)
Fix trivial misannotations
mga: switch compat ioctls to drm_ioctl_kernel()
radeon: take out dead compat ioctls
drm compat: ia64 is not biarch
drm_compat_ioctl(): tidy up a bit
switch compat_drm_mapbufs() to drm_ioctl_kernel()
switch compat_drm_rmmap() to drm_ioctl_kernel()
switch compat_drm_mode_addfb2() to drm_ioctl_kernel()
switch compat_drm_wait_vblank() to drm_ioctl_kernel()
switch compat_drm_update_draw()
compat_drm: switch sg ioctls
compat_drm: switch AGP compat ioctls to drm_ioctl_kernel()
switch compat_drm_dma() to drm_ioctl_kernel()
switch compat_drm_resctx() to drm_ioctl_kernel()
switch compat_drm_getsareactx() to drm_ioctl_kernel()
switch compat_drm_setsareactx() to drm_ioctl_kernel()
switch compat_drm_freebufs() to drm_ioctl_kernel()
switch compat_drm_markbufs() to drm_ioctl_kernel()
switch compat_drm_addmap() to drm_ioctl_kernel()
switch compat_drm_getstats() to drm_ioctl_kernel()
...
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
This patch just adds the new lock everywhere we currently grab
mode_config->mutex (explicitly, or through drm_modeset_lock_all).
Follow-up patches will push the kms locking down into only the places
that need it.
v2:
- use lockdep_assert_held
- use drm_fb_helper_for_each_connector where possible
- use the new top-level lock consistently, i.e. in all the places
we're currently acquiring mode_config.mutex.
- small polish to the kerneldoc
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-4-daniel.vetter@ffwll.ch
the drm_file parameter is unused, so remove it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.
This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.
For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.
v6: - move check code to drm_atomic_helper.c (Daniel Vetter)
v5:
- improve comments (Eric Anholt)
v4:
- fix state->crtc NULL check (Archit Taneja)
v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)
v2:
- allow updates even if there is a queued update for the same
plane.
- fixes on the documentation (Emil Velikov)
- unconditionally call ->atomic_async_update (Emil Velikov)
- check for ->atomic_async_update earlier (Daniel Vetter)
- make ->atomic_async_check() the last step (Daniel Vetter)
- add ASYNC_UPDATE flag (Eric Anholt)
- update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org> (v5)
Acked-by: Eric Anholt <eric@anholt.net> (v5)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630180322.29007-2-gustavo@padovan.org
The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.
While at it, rename the operation to .atomic_enable() to be consistent
with .atomic_disable(), as the .enable() operation is used by atomic
helpers only.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> # for sun4i
Acked-by: Philipp Zabel <p.zabel@pengutronix.de> # for imx-drm and mediatek
Acked-by: Alexey Brodkin <abrodkin@synopsys.com> # for arcpgu
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> # for atmel-hlcdc
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> # for hdlcd and mali-dp
Acked-by: Stefan Agner <stefan@agner.ch> # for fsl-dcu
Tested-by: Philippe Cornu <philippe.cornu@st.com> # for stm
Acked-by: Philippe Cornu <philippe.cornu@st.com> # for stm
Acked-by: Vincent Abriou <vincent.abriou@st.com> # for sti
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> # for vmwgfx
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630093646.7928-2-laurent.pinchart+renesas@ideasonboard.com
There's no reason for drivers to call this, and all the ones I've
removed looked very fishy:
- Proper quiescenting of the vblank machinery should be done by
calling drm_crtc_vblank_off(), which is best done by shutting down
the entire display engine with drm_atomic_helper_shutdown.
- Releasing of allocated memory is done by the core already, it calls
drm_vblank_cleanup as a fallback.
- drm_vblank_cleanup also has checks for drivers which forget to clean
up vblank interrupts.
This essentially reverts
commit e77cef9c2d
Author: Jerome Glisse <jglisse@redhat.com>
Date: Thu Jan 7 15:39:13 2010 +0100
drm: Avoid calling vblank function is vblank wasn't initialized
which was done to fix a bug in radeon code with msi interrupts:
commit 003e69f986
Author: Jerome Glisse <jglisse@redhat.com>
Date: Thu Jan 7 15:39:14 2010 +0100
drm/radeon/kms: Don't try to enable IRQ if we have no handler installed
Afaict from digging around in old code, this was needed to avoid
blowing up in the ums fallback, and has stopped serving it's purpose
long ago - if irq init fails, the driver fails to load, and there's
really no way to blow up anymore.
Long story short, this was most likely a small ums compat/fallback
hack that became a thing of it's own and got cargo-cult duplicated all
over the drm codebase for essentially no gain at all.
v2: Mention that for drivers with a ->release callback cleanup is
handled by drm_dev_fini() (Thierry).
Cc: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626161949.25629-2-daniel.vetter@ffwll.ch
The "supported input formats" table in dw_hdmi.h was incorrectly formatted,
using "+" signs where "|" needs to be. That, in turn, causes the PDF build
to fail.
Fixes: def23aa7e9 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170623140013.0703107a@lwn.net
Add an helper to wait for all page flips of an atomic state to be done.
v2:
- Pimp kerneldoc as discussed with Boris on irc
- Add missing doc for @dev.
- Use old_state for consitency with wait_for_vblanks
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> (v1)
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1496392332-8722-2-git-send-email-boris.brezillon@free-electrons.com
Final pile of features for 4.13
New uabi:
- batch bo in first slot, for faster execbuf assembly in userspace
(Chris Wilson)
- (sub)slice getparam, needed for mesa perf support (Robert Bragg)
First pile of patches for cnl/cfl support, maintained by Rodrigo but
with lots of contributions from others. Still incomplete since public
review still ongoing.
Features/refactoring:
- Make execbuf faster (Chris Wilson), a pile of series to make execbuf
buffer handling have fewer passes, use less list walking, postpone
more work to async workers and shuffle buffers less, all to make the
common case much faster (in some cases at least).
- cold boot support for glk dsi (Madhav Chauhan)
- Clean up pipe A quirk and related old platform hacks (Ville)
- perf sampling support for kbl/glk (Lionel)
- perf cleanups (Robert Bragg)
- wire atomic state to backlight code, to avoid pipe lookup hacks
(Maarten)
- reduce request waiting latency/overhead to remove the spinning and
associated cpu cycle wasting (Chris)
- fix 90/270 rotation wm computation (Ville)
- new ddb allocation algo for skl (Kumar Mahesh)
- fix regression due to system suspend optimiazatino (Imre)
- the usual pile of small cleanups and refactors all over
GVT updates contained in this tag:
- optimization for per-VM mmio save/restore (Changbin)
- optimization for mmio hash table (Changbin)
- scheduler optimization with event (Ping)
- vGPU reset refinement (Fred)
- other misc refactor and cleanups, etc.
* tag 'drm-intel-next-2017-06-19' of git://anongit.freedesktop.org/git/drm-intel: (170 commits)
drm/i915: Update DRIVER_DATE to 20170619
drm/i915/cfl: Introduce Coffee Lake workarounds.
drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH
drm/i915: Stash a pointer to the obj's resv in the vma
drm/i915: Async GPU relocation processing
drm/i915: Allow execbuffer to use the first object as the batch
drm/i915: Wait upon userptr get-user-pages within execbuffer
drm/i915: First try the previous execbuffer location
drm/i915: Store a persistent reference for an object in the execbuffer cache
drm/i915: Eliminate lots of iterations over the execobjects array
drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations
drm/i915: Pass vma to relocate entry
drm/i915: Store a direct lookup from object handle to vma
drm/i915: Fix retrieval of hangcheck stats
drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty
drm/i915: Mark CPU cache as dirty on every transition for CPU writes
drm/i915: Make i915_vma_destroy() static
drm/i915: Actually attach the tv_format property to the SDVO connector
Revert "drm/i915/skl: New ddb allocation algorithm"
drm/i915/glk: Add cold boot sequence for GLK DSI
...
drm_fbdev_cma_set_suspend{,_unlocked} use an integer parameter
to describe whether the intended state is a suspend or a resume.
It then passes the value to drm_fb_helper_set_suspend{,_unlocked}
which uses a boolean. Switch to using bool everywhere.
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620102320.8849-1-Liviu.Dudau@arm.com
I spotted a markup issue, plus adding the descriptions in drm_driver.
Plus a few more links while at it.
I'm still mildly unhappy with the split between fops and ioctls, but I
still think having the ioctls in the uapi chapter makes more sense. Oh
well ...
v2: Rebase.
v3: Move misplace hunk to the right patch.
Cc: Stefan Agner <stefan@agner.ch>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170531092045.3950-1-daniel.vetter@ffwll.ch
The magic switching between proper pci driver and shadow-attach isn't
useful anymore since there's no ums+kms drivers left. Let's split this
up properly, calling pci_register_driver for kms drivers and renaming
the shadow-attach init to drm_legacy_pci_init/exit.
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-6-daniel.vetter@ffwll.ch
We use drm_crtc_ for all the new-style vblank functions which directly
take a struct drm_crtc *. drm_accurate_vblank_count was the odd one
out, correct this to appease my OCD.
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-13-daniel.vetter@ffwll.ch
Unify and review everything, plus make sure it's all correct markup.
Drop the kernel-doc for internal functions. Also rework the overview
section, it's become rather outdated.
Unfortuantely the kernel-doc in drm_driver isn't rendered yet, but
that will change as soon as drm_driver is kernel-docified properly.
Also document properly that drm_vblank_cleanup is optional, the core
calls this already.
v2: Make it clear that cleanup happens in drm_dev_fini for drivers
with their own ->release callback (Thierry).
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-11-daniel.vetter@ffwll.ch
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJZPdbLAAoJEHm+PkMAQRiGx4wH/1nCjfnl6fE8oJ24/1gEAOUh
biFdqJkYZmlLYHVtYfLm4Ueg4adJdg0wx6qM/4RaAzmQVvLfDV34bc1qBf1+P95G
kVF+osWyXrZo5cTwkwapHW/KNu4VJwAx2D1wrlxKDVG5AOrULH1pYOYGOpApEkZU
4N+q5+M0ce0GJpqtUZX+UnI33ygjdDbBxXoFKsr24B7eA0ouGbAJ7dC88WcaETL+
2/7tT01SvDMo0jBSV0WIqlgXwZ5gp3yPGnklC3F4159Yze6VFrzHMKS/UpPF8o8E
W9EbuzwxsKyXUifX2GY348L1f+47glen/1sedbuKnFhP6E9aqUQQJXvEO7ueQl4=
=m2Gx
-----END PGP SIGNATURE-----
BackMerge tag 'v4.12-rc5' into drm-next
Linux 4.12-rc5 for nouveau fixes
