29 Oct, 2018
5 commits
-
This adds the infrastructure needed to quirk displays
using edid and to mark them a non-desktop.A non-desktop display is one which shouldn't normally be included
as a part of a desktop environment.This is meant to cover head mounted devices like HTC Vive.
v2: Change description from non-standard to non-desktop, add docs
Reviewed-by: Keith Packard
Signed-off-by: Dave Airlie
Signed-off-by: Marius Vlad(Ported 66660d4cf21b7dfcb25 from git://people.freedesktop.org/~airlied/linux)
-
Signed-off-by: Laurentiu Palcu
-
EA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.Signed-off-by: Uma 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.Signed-off-by: Uma Shankar
-
This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.v2: Also fix up vboxvideo driver in staging
[airlied: merging early as this is an API change]
Suggested-by: Daniel Vetter
Signed-off-by: Keith Packard
Signed-off-by: Dave Airlie
(cherry picked from commit 418da17214aca5ef5f0b6f7588905ee7df92f98f)
08 Aug, 2017
1 commit
-
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
Reviewed-by: Archit Taneja (v3)
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Link: https://patchwork.freedesktop.org/patch/msgid/20170725120204.2107-1-daniel.vetter@ffwll.ch
15 Jul, 2017
3 commits
-
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: RebaseCc: Ville Syrjälä
Cc: Jose Abreu
Signed-off-by: Shashank Sharma
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ä -
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
Cc: Jose Abreu
Cc: Emil VelikovV2: Addressed
Review comments from Emil:
- Use 1ULL<< 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 bitmapSigned-off-by: Shashank Sharma
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ä -
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 patchCc: Ville Syrjala
Signed-off-by: Shashank Sharma
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ä
15 Jun, 2017
1 commit
-
Forward declarations in C are great but I'm pretty sure one is enough.
Signed-off-by: Dawid Kurek
Signed-off-by: Sean Paul
Link: http://patchwork.freedesktop.org/patch/msgid/20170614213518.GA3554@gmail.com
26 May, 2017
1 commit
-
After converting all users to drm_for_each_connector_iter() we no
longer need drm_for_each_connector() so we can go ahead and remove it.Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20170511191049.28944-8-gustavo@padovan.org
18 May, 2017
1 commit
-
While reading drm_for_each_connector_iter, I noticed a mention to
drm_connector_begin which doesn't exist. It should be
drm_connector_get.Signed-off-by: Gabriel Krisman Bertazi
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20170421003819.17685-1-krisman@collabora.co.uk
08 May, 2017
2 commits
-
Some connectors may not allow all scaling mode properties, this function will allow
creating the scaling mode property with only the supported subset. It also wires up
this state for atomic.This will make it possible to convert i915 connectors to atomic.
Changes since v1:
- Add DRM_MODE_PROP_ENUM flag to drm_property_create
- Use the correct index in drm_property_add_enum.
- Add DocBook for function (Sean Paul).
- Warn if less than 2 valid scaling modes are passed.
- Remove level of indent. (Sean Paul)Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/20170501133804.8116-3-maarten.lankhorst@linux.intel.com
[mlankhorst: Rename function, fix docbook issues]
Reviewed-by: Daniel Vetter -
This is only used in i915, which had used its own non-atomic way to
deal with the picture aspect ratio. Move selected aspect_ratio to
atomic state and use the atomic state in the affected i915 connectors.Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/20170501133804.8116-2-maarten.lankhorst@linux.intel.com
[mlankhorst: taomic -> atomic thanks to Manasi's input]
Reviewed-by: Daniel Vetter
11 Apr, 2017
1 commit
-
Last drm-misc-next pull req for 4.12
Core changes:
- fb_helper checkpatch cleanup and simplified _add_one_connector() (Thierry)
- drm_ioctl and drm_sysfs improved/gained documentation (Daniel)
- [ABI] Repurpose reserved field in drm_event_vblank for crtc_id (Ander)
- Plumb acquire ctx through legacy paths to avoid lock_all and legacy_backoff
(Daniel)
- Add connector_atomic_check to check conn constraints on modeset (Maarten)
- Add drm_of_find_panel_or_bridge to remove boilerplate in drivers (Rob)Driver changes:
- meson moved to drm-misc (Neil)
- Added support for Amlogic GX SoCs in dw-hdmi (Neil)
- Rockchip unbind actually cleans up the things bind initializes (Jeffy)
- A couple misc fixes in virtio, dw-hdmiNOTE: this also includes a backmerge of drm-next as well rc5 (we needed vmwgfx
as well as the new synopsys media formats)* tag 'drm-misc-next-2017-04-07' of git://anongit.freedesktop.org/git/drm-misc: (77 commits)
Revert "drm: Don't allow interruptions when opening debugfs/crc"
drm: Only take cursor locks when the cursor plane exists
drm/vmwgfx: Fix fbdev emulation using legacy functions
drm/rockchip: Shutdown all crtcs when unbinding drm
drm/rockchip: Reorder drm bind/unbind sequence
drm/rockchip: analogix_dp: Disable clock when unbinding
drm/rockchip: vop: Unprepare clocks when unbinding
drm/rockchip: vop: Enable pm domain before vop_initial
drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding
drm/rockchip: cdn-dp: Don't try to release firmware when not loaded
drm: bridge: analogix: Destroy connector & encoder when unbinding
drm: bridge: analogix: Disable clock when unbinding
drm: bridge: analogix: Unregister dp aux when unbinding
drm: bridge: analogix: Detach panel when unbinding analogix dp
drm: Don't allow interruptions when opening debugfs/crc
drm/virtio: don't leak bo on drm_gem_object_init failure
drm: bridge: dw-hdmi: fix input format/encoding from plat_data
drm: omap: use common OF graph helpers
drm: convert drivers to use drm_of_find_panel_or_bridge
drm: convert drivers to use of_graph_get_remote_node
...
07 Apr, 2017
1 commit
-
mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.Some implementations of detect() already lock all state,
so we have to pass an acquire_ctx to them to prevent a deadlock.This means changing the function signature of detect() slightly,
and passing the acquire_ctx for locking multiple crtc's.
For the callbacks, it will always be non-zero. To allow callers
not to worry about this, drm_helper_probe_detect_ctx is added
which might handle -EDEADLK for you.Changes since v1:
- Always set ctx parameter.
Changes since v2:
- Always take connection_mutex when probing.
Changes since v3:
- Remove the ctx from intel_dp_long_pulse, and add
WARN_ON(!connection_mutex) (danvet)
- Update docs to clarify the locking situation. (danvet)Signed-off-by: Maarten Lankhorst
Cc: Boris Brezillon
Reviewed-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1491504920-4017-1-git-send-email-maarten.lankhorst@linux.intel.com
04 Apr, 2017
1 commit
-
The flags indicate whether data is transmitted LSB to MSB or MSB to LSB
on the bus.The exact meaning is bus-type dependent. For instance, for LVDS buses
the flags indicate whether the seven data bits transmitted in a clock
pulse are sent in normal order (MSB to LSB, slots 0 to 6) or reverse
order (LSB to MSB, slots 6 to 0).Signed-off-by: Laurent Pinchart
Reviewed-by: Thierry Reding
29 Mar, 2017
1 commit
-
The rules are getting real hard, better to dump my brain into text a
bit. This is by far not complete, but I think I reasonable start at
least.Some of the older kms structures would need a full doc review anyway
...Cc: Harry Wentland
Reviewed-by: Harry Wentland
Reviewed-by: Alex Deucher
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20170328155349.5972-2-daniel.vetter@ffwll.ch
28 Mar, 2017
1 commit
-
This patch adds description about 'scdc' variable in drm_hdmi_info
structure, to fix this warning during doc-build."drm_connector.h:140: warning: No description found for parameter 'scdc'"
V2: Rebase
V3: Added extra *
V4: Removed merged conflict
V5: Removed extra line at start of structure (Daniel)
V6: Make description single line (Daniel)Cc: Daniel Vetter
Signed-off-by: Shashank Sharma
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1490684779-21633-1-git-send-email-shashank.sharma@intel.com
21 Mar, 2017
2 commits
-
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
- If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Addressed review comments from Ville
- Add clock rate calculations for 1/10 and 1/40 ratios
- Remove leftovers from old patchset
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.Signed-off-by: Shashank Sharma
Reviewed-by: Thierry Reding
Reviewed-by: Jose Abreu
Signed-off-by: Jani Nikula
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com -
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
- If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Rebase.
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.Signed-off-by: Shashank Sharma
Reviewed-by: Thierry Reding
Reviewed-by: Jose Abreu
Signed-off-by: Jani Nikula
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
01 Mar, 2017
1 commit
-
This fixes the kernel doc warning that was introduced in
the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
atomic property for link status")'. Description has
been added for the enum values.Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1488379510-15059-1-git-send-email-manasi.d.navare@intel.com
28 Feb, 2017
2 commits
-
Currently the functions that initialize and tear down a connector
iterator use the _get() and _put() suffixes. However, these suffixes
are typically used by reference counting functions.Make these function names a little more consistent by changing the
suffixes to _begin() and _end(), which is a fairly common pattern in
the rest of the Linux kernel.Suggested-by: Jani Nikula
Signed-off-by: Thierry Reding
Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-8-thierry.reding@gmail.com -
For consistency with other reference counting APIs in the kernel, add
drm_connector_get() and drm_connector_put() functions to reference count
connectors.Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.The existing semantic patch for mode object reference count conversion
is extended for these new helpers.Reviewed-by: Sean Paul
Acked-by: Christian König
Signed-off-by: Thierry Reding
Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-4-thierry.reding@gmail.com
27 Feb, 2017
1 commit
-
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requirements of the mode. Black screen follows.One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would
also conflict with the idea of making setcrtc asynchronous in the
future, returning before the actual mode setting and link training.Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on
practical not theoretical capabilities. However, the changes for link
training are pretty drastic, all for the sake of error handling and
DP compliance, when the most common happy day scenario is the current
approach of link training at mode setting time, using the optimal
parameters for the mode. It is also not certain all hardware could do
this without the pipe on; not even all our hardware can do this. Some
of this can be solved, but not trivially.Both of the above ideas also fail to address link degradation *during*
operation.The solution is to add a new "link-status" connector property in order
to address link training failure in a way that:
a) changes the current happy day scenario as little as possible, to
avoid regressions, b) can be implemented the same way by all drm
drivers, c) is still opt-in for the drivers and userspace, and opting
out doesn't regress the user experience, d) doesn't prevent drivers
from implementing better or alternate approaches, possibly without
userspace involvement. And, of course, handles all the issues presented.
In the usual happy day scenario, this is always "good". If something
fails during or after a mode set, the kernel driver can set the link
status to "bad" and issue a hotplug uevent for userspace to have it
re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
again. If the theoretical capabilities of the link can't be reached,
the mode list is trimmed based on that.v7 by Jani:
* Rebase, simplify set property while at it, checkpatch fix
v6:
* Fix a typo in kernel doc (Sean Paul)
v5:
* Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter)
v4:
* Add comments in kernel-doc format (Daniel Vetter)
* Update the kernel-doc for link-status (Sean Paul)
v3:
* Fixed a build error (Jani Saarinen)
v2:
* Removed connector->link_status (Daniel Vetter)
* Set connector->state->link_status in drm_mode_connector_set_link_status_property
(Daniel Vetter)
* Set the connector_changed flag to true if connector->state->link_status changed.
* Reset link_status to GOOD in update_output_state (Daniel Vetter)
* Never allow userspace to set link status from Good To Bad (Daniel Vetter)Reviewed-by: Sean Paul
Reviewed-by: Daniel Vetter
Reviewed-by: Jani Nikula
Acked-by: Tony Cheng
Acked-by: Harry Wentland
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Chris Wilson
Cc: Sean Paul
Signed-off-by: Manasi Navare
Signed-off-by: Jani Nikula
Acked-by: Eric Anholt (for the -modesetting patch)
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
25 Jan, 2017
1 commit
-
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).Also some minor drive-by polish where it makes sense, I read a lot
of docs ...v2: Review from Eric.
Cc: Jani Nikula
Cc: Chris Wilson
Reviewed-by: Eric Engestrom
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-4-daniel.vetter@ffwll.ch
30 Dec, 2016
2 commits
-
I've forgotten to remove this when revamping the
connector_list locking.Cc: seanpaul@chromium.org
Reviewed-by: David Herrmann
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-7-git-send-email-daniel.vetter@ffwll.ch -
sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i
Originally I wasnt a friend of this style because I thought a
line-break between the "&struct" and "foo" part would break it. But a
quick test shows that " * &struct \n * foo\n" works pefectly well with
current kernel-doc. So time to mass-apply these changes!Cc: Jani Nikula
Cc: Chris Wilson
Reviewed-by: David Herrmann
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-6-git-send-email-daniel.vetter@ffwll.ch
18 Dec, 2016
4 commits
-
Signed-off-by: Peter Meerwald-Stadler
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: trivial@kernel.org
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1481894663-4570-1-git-send-email-pmeerw@pmeerw.net -
- Modeset state needs mode_config->connection mutex, that covers
figuring out the encoder, and reading properties (since in the
atomic case those need to look at connector->state).- Don't hold any locks for stuff that's invariant (i.e. possible
connectors).- Same for connector lookup and unref, those don't need any locks.
- And finally the probe stuff is only protected by mode_config->mutex.
While at it updated the kerneldoc for these fields in drm_connector
and add docs explaining what's protected by which locks.Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-10-daniel.vetter@ffwll.ch -
If we're unlucky then the registration from a hotplugged connector
might race with the final registration step on driver load. And since
MST topology discover is asynchronous that's even somewhat likely.v2: Also update the kerneldoc for @registered!
v3: Review from Chris:
- Improve kerneldoc for late_register/early_unregister callbacks.
- Use mutex_destroy.Reviewed-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Sean Paul
Reported-by: Chris Wilson
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161218133545.2106-1-daniel.vetter@ffwll.ch -
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.Cc: Dave Airlie
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
13 Dec, 2016
1 commit
-
This pull request brings in VEC (TV-out) support for vc4, along with a
pageflipping race fix.* tag 'drm-vc4-next-2016-12-09' of https://github.com/anholt/linux:
drm/vc4: Don't use drm_put_dev
drm/vc4: Document VEC DT binding
drm/vc4: Add support for the VEC (Video Encoder) IP
drm: Add TV connector states to drm_connector_state
drm: Turn DRM_MODE_SUBCONNECTOR_xx definitions into an enum
drm/vc4: Fix ->clock_select setting for the VEC encoder
drm/vc4: Fix race between page flip completion event and clean-up
10 Dec, 2016
1 commit
-
Some generic TV connector properties are exposed in drm_mode_config, but
they are currently handled independently in each DRM encoder driver.Extend the drm_connector_state to store TV related states, and modify the
drm_atomic_connector_{set,get}_property() helpers to fill the connector
state accordingly.Each driver is then responsible for checking and applying the new config
in its ->atomic_mode_{check,set}() operations.Signed-off-by: Boris Brezillon
Reviewed-by: Daniel Vetter
Signed-off-by: Eric Anholt
01 Dec, 2016
1 commit
-
Many drivers (21 to be exact) create connectors that are always
connected (for instance to an LVDS or DSI panel). Instead of forcing
them to implement a dummy .detect() handler, make the callback optional
and consider the connector as always connected in that case.Reviewed-by: Alex Deucher
Acked-by: Maxime Ripard
Acked-by: Jyri Sarha
Acked-by: Jani Nikula
Acked-by: Philipp Zabel
Acked-by: Vincent Abriou
Acked-by: Alexey Brodkin
Signed-off-by: Laurent Pinchart
[seanpaul fixed small conflict in rcar-du/rcar_du_lvdscon.c]
Signed-off-by: Sean Paul
15 Nov, 2016
1 commit
-
And also put the overview section into the KMS Properties part of the
docs, instead of randomly-placed within the helpers - this is part of
the uabi.With this patch I think drm_crtc.[hc] is cleaned up and entirely
documented.Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
09 Nov, 2016
1 commit
-
The contents of drm_{plane,crtc,connector}_state is dumped before
commit. If a driver extends any of the state structs, it can implement
the corresponding funcs->atomic_print_state() to add it's own driver
specific state.Signed-off-by: Rob Clark
[seanpaul resolved conflict in drm_plane.h]
Signed-off-by: Sean Paul
10 Oct, 2016
1 commit
-
There is no late_unregister(), it looks like the comment meant
late_register(). Also fix a typo while at it.Signed-off-by: Grazvydas Ignotas
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1476032820-3275-1-git-send-email-notasas@gmail.com
04 Oct, 2016
2 commits
-
We have the drm_display_info for storing information about the sink, so
let's move dvi_dual and max_tmds_clock in there.v2: Deal with superfluous code shuffling
Document dvi_dual and max_tmds_clock tooCc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
Reviewed-by: Christian König (v1)
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-5-git-send-email-ville.syrjala@linux.intel.com -
We generally store clocks in kHz, so let's do that for the
HDMI max TMDS clock value as well. Less surpising.v2: Deal with superfluous code shuffling
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
Reviewed-by: Christian König (v1)
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-4-git-send-email-ville.syrjala@linux.intel.com
