While trying to find a random -EINVAL from a failing test, I noticed we
had a few hard to follow return values.

The first two hunks in this patch replace completely useless
initialization of ret. The last several hunks help to distinguish
between altering 'return ret' and 'return <ERROR>'
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrant <jakob@vmware.com>

At least drm/i915 expects that the obj->dev pointer is set even in
failure paths. Specifically when the shmem initialization fails we
call i915_gem_object_free which needs to deref obj->base.dev to get at
the slab pointer in the device private structure. And the shmem
allocation can easily fail when userspace is hitting open file limits.

Doing the structure init even when the shmem file allocation fails
prevents this Oops.

This is a regression from

commit 89c8233f
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Thu Jul 11 11:56:32 2013 +0200

    drm/gem: simplify object initialization

v2: Add regression note which Chris supplied.

Testcase: igt/gem_fd_exhaustion
Reported-and-Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
References: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
Cc: stable@vger.kernel.org
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It seems this got dropped when we merged UVD support
last year.  Add this back now.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Copy/paste typos from the ni code. Should not
have any functional change.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Needed to properly flush the read caches for fences.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We need to set the engine bit to select the ME and
also set the full cache bit.  Should help stability
on TN and cayman.

V2: fix up surface sync in ib execute as well
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Mclk switching doesn't seem to work reliably on these
cards.  Most RV770 boards specify the same mclk for all
performance levels anyway so in most cases, this has
no affect.

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

Need to swap the data for big endian.
Notcied by sylware in IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For consistency.  These buffers aren't used when pg is
disabled.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If the ss percentage is 0 or we are using external ss,
just bail when enabling ss.  We disable it explicitly
earlier in the modeset already.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's either 100 or 1000 depending on the flags in the
table.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is needed for reporting the max GPU engine clock
in OpenCL.  This just reports the max possible engine
clock, it does not take into account current conditions
that may limit that clock.

v2: fix query number for merge with 3.13
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
CEA-861E Table 4. This is useful for filling up the detail in AVI
infoframe.

v2: Ville's review comments incorporated
Added picture aspect ratio as part of edid_cea_modes instead of DRM_MODE
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to the DP 1.1 spec, the sink must power
up within 1ms.  Noticed while reviewing Thierry's
drm/dp patches.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Based on common dp code proposed by Thierry Reding.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

As per the DP1.2 spec.  Noticed while reviewing
Thierry's drm/dp patches. Also bump native aux
retries to 7 for consistency.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Seems to cause problems with certain DP monitors.

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

Use the hw power up values rather than 0.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Still unstable on some boards.

Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=73053
https://bugzilla.kernel.org/show_bug.cgi?id=68571Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: 3.13 <stable@vger.kernel.org> # 3.13

This is the preferred flushing method on CIK.

Note, this only works on the PFP so the engine bit must be
set.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is the preferred flushing method on CIK.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's used in several places so move to a common shared
function.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's used in several places so move to a common shared
function.
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>

This reverts commit 99b4f251.

Semaphores work fine after further review and testing.
Cc: 3.13 <stable@vger.kernel.org> # 3.13

Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.

v2: Use an offset value depending on 3D_Multi_present and add
    detail_present. (Ville Syrjälä)
v3: Make sure the list is parsed even if 3D_Structure_ALL/MASK is not
    present. (Ville Syrjälä)
    Fix one length check and remove another. (Ville Syrjälä)
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as
far as display interrupts are concerned. Instead it sort of looks like
some ISR bits just directly reflect the corresponding bit from PIPESTAT.
The bit appears in the ISR only if the PIPESTAT interrupt is enabled. So
in that sense it sort of looks a bit like the south interrupt scheme on
PCH platforms. So it goes something a bit like this:
PIPESTAT.status & PIPESTAT.enable -> ISR -> IMR -> IIR -> IER -> actual
interrupt

In any case that means the intel_pipe_in_vblank_locked() doesn't actually
work for pre-PCH platforms. As a last resort, add a similar kludge as radeon
has that fixes things up if we got called from the vblank interrupt,
but the scanline counter value indicates that we're not quite there yet.
We know that the scanline counter increments at hsync but is otherwise
accurate, so we can limit the kludge to the line just prior to vblank
start, instead of the relative distance that radeon uses.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

i915 doesn't need this kludge for most platforms. Although we do
appear to need something similar on certain platforms, but we can
be more accurate when we apply the adjustment since we know exactly
why the scanline counter doesn't always quite match the vblank
status.

Also the current code doesn't handle interlaced modes correctly,
and we already deal with interlaced modes in i915 code.

So let's just move the current code to radeon_get_crtc_scanoutpos()
since that's why it was added. For i915 we'll add a more finely
targeted variant.

v2: Fix vpos vs. *vpos bug (Mario)

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().

v2: Fix radeon_drv.c compile warning (Mario)

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

We're currently miscalculating the line and pixel durations for
interlaced modes. crtc_htotal and crtc_vtotal are the full frame
timings, and so is crtc_clock, so we can compute the line
and pixel durations from those w/o any extra adjustments. But
we actually want framedur_ns to be the field, not frame, duration,
so we must divide it by two.

This should make the scanout based vblank timestamp corrections
work correctly with interlaced modes, at least for i915. It all
depends whether we keep the field or frame timings in the display
mode crtc_ timings.

v2: Preserve halve->half typo fix that happened in the meantine

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

The scanline counter counts lines in the current field, not the entire
frame. But the crtc_ timings are the values for the entire frame. Divide
the vertical timings by 2 to make them match the scanline counter.

The rounding was carefully chosen to make it do the right thing wrt. the
observed scanline counter and ISR vblank bit behaviour.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Using s64 for the timestamping constants is wasteful. Signed 32bit
integers get us a range of over +-2 seconds. Presuming that no-one
wants to a vrefresh rate less than 0.5, we can switch to using int
for the timestamping constants. We save a few bytes in drm_crtc and
avoid a bunch of 64bit math.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

drm_calc_timestamping_constants() computes the pixel/line/frame
durations based on the crtc_ timing values. The corresponding pixel
clock is in mode->crtc_clock, so we need to use that instead of
mode->clock.

This should fix drm_calc_timestamping_constants() for frame packing
stereo modes.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

crtc_clock is now supposed to be the actual pixel clock corresponding to
the other crtc_ timing values. Populate crtc_clock appropriately in
radeon_atom_get_tv_timings().

This was the only obvious place where we frob with the crtc_ timigns
directly instead of calling drm_mode_set_crtcinfo() which would also
update crtc_clock.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

drm_calc_timestamping_constants() makes the math more complex
than necessary.
- multipying the dotclock by 1000 is pointless, just makes all the
  numbers bigger
- div64_u64() is also pointless, div_u64 is enough
- pixeldur_ns doesn't need any 64bit math

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Move the long blurp to into the body of the comment, leaving only
a short summary line at the top.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Update the pixel/line/frame duration information when we switch to the
new pipe config. This will keep the timestamping constants in better
sync with the real hardware state.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

drm core no longer uses crtc->hwmode, and neither does i915, so we can totally ignore it
in i915.

Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>