YUYV is UYVY with swapped bytes. Luckily the Tegra DC hardware can swap
bytes during scan-out, so supporting YUYV is simply a matter of writing
the correct value to the byteswap register.

This patch modifies tegra_dc_format() to return the byte swap parameter
via an output parameter in addition to returning the pixel format. Many
other formats can potentially be supported in a similar way.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Remove extern keyword from function prototypes since it isn't needed and
drop an unnecessary forward declaration.
Signed-off-by: NThierry Reding <treding@nvidia.com>

All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same
locking.  Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked().
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.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>

This should avoid races between connector probing and HPD
irqs in the future, currently mode_config.mutex blocks this
possibility.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The drm core shouldn't depend upon any helpers, and we make sure this
doesn't accidentally happen by moving them into the helper-only
drm_kms_helper.ko module.

v2: Don't break the build for vmwgfx, spotted by Matt.

v3: Unbreak the depency loop around CONFIG_FB (not actually a loop
since it involves select). Reported by Chris.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-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>

I find myself making this change locally whenever debugging FB reference
counting.  Which seems a bit silly.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@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>

Generated using semantic patch:

@@
expression E;
@@

- drm_get_encoder_name(E)
+ E->name
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>

Generated using semantic patches:

@@
expression E;
@@

- drm_get_encoder_name(&E)
+ E.name

@@
expression E;
@@

- drm_get_encoder_name(E)
+ E->name

v2: Turn drm_get_encoder_name(&E) into E.name instead of &(E)->name.
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>

Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E->name

[airlied: regenerated]
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>

Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E->name

[airlied: regenerated]
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
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>

Generated using semantic patches:

@@
expression E;
@@

- drm_get_connector_name(&E)
+ E.name

@@
expression E;
@@

- drm_get_connector_name(E)
+ E->name

v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name.
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>

Generated using semantic patches:

@@
expression E;
@@

- drm_get_connector_name(&E)
+ E.name

@@
expression E;
@@

- drm_get_connector_name(E)
+ E->name

v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name.
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>

spice-server and downstream code expect that the primary surface
will always have surface_id = 0, while in reality, once allocated, the
surface_id in qxl.ko is NEVER 0.  In a dual head environment, all
monitors render portions of the primary surface.

However, when the monitor config events are generated and sent,
the primary surface is only mapped to the correct identifier
(i.e. 0) for the primary head (where crtc index is 0).

The fix is to look at the "primary" flag in the bo and always
use id 0, irrespective of which head is being configured.

[airlied: qxl hw really needs to be fixed to scanout surfaces]
Signed-off-by: NDave Airlie <airlied@redhat.com>

Instead of trying to flip inside the vblank period when
the buffer is idle, offload blocking for idle to a kernel
thread and program the flip directly into the hardware.

v2: add error handling, fix EBUSY handling
v3: add proper exclusive_lock handling
v4: update crtc->primary->fb when the flip actually happens
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit 1aab5514.

Apply the fixed up version instead.

The Sony PVM-2541A OLED high precision color display supports
both 10 bpc and 12 bpc hdmi deep color input, but its edid
does not signal any deep color support.

Add a quirk to force it being treated as a 12 bpc panel.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Check the HDMI cea block for deep color mode bits. If available,
assign the highest supported bpc for a hdmi display, corresponding
to the given deep color modes.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

DCE-4/5/6 can't support more than 12 bpc deep color over hdmi,
so clamp to 12 bpc when a hdmi deep color capable display is
connected. This even makes sense on DCE-8+, which could do up
to 16 bpc, as driving with more than 12 bpc would only waste
video bandwidth as long as we don't support framebuffers with
more than 12 bpc depth.

On pre-DCE4 we clamp hdmi bit depth to 8 bpc, as those asics
don't support hdmi deep color.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Program HDMI_CONTROL to send general control packets
for hdmi deep color mode signalling at every video
frame if bpc > 8.

This is only supported on evergreen / DCE-4 and later.

v2: rebase
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to adjust the pll up for deep color modes.
Additionally, the atom bpc defines were wrong in certain
cases.

v2: set the adjusted clock to the pll clock for hdmi deep
color.  This fixes display and audio issues with deep color
as reported by Andy Furniss <adf.lists@gmail.com>

v3: set crtc_clock as well

v4: setcrtcinfo on the adjusted mode

v5: just use the adjusted clock for setting the pll

v6: only use the adjusted clock for hdmi

v7: only DCE5 and DCE6 and bpc > 8
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

I'm not really sure how these should be calculated
for deep color.  The hw generated values seem to work.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

May fix display issues with non-HDMI displays.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We need to specify the encoder mode as LVDS for eDP
when using the Crtc_Source atom table in order to properly
set up the FMT hardware.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73911Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Fill VM page tables from the GART page table if applicable.

v2: fix copy&paste error
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fill VM page tables from the GART page table if applicable.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Instead of trying to flip inside the vblank period when
the buffer is idle, offload blocking for idle to a kernel
thread and program the flip directly into the hardware.

v2: add error handling, fix EBUSY handling
v3: add proper exclusive_lock handling
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We activate the VBLANK irq manually anyway, so this is unnecessary.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

They are doing the same on all generations anyway.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Only DCE5+ asics support DP 1.2.

Noticed by ArtForz on IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We were checking the ext clock rather than the display clock.

Noticed by ArtForz on IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org