Including headers somewhere else but at the top is ugly, deprecated and
was used in early days only to speed up compile-times. Those days are
over. Make headers independent and then move the inclusions to the top.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make sure plane rotation is reset correctly when restoring the fbdev
configuration by using drm_mode_plane_set_obj_prop which calls the
driver's set_property callback.

The rotation reset feature was introduced in commit 9783de20 (drm:
Resetting rotation property) and the callback issue was originally
addressed in a previous version of the patch, but the fix was not
present in the final version.

v2: Fix documentation warning
    Add some more details to the commit message (Daniel Vetter)

Testcase: igt/kms_rotation_crc
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82236
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In general having this can't hurt, and the atomic helpers will need
it to be able to reset the state objects properly. The overall idea
is to reset in the order pixels flow, so planes -> crtcs ->
encoders -> connectors.

v2: Squash in fixup from Ville to correctly deference struct drm_plane
instead of drm_crtc when walking the plane list. Fixes an oops in
driver init and resume.
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.

The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then it might potentially unref an
outdated framebuffer. To fix that move the old_fb temporary storage
into struct drm_plane for all ioctls, so that the atomic helpers can
update it.

v2: Fix up the error case handling as suggested by Matt Roper and just
grab locks uncoditionally - there's no point in optimizing the locking
for when userspace gets it wrong.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.

Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those paths which grab all locks we already
have to keep around an acquire context in dev->mode_config. Helper
functions that implement legacy interfaces in terms of atomic support
can therefore grab this acquire contexts and reuse it.

The only interfaces left are the cursor and pageflip ioctls. So add
functions to grab the crtc lock these need using an acquire context
and preserve it for atomic drivers to reuse.

v2:
- Fixup comments&kerneldoc.
- Drop the WARNING from modeset_lock_all_crtcs since that can be used
  in legacy paths with crtc locking.

v3: Fix a type on the kerneldoc Dave spotted.

Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Somehow we've forgotten about this little bit of OCD.
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.

If it later on turns out that the list walking is too expensive we can
add the index to the relevant modeset objects.

Rob Clark doesn't like the loops too much, but we can always add an
obj->idx parameter later on. And for now reiterating is actually safer
since nowadays we have hotpluggable connectors (thanks to DP MST).

v2: Fix embarrassing copypasta fail in kerneldoc and header
declarations, spotted by Matt Roper.

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed by drm_fb_helper_initial_config() which is called after
i915.ko's custom initial_config() as a fallback method. So in order for
us to honour it, we need to move the cmdline parser earlier. If we
perform the connector cmdline parsing as soon as we initialise the
connector, that cmdline mode and forced status is then available even if
the fbdev helper is not compiled in or never called.

We also then expose the cmdline user mode in the connector mode lists.

v2: Rebase after connector->name upheaval.

v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely
simplifies things while at that.

v4: Fix checkpatch.

v5: Select FB_CMDLINE to adapt to the changed fbdev patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Cc: dri-devel@lists.freedesktop.org
Cc: Julia Lemire <jlemire@matrox.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.

v2: Thierry's review comments.
	- Made aspect ratio enum generic instead of HDMI/CEA specfic
	- Removed usage of temporary aspect_ratio variable

v3: Thierry's review comments.
	- Fixed indentation

v4: Thierry's review comments.
	- Return ENOMEM when property creation fails
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope is
that this identity transform will eliminate the unsupported flags.

Of course that might not result in any more supported rotation, so
the caller is still responsible for checking the result afterwards.

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a function to create a standards compliant rotation property.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.

v2: Populate values[] array as non-sparse
    Make supported_bits 64bit
    Fix up omapdrm call site (Rob)

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSagar Kamble <sagar.a.kamble@intel.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The rotation property stuff should be standardized among all drivers.
Move the bits to drm_crtc.h from omap_drv.h.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a helper to allow encoders to find their possible CRTCs from the
OF graph without having to re-implement this functionality.  We add a
device_node to drm_crtc which corresponds with the port node in the
DT description of the CRTC device.

We can then scan the DRM device list for CRTCs to find their index,
matching the appropriate CRTC using the port device_node, thus building
up the possible CRTC mask.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This can be called to update things after dynamic connectors/encoders
are created/deleted.
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a file to debugfs for each connector to allow the EDID to be
overridden.

v2: Copy ubuf before accessing it and reject invalid length data. (David
    Herrmann)
    Ensure override_edid is reset when a new EDID value is written.
    (David Herrmann)
    Fix the debugfs file permissions. (David Herrmann)
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a file to debugfs for each connector to enable modification of the
"force" connector attribute. This allows connectors to be enabled or
disabled for testing and debugging purposes.

v2: Add stricter value checking and clean up debugfs_entry if file
    creation fails in drm_debugfs_connector_add. (David Herrmann)
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Introduce generic functions to register and unregister connectors. This
provides a common place to add and remove associated user space
interfaces.
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Universal plane support had placeholders for cursor planes, but didn't
actually do anything with them.  Save the cursor plane reference inside
the crtc and update the cursor plane parameter from void* to drm_plane.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls.  Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition to universal planes will continue to operate
without any change to behavior.

Note that there's a bit of a mismatch between the legacy cursor ioctls
and the universal plane API's --- legacy ioctl's use driver buffer
handles directly whereas the universal plane API takes drm_framebuffers.
Since there's no way to recover the driver handle from a
drm_framebuffer, we can implement legacy ioctl's in terms of universal
plane interfaces, but cannot implement universal plane interfaces in
terms of legacy ioctls.  Specifically, there's no way to create a
general cursor helper in the way we previously created a primary plane
helper.

It's important to land this patch before any patches that add universal
cursor support to individual drivers so that drivers don't have to worry
about juggling two different styles of reference counting for cursor
buffers when userspace mixes and matches legacy and universal cursor
calls.  With this patch, a driver that switches to universal cursor
support may assume that all cursor buffers are wrapped in a
drm_framebuffer and can rely on framebuffer reference counting for all
cursor operations.

v4:
 - Add comments pointing out setplane_internal's reference-eating
   semantics.
v3:
 - Drop drm_mode_rmfb() call that is no longer needed now that we're
   using setplane_internal(), which takes care of deref'ing the
   appropriate framebuffer.
v2:
 - Use new add_framebuffer_internal() function to create framebuffer
   rather than trying to call directly into the ioctl interface and
   look up the handle returned.
 - Use new setplane_internal() function to update the cursor plane
   rather than calling through the ioctl interface.  Note that since
   we're no longer looking up an fb_id, no extra reference will be
   taken here.
 - Grab extra reference to fb under lock in !BO case to avoid issues
   where racing userspace could cause the fb to be destroyed out from
   under us after we grab the fb pointer.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

HDMI deep color setup must know which modes are supported if
it needs to degrade gracefully, as only 12 bpc / dc_36 is
guaranteed, but 10 bpc / dc_30 is optional. The maximum bpc
is not sufficient for this.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For atomic, it will be quite necessary to not need to care so much
about locking order.  And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.

Because we will want to eventually make locking even more fine grained
(giving locks to planes, connectors, etc), split out drm_modeset_lock
and drm_modeset_acquire_ctx to track acquired locks.

Atomic will use this to keep track of which locks have been acquired
in a transaction.

v1: original
v2: remove a few things not needed until atomic, for now
v3: update for v3 of connection_mutex patch..
v4: squash in docbook
v5: doc tweaks/fixes
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
  properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
  modeset-relevant connector state (e.g. properties which control the
  panel fitter).

The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.

Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.

The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.

For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.

Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.

I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
  sprinkle mode_config.connection_mutex over this file a bit, but
  since it already lacks mode_config.mutex this patch wont make the
  situation any worse. This is material for a follow-up patch.

- omap has a omap_framebuffer_flush function which walks the
  connector->encoder->crtc links and is called from many contexts.
  Some look like they don't acquire mode_config.mutex, so this is
  already racy. Again fixing this is material for a separate patch.

- The radeon hot_plug function to retrain DP links looks at
  connector->dpms. Currently this happens without any locking, so is
  already racy. I think radeon_hotplug_work_func should gain
  mutex_lock/unlock calls for the mode_config.connection_mutex.

- Same applies to i915's intel_dp_hot_plug. But again, this is already
  racy.

- i915 load_detect code needs to acquire this lock. Which means the
  w/w dance due to Rob's work will be nicely contained to _just_ this
  function.

I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.

v1: original (only compile tested)

v2: missing mutex_init(), etc (from Rob Clark)

v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
  get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.

Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Like range, but values are signed.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>

An object property is an id (idr) for a drm mode object.  This
will allow a property to be used set/get a framebuffer, CRTC, etc.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we continue to use bitmask for type, we will quickly run out of room
to add new types.  Split this up so existing part of bitmask range
continues to function as before, but reserve a chunk of the remaining
space for an integer type-id.  Wrap this all up in some type-check
helpers to keep the backwards-compat uglyness contained.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a few more useful helpers to find mode objects.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No longer used or needed as the structs have a name field.
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes drm_get_encoder_name() thread safe.

Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3@DC1-MBX-01\
.ptsecurity.ru
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes drm_get_connector_name() thread safe.

[airlied: fix to build.]

Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3@DC1-MBX-01.ptsecurity.ruSigned-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This mode group id_list was never being freed.

v2: take David's suggestion to free in minor_free.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Populate PAR in infoframe structure. If there is a user setting for PAR, then
that value is set. Else, value is taken from CEA mode list if VIC is found.
Else, PAR is calculated from resolution. If none of these conditions are
satisfied, PAR is NONE as per initialization.

v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.

A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.

v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.

v3: Removed calculation of PAR for non-CEA modes as per discussion with
Ville.

A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Cc: Jesse Barnes <jesse.barnes@intel.com>
Cc: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Squash in fixup for htmldocs.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Add a new drm_crtc_init_with_planes() to allow drivers to provide
specific primary and cursor planes at CRTC initialization.  The existing
drm_crtc_init() interface remains to avoid driver churn in existing
drivers; it will initialize the CRTC with a plane helper-created primary
plane and no cursor plane.

v2:
  - Move drm_crtc_init() to plane helper file so that nothing in the DRM
    core depends on helpers.  [suggested by Daniel Vetter]
  - Keep cursor parameter to drm_crtc_init_with_planes() a void* until
    we actually add cursor support.  [suggested by Daniel Vetter]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Add a plane type property to allow userspace to distinguish plane types.

v2: Driver-specific churn eliminated now that drm_plane_init() and
    drm_universal_plane_init() were separated out in a previous patch.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Add a new plane initialization interface for universal plane support
that allows a specific plane type (primary, cursor, or overlay) to
be specified.

drm_plane_init() remains as a compatibility API to reduce churn in
existing drivers.  The 'bool priv' parameter has been changed to
'bool is_primary' under the assumption that all existing uses of
private planes were representing primary planes.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

This function will be used by the universal plane helpers and may also
be useful for individual drivers.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

The DRM core currently only tracks "overlay"-style planes.  Start
refactoring the plane handling to allow other plane types (primary and
cursor) to also be placed on the DRM plane list.

v2: Add drm_for_each_legacy_plane() iterator to smooth transition
    of drivers with plane loops.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>