drm/atomic: Rename drm_atomic_helper_commit_pre_planes() state argument

The argument contains a pointer to the old state, rename it to old_state
like in all other commit helper functions.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: If available use atomic state in getcrtc ioctl

This way drivers fully converted to atomic don't need to update these
legacy state variables in their modeset code any more.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: Add DRM_DEBUG_ATOMIC

Atomic state handling adds a lot of indirection and complexity between
simple updates and drivers. For easier debugging the diagnostic output
is therefore rather chatty. Which is great for tracking down atomic
issues, but really annoying otherwise.

Add a new DRM_DEBUG_ATOMIC to be able to filter this out.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/atomic-helpers: Fix documentation typos and wrong copy&paste

The kerneldoc blocks for the drm_atomic_helper_*_set_property()
functions seem to have been copied from the plane disable handler
without being properly updated. Fix them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Fix the CRTC_STEREO_DOUBLE_ONLY define to include stero modes

The CRTC_STEREO_DOUBLE_ONLY define was introduced in commit:

  commit ecb7e16bf187bc369cf6a5cd108582c01329980d
  Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
  Date:   Mon Dec 1 15:40:09 2014 -0800

      drm: add helper to get crtc timings (v5)

but if we want the stereo h/v adjustments, we need to set the
CRTC_STEREO_DOUBLE flag. Otherwise, we'll get the wrong h/v for frame packing
stereo 3d modes.

Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Fix drm_crtc_vblank_get() documentation

drm_crtc_vblank_get() is the new drm_vblank_get(), not the new
drm_vblank_off().

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'drm-next-3.20' of git://people.freedesktop.org/~agd5f/linux into drm-next

Some radeon fixes for 3.20.

* 'drm-next-3.20' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: only enable kv/kb dpm interrupts once v3
  drm/radeon: workaround for CP HW bug on CIK
  drm/radeon: Don't try to enable write-combining without PAT
  drm/radeon: use 0-255 rather than 0-100 for pwm fan range

Merge tag 'drm-intel-next-fixes-2015-02-11' of git://anongit.freedesktop.org/drm-intel into drm-next

Here's a batch of i915 fixes for drm-next, with more cc: stable material
than fixes specific to drm-next.

* tag 'drm-intel-next-fixes-2015-02-11' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Clamp efficient frequency to valid range
  drm/i915: Really ignore long HPD pulses on eDP
  drm/i915: Correct the base value while updating LP_OUTPUT_HOLD in MIPI_PORT_CTRL
  drm/i915: Insert a command barrier on BLT/BSD cache flushes
  drm/i915: Drop vblank wait from intel_dp_link_down
  drm/i915: Squelch overzealous uncore reset WARN_ON
  drm/i915: Take runtime pm reference on hangcheck_info
  drm/i915: Correct the IOSF Dev_FN field for IOSF transfers
  drm/i915: Prevent use-after-free in invalidate_range_start callback

drm/radeon: only enable kv/kb dpm interrupts once v3

Enable at init and disable on fini. Workaround for hardware problems.

v2 (chk): extend commit message
v3: add new function

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com> (v2)
Cc: stable@vger.kernel.org

drm/radeon: workaround for CP HW bug on CIK

Emit the EOP twice to avoid cache flushing problems.

Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Don't try to enable write-combining without PAT

Doing so can cause things to become slow.

Print a warning at compile time and an informative message at runtime in
that case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: use 0-255 rather than 0-100 for pwm fan range

0-255 seems to be the preferred range for the pwm interface.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/i915: Clamp efficient frequency to valid range

The efficient frequency (RPe) should stay in the range
RPn <= RPe <= RP0.  The pcode clamps the returned value
internally on Broadwell but not on Haswell.

Fix for missing range check in
commit 93ee29203f506582cca2bcec5f05041526d9ab0a
Author: Tom O'Rourke <Tom.O'Rourke@intel.com>
Date:   Wed Nov 19 14:21:52 2014 -0800

    drm/i915: Use efficient frequency for HSW/BDW

Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/059802.html
Reported-by: Michael Auchter <a@phire.org>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org # v3.19
Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Really ignore long HPD pulses on eDP

Return IRQ_HANDLED from intel_dp_hpd_pulse() to properly
ignore the long HPD pulse on eDP to avoid the never ending
VDD off->HPD->VDD on->VDD off->HPD... cycle.

This fixes a regression intoduced by
 commit b2c5c181ed18490648a02f8c7d562a3b9e8b96de
 Author: Daniel Vetter <daniel.vetter@ffwll.ch>
 Date:   Fri Jan 23 06:00:31 2015 +0100

    drm/i915: Use symbolic irqreturn for ->hpd_pulse

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Merge tag 'imx-drm-fixes-2015-01-28' of git://git.pengutronix.de/git/pza/linux into drm-next

imx-drm fixes for IPUv3 DC and i.MX5 IPUv3 IC and TVE

- Corrected handling of wait_for_completion_timeout return value
  when disabling IPUv3 DC channels
- Fixed error return value propagation in TVE mode_set
- Fixed IPUv3 register offsets for IC module on i.MX51 and i.MX53

* tag 'imx-drm-fixes-2015-01-28' of git://git.pengutronix.de/git/pza/linux:
  gpu: ipu-v3: Fix IC control register offset
  drm: imx: imx-tve: Check and propagate the errors
  gpu: ipu-v3: wait_for_completion_timeout does not return negative status

Merge branch 'drm-sti-next-2015-02-04' of git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next

Those patches improve audio info frame management, add pixel formats
support and fix minor issues.

* 'drm-sti-next-2015-02-04' of git://git.linaro.org/people/benjamin.gaignard/kernel:
  drm: sti: HDMI add audio infoframe
  drm: sti: add support of XBGR8888 for gdp plane
  drm: sti: add support of ABGR8888 for gdp plane
  drm: sti: fix static checker warning in sti_awg_utils
  drm: sti: fix check for clk_pix_main

Merge tag 'topic/drm-misc-2015-02-06' of git://anongit.freedesktop.org/drm-intel into drm-next

Flushing out my drm-misc queue with a few oddball things all over.

* tag 'topic/drm-misc-2015-02-06' of git://anongit.freedesktop.org/drm-intel:
  drm: Use static attribute groups for managing connector sysfs entries
  drm: remove DRM_FORMAT_NV12MT
  drm/modes: Print the mode status in human readable form
  drm/irq: Don't disable vblank interrupts when already disabled

drm/i915: Correct the base value while updating LP_OUTPUT_HOLD in MIPI_PORT_CTRL

LP_OUTPUT_HOLD is only in MIPI_PORT_CTRL(PORT_A) even for PORT_C in case
of dual link. In the dual link implementation, the bit is correctly set
or unset for hardcoded PORT_A, but for bit update the register base value
is read by using MIPI_PORT_CTRL(port) in a loop. The second iteration will
read base value from PORT_C and program for PORT_A. Mostly in case of dual
link all other bit values should be same, but logically we should read from
PORT_A. So hardcode to read initial value from PORT_A as well.

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Insert a command barrier on BLT/BSD cache flushes

This looked like an odd regression from

commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jun 12 10:28:55 2014 +0100

    drm/i915: Restrict GPU boost to the RCS engine

but in reality it undercovered a much older coherency bug. The issue that
boosting the GPU frequency on the BCS ring was masking was that we could
wake the CPU up after completion of a BCS batch and inspect memory prior
to the write cache being fully evicted. In order to serialise the
breadcrumb interrupt (and so ensure that the CPU's view of memory is
coherent) we need to perform a post-sync operation in the MI_FLUSH_DW.

v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists).

Also fix the invalidate_domains mask in gen8_emit_flush() for ring !=
VCS.

Testcase: gpuX-rcs-gpu-read-after-write
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Drop vblank wait from intel_dp_link_down

Nothing in Bspec seems to indicate that we actually needs this, and it
looks like can't work since by this point the pipe is off and so
vblanks won't really happen any more.

Note that Bspec mentions that it takes a vblank for this bit to
change, but _only_ when enabling.

Dropping this code quenches an annoying backtrace introduced by the
more anal checking since

commit 51e31d49c89055299e34b8f44d13f70e19aaaad1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 15 12:36:02 2014 +0200

    drm/i915: Use generic vblank wait

Note: This fixes the fallout from the above commit, but does not address
the shortcomings of the IBX transcoder select workaround implementation
discussed during review [1].

[1] http://mid.gmane.org/87y4o7usxf.fsf@intel.com

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86095
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org # 3.19
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Squelch overzealous uncore reset WARN_ON

We added this WARN_ON to guard against using uninitialized
forcewake domains. But forgot blissfully that not all
gens have forcewake domains in the first place.

v2: Move WARN_ON to fw_domains_init (Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88911
Tested-by: Ding Heng <hengx.ding@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[Jani: add comment above WARN_ON as suggested by Chris]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Take runtime pm reference on hangcheck_info

We read the coherent current seqno and actual head from ring.
For hardware access we need to take runtime_pm reference.

Get hardware specific values with runtime reference held
and print them first to emphasize hw state vs bookkeepping.

v2: Reorder output according to hw access (Chris)
    remove superfluous locking (Daniel)

Testcase: igt/pm_rpm/debugfs-read
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88910
Tested-by: Ding Heng <hengx.ding@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Correct the IOSF Dev_FN field for IOSF transfers

As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target
device and not the source. So PCI_DEVFN(2,0) is not correct. Further the
port ID should be enough to identify devices unless they are MFD. The
SB_DevFn was intended to remove ambiguity in case of these MFD devices.

For non MFD devices the recommendation for the target device IP was to
ignore these fields, but not all of them followed the recommendation.
Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so
does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because
of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0).
It turned out that this did not follow the recommendation and expected 0
in this field.

In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for
all devices except target PCI devices.

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm: sti: HDMI add audio infoframe

Add a default audio infoframe for HDMI compliance

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>

drm/i915: Prevent use-after-free in invalidate_range_start callback

It's possible for invalidate_range_start mmu notifier callback to race
against userptr object release. If the gem object was released prior to
obtaining the spinlock in invalidate_range_start we're hitting null
pointer dereference.

Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close
Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[Jani: added code comment suggested by Chris]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm: sti: add support of XBGR8888 for gdp plane

Use GDP capabilities to support DRM_FORMAT_XBGR8888 (XB24)

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>

Merge tag 'drm-amdkfd-next-fixes-2015-02-03' of git://people.freedesktop.org/~gabbayo/linux into drm-next

- Fixing accounting of active queues
- Preserving a register internal state

* tag 'drm-amdkfd-next-fixes-2015-02-03' of git://people.freedesktop.org/~gabbayo/linux:
  drm/amdkfd: Preserve CP_MQD_IQ_RPTR internal state
  drm/amdkfd: Fix dqm->queue_count tracking

Merge branch 'drm-intel-next' of git://anongit.freedesktop.org/drm-intel into drm-next

drm-intel-next-2015-01-30:
- chv rps improvements from Ville
- atomic state handling prep work from Ander
- execlist request tracking refactoring from Nick Hoath
- forcewake code consolidation from Chris&Mika
- fastboot plane config refactoring and skl support from Damien
- some more skl pm patches all over (Damien)
- refactor dsi code to use drm dsi helpers and drm_panel infrastructure (Jani)
- first cut at experimental atomic plane updates (Matt Roper)
- piles of smaller things all over, as usual

* 'drm-intel-next' of git://anongit.freedesktop.org/drm-intel: (102 commits)
  drm/i915: Remove bogus locking check in the hangcheck code
  drm/i915: Update DRIVER_DATE to 20150130
  drm/i915: Use pipe_config's cpu_transcoder for reading encoder hw state
  drm/i915: Fix a use-after-free in intel_execlists_retire_requests
  drm/i915: Split shared dpll setup out of __intel_set_mode()
  drm/i915: Don't do posting reads on getting forcewake
  drm/i915: Do uncore early sanitize after domain init
  drm/i915: Handle CHV in vlv_set_rps_idle()
  drm/i915: Remove nested work in gpu error handling
  drm/i915/documentation: Add intel_uncore.c to drm.tmpl
  drm/i915/dsi: remove intel_dsi_cmd.c and the unused functions therein
  drm/i915/dsi: move dpi_send_cmd() to intel_dsi.c and make it static
  drm/i915/dsi: remove old read/write functions in favor of new stuff
  drm/i915/dsi: make the vbt panel driver use mipi_dsi_device for transfers
  drm/i915/dsi: add drm mipi dsi host support
  drm/i915/dsi: switch to drm_panel interface
  drm/i915/skl: Enabling PSR on Skylake
  Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"
  drm/i915: Be consistent on printing seqnos
  drm/i915: Display current hangcheck status in debugfs
  ...

drm: sti: add support of ABGR8888 for gdp plane

Use GDP capabilities to support DRM_FORMAT_ABGR8888 (AB24)

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

drm: sti: fix static checker warning in sti_awg_utils

The shift and the mask done on arg value is useless
since arg is null.

Signed-off-by: Vincent Abriou <vincent.abriou@st.com>

drm: sti: fix check for clk_pix_main

copy-paste wasn't followed by editing, do it.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

drm: Use static attribute groups for managing connector sysfs entries

Instead of manual calls of device_create_file() and
device_remove_file(), assign the static attribute groups to the device
with device_create_with_groups().  The conditionally built sysfs
entries are handled via is_visible callback.

This simplifies the code and also avoids the possible races.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: remove DRM_FORMAT_NV12MT

So this has been merged originally in

commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Thu Dec 15 15:40:55 2011 +0900

    drm: Add multi buffer plane pixel formats

which hasn't seen a lot of review really. The problem is that it's not
a real pixel format, but just a different way to lay out NV12 pixels
in macroblocks, i.e. a tiling format.

The new way of doing this is with the soon-to-be-merged fb modifiers.

This was brough up in some long irc discussion around the entire
topic, as an example of where things have gone wrong. Luckily we can
correct the mistake:
- The kms side support for NV12MT is all dead code because
  format_check in drm_crtc.c never accepted NV12MT.
- The gem side for the gsc support doesn't look better: The code
  forgets to set the pixel format and makes a big mess with the tiling
  mode bits, inadvertedly setting them all.

Conclusion: This never really worked (at least not in upstream) and
hence we can safely correct our mistake here.

Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rob Clark <robclark@freedesktop.org>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Remove bogus locking check in the hangcheck code

You can _never_ assert that a lock is not held, except in some very
restricted corner cases where it's guranteed that your code is running
single-threade (e.g. driver load before you've published any pointers
leading to that lock).

In addition the early return breaks a bunch of testcases since with
highly concurrent hangcheck stress tests the reset fails to work and
the test doesn't recover and time out.

This regression has been introduced in

commit b8d24a06568368076ebd5a858a011699a97bfa42
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Wed Jan 28 17:03:14 2015 +0200

    drm/i915: Remove nested work in gpu error handling

Aside: It is possible to check whether a given task doesn't hold a
lock, but only when lockdep is enabled, using the lockdep_assert_held
stuff.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88908
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/modes: Print the mode status in human readable form

Currently when a mode is rejected the reason is printed as a raw number.
Having to manually decode that to a enum drm_mode_status value is
tiresome. Have the code do the decoding instead and print the result
in a human readable format.

Just having an array of strings indexed with the mode status doesn't
work since the enum includes negative values. So we offset the status
by +3 which makes all the indexes non-negative. Also add a bit of
paranoia into the code to catch out of bounds accesses in case
someone adds more enum values but forgets to update the code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/modes: Print the mode status in human readable form

Currently when a mode is rejected the reason is printed as a raw number.
Having to manually decode that to a enum drm_mode_status value is
tiresome. Have the code do the decoding instead and print the result
in a human readable format.

Just having an array of strings indexed with the mode status doesn't
work since the enum includes negative values. So we offset the status
by +3 which makes all the indexes non-negative. Also add a bit of
paranoia into the code to catch out of bounds accesses in case
someone adds more enum values but forgets to update the code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on HAVE_DMA_ATTRS

DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the
building. The related error (with allmodconfig under xtensa):

    CC [M]  drivers/gpu/drm/drm_gem_cma_helper.o
  drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_create':
  drivers/gpu/drm/drm_gem_cma_helper.c:110:19: error: implicit declaration of function 'dma_alloc_writecombine' [-Werror=implicit-function-declaration]
    cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
                     ^
  drivers/gpu/drm/drm_gem_cma_helper.c:110:17: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
    cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
                   ^
  drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_free_object':
  drivers/gpu/drm/drm_gem_cma_helper.c:193:3: error: implicit declaration of function 'dma_free_writecombine' [-Werror=implicit-function-declaration]
     dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
     ^
  drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_mmap_obj':
  drivers/gpu/drm/drm_gem_cma_helper.c:330:8: error: implicit declaration of function 'dma_mmap_writecombine' [-Werror=implicit-function-declaration]
    ret = dma_mmap_writecombine(cma_obj->base.dev->dev, vma,
          ^

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next

Rebase of main pull for 3.20.  There was a mid-air collision between
the bridge changes and msm eDP support.  And atomic dpms support broke
msm somewhat, due to using prepare/commit hooks in a different way.
Compared to the initial pull req, this fixes up a memory leak caused
by the bridge changes, rebases the eDP support on the bridge changes,
and migrates to the atomic dpms hooks to fix the dpms breakage.

Highlights (from original pull req):

1) YUV support for mdp4 and mdp5
2) eDP support
3) hw cursor support for mdp5[*]
4) additional hdmi support for apq8084 (snapdragon 805)
5) few bug fixes

Note that I may have a later pull to enable hdmi hpd irqs.. but
(un)fortunately I seem to have a particularly troublesome monitor..  I
managed to figure out a workaround for spurious hpd disconnect irqs
that works with some of my boards but not others, so holding off on
that patch for now.  There are also patches for HDCP support, but
those are waiting on some scm patches outside of drm so I think
waiting until 3.21 at this point.

* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (22 commits)
  drm/msm: add moduleparam to disable fbdev
  drm/msm: fix build error with W=1
  drm/msm/mdp5: Fix negative SMP block allocation
  drm/msm/hdmi: disallow interlaced
  drm/msm/atomic: fix issue with gnome-shell wayland
  drm/msm/mdp5: Add hardware cursor support
  drm/msm/hdmi: rework hdmi configurations, using dt_match[]
  drm/msm/hdmi: Add HDMI platform config for apq8084
  drm/msm/hdmi: use dynamic allocation for hdmi resources
  drm/msm/mdp5: fix parameter type for mdp5_ctl_set_intf()
  drm/msm/dp: use link power helpers
  drm/msm: Add the eDP connector in msm drm driver (V2)
  drm/msm: Initial add eDP support in msm drm driver (v5)
  drm/msm/mdp4: add YUV format support
  drm/msm/mdp5: add NV12 support for MDP5
  drm/msm/mdp: add common YUV information for MDP4/MDP5
  drm/msm: update generated headers
  drm/msm: Do not BUG_ON(!spin_is_locked()) on UP
  drm/msm/hdmi: fix memory leak after bridge changes
  drm/msm: fix fallout of atomic dpms changes
  ...

drm/msm: add moduleparam to disable fbdev

Useful to avoid recompiling to disable fbdev.  Useful because otherwise
the first modeset happens under console_lock (ie. debugging sadness).

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: fix build error with W=1

Combining -Werror with all the extra warning flags that W=1 adds doesn't
go so well.  Especially because some of the warnings triggered are from
included headers.  So just drop -Werror.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: Fix negative SMP block allocation

In case we request a number of SMP blocks which is lower than
the already reserved blocks, we should not try to allocate a
negative number, but 0 blocks instead.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/hdmi: disallow interlaced

So after clarification from qcom, it seems mdp4 and mdp5 support
*de*interlacing but not generating an interlaced signal.  Which would
explain why interlaced modes never worked properly.

So disable in the one connector which was claiming to support
interlaced.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/atomic: fix issue with gnome-shell wayland

The gnome-shell wayland compositor triggers a setcrtc with an fb that is
still being rendered, triggering the call to _wait_fence_interruptable().
But a NULL timeout means "don't wait, return -EBUSY if not ready", which
in turn causes the setcrtc to fail.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: Add hardware cursor support

This patch implements the hardware accelarated cursor
support for MDP5 platforms.

Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/hdmi: rework hdmi configurations, using dt_match[]

In the same idea mdp5_cfg was added, this change allows us to quickly
add new instances, such as apq8084's HDMI in this case.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/hdmi: Add HDMI platform config for apq8084

This change add the regulator/clock configuration for MDP5 v1.3.
This config is close to the one already existing for 8x74, except
that one more regulator is needed (hpd-5v-en).

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/hdmi: use dynamic allocation for hdmi resources

Instead of reporting BUG_ON when resources arrays are not
dimensioned correctly, this patch does a dynamic allocation of
these arrays. This is needed for the following patches that add a
regulator for a new target.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: fix parameter type for mdp5_ctl_set_intf()

mdp5_ctl_set_intf()'s second argument should be "int", not "enum mdp5_intf".
The passed in value is "intf", not "intf_id".

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/dp: use link power helpers

Now that we have a helper for drm_dp_link_power_down(), use dp helpers
instead of rolling our own.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: Add the eDP connector in msm drm driver (V2)

Modified the hard-coded hdmi connector/encoder implementations in msm drm
driver to support both edp and hdmi.

V1: Initial change

V2: Address Thierry's change

Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: Initial add eDP support in msm drm driver (v5)

This change adds a new eDP connector in msm drm driver. With this
change, eDP panel can work with msm platform under drm framework.

v1: Initial change

v2: Address Rob's comments
    Use generated header file for register definitions
    Change to devm_* APIs

v3: Address Thierry's comments and rebase on top of atomic changes
    Remove edp_bridge_mode_fixup
    Remove backlight control code and rely on pwm-backlight
    Remove continuous splash screen support for now
    Change to gpiod_* APIs

v4: Fix kbuild test issue

Signed-off-by: Hai Li <hali@codeaurora.org>
[robclark: v5: rebase on drm_bridge changes in drm-next]
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp4: add YUV format support

The patch add support for YUV frame format
for MDP4 platform.

Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: add NV12 support for MDP5

This change adds the NV12 format support for public planes.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp: add common YUV information for MDP4/MDP5

Both MDP4 and MDP5 share some code as far as YUV support is
concerned. This change adds this information and will be followed
by the actual MDP4 and MDP5 YUV support patches.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: update generated headers

Resync from rnndb database, to pull in register defines for:
 * eDP
 * HDMI/HDCP
 * mdp4/mdp5 YUV support
 * mdp5 hw cursor support

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: Do not BUG_ON(!spin_is_locked()) on UP

On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.

Use
  assert_spin_locked(lock);
instead of
  BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.

Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
[robclark: drop stray ')']
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/hdmi: fix memory leak after bridge changes

3d3f8b1f8b ("drm/bridge: make bridge registration independent of drm
flow") resulted that the hdmi bridge object would be leaked at teardown.
Just switch over to devm_kzalloc() as the easy way to solve this.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: fix fallout of atomic dpms changes

As a result of atomic DPMS support, the various prepare/commit hooks get
called in a way that msm dislikes.  We were expecting prepare/commit to
bracket a modeset, which is no longer the case.  This was needed to hold
various extra clk's (such as interface clks) on while we are touching
registers, and in the case of mdp4 holding vblank enabled.

The most straightforward way to deal with this, since we already have
our own atomic_commit(), is to just handle prepare/commit internally to
the driver (with some additional vfuncs for mdp4 vs mdp5), and switch
everything over to instead use the new enable/disable hooks.  It doesn't
really change too much, despite the code motion.  What used to be in the
encoder/crtc dpms() fxns is split out into enable/disable.

We should be able to drop our own enable-state tracking, as the atomic
helpers should do this for us.  But keeping that for the short term for
extra debugging as atomic stablizes.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: Remove CRTC .mode_set and .mode_set_base helpers

Only the legacy helpers use these entry points.  Don't populate them
with transitional helpers, since that just makes things more confusing.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[robclark: reword commit msg]
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/dp: add drm_dp_link_power_down() helper

We had _power_up(), but drivers also need to be able to power down.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

drm: atmel-hlcdc: Add dependency on ARM

The atmel-hlcdc driver selects DRM_GEM_CMA_HELPER which makes use of
symbols only available when HAVE_DMA_ATTRS is selected.
Add a dependency on the ARM architecture which select this option.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm: msm: add missing dependencies on OF and COMMON_CLK

The msm gpu drivers depend on both the DT mechanism and the
common clk handling code, if they are not enabled, we get
a number of build errors:

In file included from drivers/gpu/drm/msm/hdmi/hdmi.h:27:0,
                 from drivers/gpu/drm/msm/hdmi/hdmi_bridge.c:18:
drivers/gpu/drm/msm/msm_drv.h:45:24: fatal error: mach/board.h: No such file or directory
 #include <mach/board.h>
                        ^

drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c:503:2: error: implicit declaration of function 'devm_clk_register' [-Werror=implicit-function-declaration]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm/udl: properly set active_16 flag in udl_crtc_page_flip(). (v2)

When page flipping, we need to mark the new fb as active and unmark the active
flag for the old fb (if different).

Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm: shmobile: fix Kconfig dependencies

The shmobile drm driver selects BACKLIGHT_CLASS_DEVICE
as of 0a5a5499ad88 "drm: shmobile: Add dependency on
BACKLIGHT_CLASS_DEVICE", but that option in turn depends
on BACKLIGHT_LCD_SUPPORT, so we actually have to select
both, or alternatively use 'depends on BACKLIGHT_CLASS_DEVICE'.

Further, the driver uses FB_SH_MOBILE_MERAM if that is
enabled, but this breaks if MERAM is a module while
the DRM driver is built-in. To solve this, add a dependency
on "FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM", which forces
DRM_SHMOBILE to be a module if FB_SH_MOBILE_MERAM set to 'm'.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm: sti: add panel dependency

The newly added sti driver requires the drm_panel helpers,
and we get a link error if they are not enabled

ERROR: "drm_panel_attach" [drivers/gpu/drm/sti/stidvo.ko] undefined!
ERROR: "of_drm_find_panel" [drivers/gpu/drm/sti/stidvo.ko] undefined!

This adds a 'select' statement as we have for the other drivers.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm: rockchip: add reset controller dependency

When the reset controller subsystem is disabled, this driver
fails to build:

drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function 'vop_initial':
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1267:2: error: implicit declaration of function 'devm_reset_control_get' [-Werror=implicit-function-declaration]

The easiest solution is to add a dependency in Kconfig to avoid
that case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm: panel/simple: add backlight dependency

The simple panel code uses the backlight interface to
find a device, which fails when backlight is disabled:

drivers/built-in.o: In function `panel_simple_platform_probe':
:(.text+0xd3c48): undefined reference to `of_find_backlight_by_node'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm: panel/sharp: add backlight dependency

The sharp panel code uses the backlight interface to
find a device, which fails when backlight is disabled:

drivers/built-in.o: In function `sharp_panel_probe':
:(.text+0x5ceac): undefined reference to `of_find_backlight_by_node'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm/udl: optimize udl_compress_hline16 (v2)

The run-length encoding algorithm should compare 16-bit encoded pixel
values instead of comparing raw pixel values. It allows pixels
with similar but different colors to be encoded as repeat pixels, and
thus potentially save USB bandwidth.

Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Haixia Shi <hshi@chromium.org>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm/i915: Update DRIVER_DATE to 20150130

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use pipe_config's cpu_transcoder for reading encoder hw state

The get_config() functions for ddi and dp_mst, used to read the value
of cpu_transcoder from the crtc->config instead of the state passed as
an argument. On the hardware state readout path, that happens to work
since the proper value is written to it before encoder->get_config() is
called. However, in the check_crtc() path, the state will be read from
the cpu_transcoder in the software tracking, instead of the one just
read out from hw. Using the field in the supplied intel_crtc_state
should do the right thing in both cases.

v2: Fix intel_ddi_get_config() too. (Ander)

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix a use-after-free in intel_execlists_retire_requests

Remove request from list before unreferencing it, in case it's actually
the only reference. (Found by Tvrtko Ursulin)

This issue has been most likely introduced in

commit 6d3d8274bc45de4babb62d64562d92af984dd238
Author: Nick Hoath <nicholas.hoath@intel.com>
Date:   Thu Jan 15 13:10:39 2015 +0000

    drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request

Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Split shared dpll setup out of __intel_set_mode()

This simplifies __intel_set_mode() a little.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't do posting reads on getting forcewake

The checking for ack and also any subsequent mmio access
will serialize with setting the forcewake bit. Drop the
posting read as superfluous.

Note that in the put side we still want to keep the posting read
as it will ensure that the hw sees our forcewake release in a
timely manner and doesn't keep the hw powered up.

Comment from Chris:

On Wed, Jan 28, 2015 at 05:54:14PM +0200, Mika Kuoppala wrote:
> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> > IIRC the posting read from same cache line actually fixed real bugs. So
> > I'm a bit worried about dropping them. But I suppose it's possible only
> > the _put side was important for those bugs.
>
> I found these:
>
> commit 6af2d180f82151cf3d58952e35a4f96e45bc453a
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Thu Jul 26 16:24:50 2012 +0200
>
>     drm/i915: fix forcewake related hangs on snb
>
> commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date:   Sat Sep 1 22:59:50 2012 -0700
>
>     drm/i915: Never read FORCEWAKE
>
> https://bugs.freedesktop.org/show_bug.cgi?id=51738
> https://bugs.freedesktop.org/show_bug.cgi?id=52424
>
> The snb here seems to survive gem_dummy_reloc_loop and
> gem_ring_sync_loop in here with the get side posting removed.

Note that we kept the once associated with #52424, but judging by my
comments in #51738 the posting read is just a band aid anyway as a full
mb() itself was not adequate.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: paste relevant review discussion in.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Do uncore early sanitize after domain init

intel_uncore_early_sanitize() will reset the forcewake registers. When
forcewake domains were introduced, the domain init was done after the
sanitization of the forcewake registers. And as the resetting of
registers use the domain accessors, we tried to reset the forcewake
registers with unitialized forcewake domains and failed.

Fix this by sanitizing after all the domains have been initialized. Do
per domain clearing of forcewake register on domain init so that
IVB can do early access to ECOBUS do determine the final configuration.

This regression was introduced in

commit 05a2fb157e44a53c79133805d30eaada43911941
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Mon Jan 19 16:20:43 2015 +0200

    drm/i915: Consolidate forcewake code

v2: Carve out ellc detect, fw_domain_reset for ivb/ecobus (Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88805
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Olof Johansson <olof@lixom.net>
Tested-by: Darren Hart <dvhart@linux.intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Handle CHV in vlv_set_rps_idle()

Move the CHV check into vlv_set_rps_idle() to simplify the caller a bit.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove nested work in gpu error handling

Now when we declare gpu errors only through our own dedicated
hangcheck workqueue there is no need to have a separate workqueue
for handling the resetting and waking up the clients as the deadlock
concerns are no more.

The only exception is i915_debugfs::i915_set_wedged, which triggers
error handling through process context. However as this is only used through
test harness it is responsibility for test harness not to introduce hangs
through both debug interface and through hangcheck mechanism at the same time.

Remove gpu_error.work and let the hangcheck work do the tasks it used to.

v2: Add a big warning sign into i915_debugfs::i915_set_wedged (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/documentation: Add intel_uncore.c to drm.tmpl

Include intel_uncore.c in template for it to include d
documentation for intel_uncore_forcewake_get and *_put.

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: remove intel_dsi_cmd.c and the unused functions therein

The removed functions can be resurrected in intel_dsi.c as need arises.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: move dpi_send_cmd() to intel_dsi.c and make it static

No functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: remove old read/write functions in favor of new stuff

All of these are replaced by the drm core mipi dsi functions.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: make the vbt panel driver use mipi_dsi_device for transfers

Use the drm core interfaces in preparation of removing our homebrew.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: add drm mipi dsi host support

Add basic support for using the drm mipi dsi framework for DSI. We don't
use device tree which is pretty much required by mipi_dsi_host_register
and friends, and we don't have the kind of device model the functions
expect either. So we cheat and use it as a library to abstract what we
need: a nice, clean interface for DSI transfers. This means we will have
to be careful with what functions we call, as the driver model devices
in mipi_dsi_host and mipi_dsi_device will *not* be initialized.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: switch to drm_panel interface

Replace intel_dsi_device and intel_dsi_dev_ops with drm_panel and
drm_panel_funcs. They are adequate for what we have now, and if we end
up needing more than this we should improve drm_panel. This will keep us
better aligned with the drm core infrastructure.

The panel driver initialization changes a bit. It still remains hideous,
but fixing that is beyond the scope here.

v2: extend mode config mutex to cover drm_panel_get_modes (Shobhit)
    vbt_panel->intel_dsi = intel_dsi in vbt panel init (Shobhit)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/irq: Don't disable vblank interrupts when already disabled

The .enable_vblank() operation is only called when vblank interrupts are
disabled, but no similar check exists when disabling vblank interrupts.
This leads to .disable_vblank() being called with vblank interrupts
already disabled and the device possibly runtime suspended. As the
operation is called with a spinlock held drivers can't runtime resume
the device there and thus must avoid touching device registers in that
case, requiring vblank refcounting.

As the DRM core tracks whether vblank interrupts are enabled just skip
the .disable_vblank() call when the interrupts are already disabled.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

agp: change agp_free_page_array to use kvfree

Change agp_free_page_array to use kvfree function,
remove the duplicated code.

Signed-off-by: Yalin Wang <yalin.wang@sonymobile.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'master' of git://git./linux/kernel/git/torvalds/linux into drm-next

This backmerges drm-fixes into drm-next mainly for the amdkfd
stuff, I'm not 100% confident, but it builds and the amdkfd
folks can fix anything up.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Conflicts:
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h

Merge tag 'drm/panel/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next

drm/panel: Changes for v3.20-rc1

This contains the long-awaited drm_bridge series that makes Chromebooks
work for people. I had thought this would've been perfect by now, but
then I go and build test it and the first thing it does is yell about a
recursive dependency. I fixed that up because I was feeling bad for not
getting around to look at this earlier.

Biseds that there is new support for two more panels, a couple of fixup
patches to the Sharp LQ101R1SX01 dual-channel DSI panel driver and a
potential NULL pointer dereference fix.

* tag 'drm/panel/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux: (23 commits)
  drm/bridge: dw-hdmi: Adapt to bridge API change
  drm/sti: fixup for bridge interface
  drm/bridge: dw-hdmi: Fix return error path
  drm: Check the right variable when setting formats
  Documentation: bridge: Add documentation for ps8622 DT properties
  Documentation: devicetree: Add vendor prefix for parade
  Documentation: drm: bridge: move to video/bridge
  drm/bridge: ptn3460: use gpiod interface
  drm/bridge: ptn3460: probe connector at the end of bridge attach
  drm/bridge: ptn3460: support drm_panel
  drm/exynos: dp: support drm_bridge
  drm/bridge: ptn3460: Convert to I2C driver model
  drm/bridge: make bridge registration independent of drm flow
  drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
  drm/bridge: ptn3460: Few trivial cleanups
  drm/panel: simple: Add AVIC TM070DDH03 panel support
  of: Add vendor prefix for Shanghai AVIC Optoelectronics Co., Ltd.
  drm/panel: sharp: lq101r1sx01: Remove unneeded include
  drm/panel: sharp: lq101r1sx01: Respect power timings
  drm/panel: sharp: lq101r1sx01: Add delay after display on
  ...

drm/i915/skl: Enabling PSR on Skylake

Mainly taking care of some register offsets, otherwise things are similar to
hsw. Also, programming ddi aux to use hardcoded values for psr data select.

v2: introduce  EDP_PSR_AUX_BASE macro (Chris)
v3: Moving to HW tracking for SKL+ platforms, so activating source psr during
psr_enabling and then avoiding psr entries and exits for each frontbuffer
updates.
v4: Using SKL DDI AUX regs instead of changing PSR_AUX regs definition (Rodrigo)

Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Drop the hunks to short-circuit sw tracking: We'd need to
push this down one level, and I don't fully trust the test coverage
yet to do so. So much prefer we pick a whitelist approach for the
cases we know work correctly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"

The core fix was applied in

commit a63b03e2d2477586440741677ecac45bcf28d7b1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 6 10:29:35 2015 +0000

    mutex: Always clear owner field upon mutex_unlock()

(note the absence of stable@ tag)

so we can now revert our band-aid commit 226e5ae9e5f910 for -next.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Be consistent on printing seqnos

We have had %x and %u intermixed. Bring everything in line and
use %x

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Display current hangcheck status in debugfs

For example,

/sys/kernel/debug/dri/0/i915_hangcheck_info:

Hangcheck active, fires in 15887800ms
render ring:
        seqno = -4059 [current -583]
        action = 2
        score = 0
        ACTHD = 1ee8 [current 21f980]
        max ACTHD = 0

v2: Include expiration ETA. Can anyone spot a problem?
v3: Convert for workqueued hangcheck (Mika)
v4: Print seqnos as unsigned ints (Ville)
v5: Print seqnos as hex (Chris)

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) (v2)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert hangcheck from a timer into a delayed work item

When run as a timer, i915_hangcheck_elapsed() must adhere to all the
rules of running in a softirq context. This is advantageous to us as we
want to minimise the risk that a driver bug will prevent us from
detecting a hung GPU. However, that is irrelevant if the driver bug
prevents us from resetting and recovering. Still it is prudent not to
rely on mutexes inside the checker, but given the coarseness of
dev->struct_mutex doing so is extremely hard.

Give in and run from a work queue, i.e. outside of softirq.

v2: Use own workqueue to avoid deadlocks (Daniel)
    Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <dnaiel.vetter@ffwll.chm>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Remove accidental kerneldoc comment starter, to appease the 0
day builder.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

agp/intel: Serialise after GTT updates

An interesting bug occurs on Pineview through which the root cause is
that the writes of the PTE values into the GTT is not serialised with
subsequent memory access through the GTT (when using WC updates of the
PTE values). This is despite there being a posting read after the GTT
update. However, by changing the address of the posting read, the memory
access is indeed serialised correctly.

Whilst we are manipulating the memory barriers, we can remove the
compiler :memory restraint on the intermediate PTE writes knowing that
we explicitly perform a posting read afterwards.

v2: Replace posting reads with explicit write memory barriers - in
particular this is advantages in case of single page objects. Update
comments to mention this issue is only with WC writes.

Testcase: igt/gem_exec_big #pnv
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191
Tested-by: huax.lu@intel.com (v1)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/bridge: dw-hdmi: Adapt to bridge API change

Commit fbc4572e9c48e45b ("drm/bridge: make bridge registration independent of
drm flow") introduced some drm/bridge API modifications. Make the necessary
changes so that we can avoid the build breakage:

drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_bridge_destroy':
drivers/gpu/drm/bridge/dw_hdmi.c:1378:2: error: implicit declaration of function 'drm_bridge_cleanup' [-Werror=implicit-function-declaration]
drivers/gpu/drm/bridge/dw_hdmi.c: At top level:
drivers/gpu/drm/bridge/dw_hdmi.c:1471:2: error: unknown field 'destroy' specified in initializer
drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_register':
drivers/gpu/drm/bridge/dw_hdmi.c:1535:2: error: implicit declaration of function 'drm_bridge_init' [-Werror=implicit-function-declaration]

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

drm/sti: fixup for bridge interface

So sti doesn't build because the bridge interfaces changes didn't
catch up to its new DVO driver.

Now I might just carry this patch, but I might just push the
bridge pull into a side-pull until someone resolves it.

So this might not be the right solution to the problem, so
please figure it out and let me know ASAP.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

drm/bridge: dw-hdmi: Fix return error path

If devm_request_threaded_irq() fails we should jump to 'err_iahb' label that
will disable the clocks that were previously enabled.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>

drm: Check the right variable when setting formats

When setting the video bus supported formats for a display device using
drm_display_info_set_bus_formats(), check for the proper variable after
duplicating memory.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Documentation: bridge: Add documentation for ps8622 DT properties

Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.

Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Documentation: devicetree: Add vendor prefix for parade

ps8622 eDP-LVDS converter bridge chip is from parade technologies

Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>