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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181012184233.29250-1-radhakrishna.sripada@intel.com

Unfortunately, it appears our fix in:
commit b5d29843 ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")

Which attempted to work around the problems introduced by:
commit 4d802739 ("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 4d802739 ("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: b5d29843 ("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: NLyude Paul <lyude@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
(cherry picked from commit 39b50c60)
Fixes: e9655095 ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Fixes: 34ca26a9 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: stable@vger.kernel.org
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Unfortunately, it appears our fix in:
commit b5d29843 ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")

Which attempted to work around the problems introduced by:
commit 4d802739 ("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 4d802739 ("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: b5d29843 ("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: NLyude Paul <lyude@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com

We have a bunch of neat little macros all over the place which should
move to kernel.h. But some of them died in bikesheds on lkml, and we
need a decent home for them.

Start out by moving the for_each_if macro there.

v2: Rename to drm_util.h instead (Dave&Sean)

Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NSean Paul <seanpaul@chromium.org>
Cc: Dave Airlie <airlied@gmail.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180905135711.28370-1-daniel.vetter@ffwll.ch

Since there's very few callers of these I've decided to do them all in
one patch. With this the unecessarily long drm_mode_connector_ prefix
is gone from the codebase! The only exception being struct
drm_mode_connector_set_property, which is part of the uapi so can't be
renamed.

Again done with sed+some manual fixups for indent issues.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-8-daniel.vetter@ffwll.ch

Again to align with the usual prefix of just drm_connector_. Again
done with sed + manual fixup for indent issues.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-7-daniel.vetter@ffwll.ch

Just makes it longer, and for most things in drm_connector.[hc] we
just use the drm_connector_ prefix. Done with sed + a bit of manual
fixup for the indenting.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-6-daniel.vetter@ffwll.ch

- switch everything over to inline comments
- add notes about locking, links to functions and other related stuff
- also include a note about Ville's soon-to-be-merged
  drm_connector_for_each_possible_encoder().

Also check that all the hyperlinks in drm_connector.h work and fix
them as needed.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-5-daniel.vetter@ffwll.ch

For consistency. Also spelled out the docs for ->best_encoder a bit
more while at it.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-4-daniel.vetter@ffwll.ch

The sync in some panels needs to be driven by different edge of the pixel
clock compared to data. This is reflected by the
DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in videmode flags.
Add similar similar definitions for bus_flags and convert the sync drive
edge via drm_bus_flags_from_videomode().
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618132242.8673-2-tomi.valkeinen@ti.com

Add a small helper for checking whether a connector and
encoder are associated with each other.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180628131315.14156-8-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>

Add a convenience macro for iterating connector->encoder_ids[].
Isolates the users from the implementation details.

Note that we don't seem to pass the file_priv down to drm_encoder_find()
because encoders apparently don't get leased. No idea why
drm_encoder_finc() even takes the file_priv actually.

Also use ARRAY_SIZE() when populating the array to avoid spreading
knowledge about the array size all over.

v2: Hide the drm_encoder_find() in the macro, and
    rename the macro appropriately (Daniel)
v3: Fix kernel docs (Daniel)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180628131315.14156-4-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add drm_connector_mask() which returns the 1<<index for the connector.
We already have an identical drm_crtc_mask() for crtcs.

Mostly performed with coccinelle:
@@
@@
- (1<<drm_connector_index(
+ drm_connector_mask(
  ...)
-  )

@@
@@
- 1<<drm_connector_index(
+ drm_connector_mask(
  ...)

@@
@@
- BIT(drm_connector_index(
+ drm_connector_mask(
  ...)
- )
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626194716.12522-4-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.

A timeline is added to drm_writeback_connector for use by the writeback
out-fences.

In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
is set to -1.

Changes from v2:
 - Rebase onto Gustavo Padovan's v9 explicit sync series
 - Change out_fence_ptr type to s32 __user *
 - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
 - Store fence in drm_writeback_job
 Gustavo Padovan:
 - Move out_fence_ptr out of connector_state
 - Signal fence from drm_writeback_signal_completion instead of
   in driver directly

Changes from v3:
 - Rebase onto commit 7e9081c5 ("drm/fence: fix memory overwrite
   when setting out_fence fd") (change out_fence_ptr to s32 __user *,
   for real this time.)
 - Update documentation around WRITEBACK_OUT_FENCE_PTR
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/229036/

Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.

Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeback-specific details on top of the normal functionality of
drm_connector_init().

Writeback connectors have a WRITEBACK_FB_ID property, used to set the
output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
supported writeback formats to userspace.

When a framebuffer is attached to a writeback connector with the
WRITEBACK_FB_ID property, it is used only once (for the commit in which
it was included), and userspace can never read back the value of
WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
attached to a CRTC.

Changes since v1:
 - Added drm_writeback.c + documentation
 - Added helper to initialize writeback connector in one go
 - Added core checks
 - Squashed into a single commit
 - Dropped the client cap
 - Writeback framebuffers are no longer persistent

Changes since v2:
 Daniel Vetter:
 - Subclass drm_connector to drm_writeback_connector
 - Relax check to allow CRTC to be set without an FB
 - Add some writeback_ prefixes
 - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
 Gustavo Padovan:
 - Add drm_writeback_job to handle writeback signalling centrally

Changes since v3:
 - Rebased
 - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS

Chances since v4:
 - Embed a drm_encoder inside the drm_writeback_connector to
   reduce the amount of boilerplate code required from the drivers
   that are using it.

Changes since v5:
 - Added Rob Clark's atomic_commit() vfunc to connector helper
   funcs, so that writeback jobs are committed from atomic helpers
 - Updated create_writeback_properties() signature to return an
   error code rather than a boolean false for failure.
 - Free writeback job with the connector state rather than when
   doing the cleanup_work()

Changes since v7:
 - fix extraneous use of out_fence that is only introduced in a
   subsequent patch.

Changes since v8:
 - whitespace changes pull from subsequent patch

Changes since v9:
 - Revert the v6 changes that free the writeback job in the connector
   state cleanup and return to doing it in the cleanup_work() function
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
[rebased and added atomic_commit() vfunc for writeback jobs]
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/229037/

This patch add checks for atomic_[duplicate/destroy]_state of
drm_[connector/crtc/plane]_funcs for atomic drivers in the relevant
drm_*_init functions since these callback are mandatory for atomic drivers.

Update the kerneldoc comments for those callbacks.
Signed-off-by: NHaneen Mohammed <hamohammed.sa@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525012555.GA8448@haneen-vb

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

v10:
 * Added usage description to HDMI properties kernel doc.

v11:
 * Created centralized function for filling HDMI AVI infoframe, based
   on correspondent DRM property value.
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

A bit boring documentation fix, but gets rid of the warnings:

./include/drm/drm_connector.h:370: warning: Function parameter or member 'margins.left' not described in 'drm_tv_connector_state'
./include/drm/drm_connector.h:370: warning: Function parameter or member 'margins.right' not described in 'drm_tv_connector_state'
./include/drm/drm_connector.h:370: warning: Function parameter or member 'margins.top' not described in 'drm_tv_connector_state'
./include/drm/drm_connector.h:370: warning: Function parameter or member 'margins.bottom' not described in 'drm_tv_connector_state'

[Depends on fe7bc493 ("scripts: kernel-doc: support in-line comments
on nested structs/unions") in docs-next to actually fix the warnings.]
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219104009.4887-1-jani.nikula@intel.com

This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.

The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this value

The driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.

If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.

Changes in v2:
 - Pimp kerneldoc for content_protection_property (Daniel)
 - Drop sysfs attribute
Changes in v3:
 - None
Changes in v4:
- Changed kerneldoc to recommend userspace polling (Daniel)
- Changed kerneldoc to briefly describe how to attach the property (Daniel)
Changes in v5:
- checkpatch whitespace noise
- Change DRM_MODE_CONTENT_PROTECTION_OFF to DRM_MODE_CONTENT_PROTECTION_UNDESIRED
Changes in v6:
- None
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-4-seanpaul@chromium.org

PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.

Fix this by using just a single cleanup work, so that we can only
flush that one and don't block on anything else. That means a free
list plus locking, a standard pattern.

v2:
- Correctly free connectors only on last ref. Oops (Chris).
- use llist_head/node (Chris).

v3
- Add init_llist_head (Chris).

Fixes: a703c550 ("drm: safely free connectors from connector_iter")
Fixes: 613051da ("drm: locking&new iterators for connector_list")
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: <stable@vger.kernel.org> # v4.11+: 613051da ("drm: locking&new iterators for connector_list"
Cc: <stable@vger.kernel.org> # v4.11+
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Guillaume Tucker <guillaume.tucker@collabora.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Matt Hart <matthew.hart@linaro.org>
Cc: Thierry Escande <thierry.escande@collabora.co.uk>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch

In

commit 613051da
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 14 00:08:06 2016 +0100

    drm: locking&new iterators for connector_list

we've went to extreme lengths to make sure connector iterations works
in any context, without introducing any additional locking context.
This worked, except for a small fumble in the implementation:

When we actually race with a concurrent connector unplug event, and
our temporary connector reference turns out to be the final one, then
everything breaks: We call the connector release function from
whatever context we happen to be in, which can be an irq/atomic
context. And connector freeing grabs all kinds of locks and stuff.

Fix this by creating a specially safe put function for connetor_iter,
which (in this rare case) punts the cleanup to a worker.
Reported-by: NBen Widawsky <ben@bwidawsk.net>
Cc: Ben Widawsky <ben@bwidawsk.net>
Fixes: 613051da ("drm: locking&new iterators for connector_list")
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: <stable@vger.kernel.org> # v4.11+
Reviewed-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171204204818.24745-1-daniel.vetter@ffwll.ch

On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).

This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to communicate how the panel is
orientated vs the casing.

Userspace can use this property to check for non-normal orientation and
then adjust the displayed image accordingly by rotating it to compensate.

Changes in v2:
-Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
 access it easily
-Have a single drm_connector_init_panel_orientation_property rather then
 create and attach functions. The caller is expected to set
 drm_display_info.panel_orientation before calling this, then this will
 check for platform specific quirks overriding the panel_orientation and if
 the panel_orientation is set after this then it will attach the property.

Changes in v6:
-Use an enum (with kerneldoc) rather then #defines for
 DRM_MODE_PANEL_ORIENTATION_*
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-4-hdegoede@redhat.com

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: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

fixup docs

Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
HDMI 1.4 does allow for this behaviour, stating that sending the
infoframe is optional in this case.

The infoframe was first specified in HDMI 1.4, so in theory sinks
predating that may not appreciate us sending an uknown infoframe
their way. To avoid regressions let's try to determine if the sink
supports the infoframe or not. Unfortunately there's no direct way
to do that, so instead we'll just check if we managed to parse any
HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
sink will accept the infoframe. Also if the EDID contains the HDMI
2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
the infoframe.

v2: Fix getting has_hdmi_infoframe from display_info
    Always fail constructing the infoframe if the display
    possibly can't handle it

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-3-ville.syrjala@linux.intel.com

The lease updates missed a few bits of docs, fixed up
the wrong name on the property lookup fn as well.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Point at the equivalent atomic state and explain that atomic drivers
shouldn't really depend upon legacy state.

Motivated by questions from Manasi about how this all is supposed to
work.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108203007.12274-1-daniel.vetter@ffwll.ch

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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now that the last users have been converted, we can finally get rid of
for_each_obj_in_state, we have better macros to replace them with.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719143920.25685-8-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we neatly track the crtc state, but forget to look at
plane/connector state.

When doing a nonblocking modeset, immediately followed by a setprop
before the modeset completes, the setprop will see the modesets new
state as the old state and free it.

This has to be solved by waiting for hw_done on the connector, even
if it's not assigned to a crtc. When a connector is unbound we take
the last crtc commit, and when it stays unbound we create a new
fake crtc commit for that gets signaled on hw_done for all the
planes/connectors.

We wait for it the same way as we do for crtc's, which will make
sure we never run into a use-after-free situation.

Changes since v1:
- Only create a single disable commit. (danvet)
- Fix leak in intel_legacy_cursor_update.
Changes since v2:
- Make reference counting in drm_atomic_helper_setup_commit
  more obvious. (pinchartl)
- Call cleanup_done for fake commit. (danvet)
- Add comments to drm_atomic_helper_setup_commit. (danvet, pinchartl)
- Add comment to drm_atomic_helper_swap_state. (pinchartl)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Testcase: kms_atomic_transition.plane-use-after-nonblocking-unbind*
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170904104838.23822-6-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170725120204.2107-1-daniel.vetter@ffwll.ch

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: NShashank 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: NVille 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: NShashank 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: NVille 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: NShashank 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: NVille Syrjälä <ville.syrjala@linux.intel.com>

Forward declarations in C are great but I'm pretty sure one is enough.
Signed-off-by: NDawid Kurek <dawikur@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170614213518.GA3554@gmail.com

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: NGustavo Padovan <gustavo.padovan@collabora.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170511191049.28944-8-gustavo@padovan.org

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: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421003819.17685-1-krisman@collabora.co.uk

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170501133804.8116-3-maarten.lankhorst@linux.intel.com
[mlankhorst: Rename function, fix docbook issues]
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1491504920-4017-1-git-send-email-maarten.lankhorst@linux.intel.com

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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>