According to the latest revision of the datasheet, the LVDS I/O pins
must be enabled before starting the PLL. Fix it.
Signed-off-by: NKoji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The VSL and HSL bits in the DSMR register set the corresponding
horizontal and vertical sync signal polarity to active high. The code
got it the wrong way around, fix it.
Signed-off-by: NKoji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

There is a bug in the setting of the DES (Display Enable Signal)
register. This current setting occurs 1 dot left shift. The DES
register should be set minus one value about the specifying value
with H/W specification. This patch corrects it.
Signed-off-by: NKoji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Dot clock routing is setup through different registers depending on the
DU generation. The code has been designed for Gen2 and hasn't been
updated since. This works thanks to good reset default value, but isn't
very safe. Fix it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Document the R8A7796-specific DT bindings and support them in the
driver. The HDMI output is currently not supported.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Add support for the R8A7792 DU; it has 2 DPAD (RGB) outputs.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

It isn't safe to call drm_dev_unregister() without first initializing
mode setting with drm_mode_config_init(). This leads to a crash if
either IO memory can't be remapped or vblank initialization fails.

Fix this by reordering the initialization sequence. Move vblank
initialization after the drm_mode_config_init() call, and move IO
remapping before drm_dev_alloc() to avoid the need to perform clean up
in case of failure.

While at it remove the explicit drm_vblank_cleanup() call from
rcar_du_remove() as the drm_dev_unregister() function already cleans up
vblank.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

When an encoder fails to initialize the driver prints an error message
to the kernel log. The message contains the name of the encoder's DT
node, which is NULL for internal encoders. Use the of_node_full_name()
macro to avoid dereferencing a NULL pointer, print the output number to
add more context to the error, and make sure we still own a reference to
the encoder's DT node by delaying the of_node_put() call.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Memory allocation failures print messages to the kernel log, there's no
need to print an extra one. Remove the duplicate message.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The driver has lost platform data support a long time ago. R-Car DU
devices can only be instantiated through DT now, making it impossible to
have a NULL DT node pointer. Remove the error check.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Capitalize acronyms and use determiners and punctuation.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The node passed as a pointer to the rcar_du_lvds_connector_init()
function is never modified, make it const.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

0day continues to complain about trying to save a stacktrace for the
users of the drm_mm range allocator. This time, it is that m68k has no
save_stack_trace(), which is apparently guarded by STACKTRACE_SUPPORT.
Make it depend so!
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161109143906.11057-1-chris@chris-wilson.co.uk

DRM_DEBUG_MM is only valid if the DRM.ko is builtin as currently
depot_save_stack is not exported.

Fixes: 5c7fcf2d ("drm/i915: Enable drm_mm debug when enabling DRM_I915_DEBUG")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161108131917.6253-1-chris@chris-wilson.co.uk

I misread the kbuild result thinking that we had missed the include
(which we had for completeness anyway), what kbuild was actually warning
me about was that depot_save_stack was not exported.

Temporarily fix this by only selecting STACKDEPOT iff drm.ko is builtin
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Fixes: 5705670d ("drm: Track drm_mm allocators and show leaks on shutdown")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161108131917.6253-2-chris@chris-wilson.co.uk

Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-8-git-send-email-robdclark@gmail.com

We subclass drm_plane_state, so add mdp5_plane_atomic_print_state() to
dump out our own driver specific plane state.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-7-git-send-email-robdclark@gmail.com

Useful to dump current state from debugfs, if turning on the drm.debug
bit is too much overhead.

The drm_state_dump() can also be used by drivers, for example to
implement a module param that dumps state on error irqs.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-6-git-send-email-robdclark@gmail.com

The contents of drm_{plane,crtc,connector}_state is dumped before
commit.  If a driver extends any of the state structs, it can implement
the corresponding funcs->atomic_print_state() to add it's own driver
specific state.
Signed-off-by: NRob Clark <robdclark@gmail.com>
[seanpaul resolved conflict in drm_plane.h]
Signed-off-by: NSean Paul <seanpaul@chromium.org>

Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
[seanpaul resolved conflict in drm_plane.h]
Signed-off-by: NSean Paul <seanpaul@chromium.org>

Sometimes it is nice not to duplicate equivalent printk() and
seq_printf() code.

v2: simplify things w/ va_format, and use dev_printk, docs
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-3-git-send-email-robdclark@gmail.com

I'll want to print things in a similar way in a later patch.  This will
make it easier.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-2-git-send-email-robdclark@gmail.com

reservation_object_wait_timeout_rcu() should enable signaling even with a
zero timeout, but ttm_bo_wait() can also be called from atomic context and
then it is not a good idea to do this.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
  [sumits: fix checkpatch warnings]
Link: http://patchwork.freedesktop.org/patch/msgid/1478553376-18575-3-git-send-email-alexander.deucher@amd.com

v2: agd: rebase and squash in all the previous optimizations and
changes so everything compiles.
v3: squash in Slava's 32bit build fix
v4: rebase on drm-next (fence -> dma_fence),
    squash in Monk's ioctl update patch
Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: NMonk Liu <monk.liu@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
 [sumits: fix checkpatch warnings]
Link: http://patchwork.freedesktop.org/patch/msgid/1478290570-30982-2-git-send-email-alexander.deucher@amd.com

0day found that stackdepot.h doesn't get automatically included on all
architectures, so remember to add our #include.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Fixes: 5705670d ("drm: Track drm_mm allocators and show leaks on shutdown")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161108115601.22873-1-chris@chris-wilson.co.uk

It's possible for CVAL to get set whilst we are in config mode. If this
happens, afer we leave config mode the HW will latch whatever
configuration is in the registers at the next vsync. Most likely this
will be a partial configuration, as we'll be racing against the ongoing
atomic_commit.

To avoid this, clear CVAL before leaving config mode.
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>

drm_atomic_set_fence_for_plane() is smart and won't overwrite
plane_state->fence if the user already set an explicit fence there.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478513013-3221-3-git-send-email-gustavo@padovan.org

drm_atomic_set_fence_for_plane() is smart and won't overwrite
plane_state->fence if the user already set an explicit fence there.

Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478513013-3221-2-git-send-email-gustavo@padovan.org

This new function should be used by drivers when setting a implicit
fence for the plane. It abstracts the fact that the user might have
chosen explicit fencing instead.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478513013-3221-1-git-send-email-gustavo@padovan.org

It is kind of a pointless restriction.  If userspace does silly things
like using crtcA's cursor plane on crtcB, and then setcursor on crtcA,
it will end up with the overlay disabled on crtcB.  But userspace is
allowed to shoot itself like this.

v2: don't WARN_ON() if caller did not set ->possible_crtcs.  This keeps
    the existing behavior by default, if caller does not set the
    ->possible_crtcs.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478357521-26542-1-git-send-email-robdclark@gmail.com

All the VICs apart from 58 and 59 have the word "Hz" included in the
comment. Include it for 59 and 59 as well.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-1-git-send-email-ville.syrjala@linux.intel.com

psb_gem_create_ioctl and psb_gem_mmap_ioctl are not used currently,
their declarations are useless.
Signed-off-by: NJiang Biao <jiang.biao2@zte.com.cn>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477990879-13139-1-git-send-email-jiang.biao2@zte.com.cn

psb_gtt_remove is only used in this file, and make it static to
eliminate missing-prototypes compiling warning.
Signed-off-by: NJiang Biao <jiang.biao2@zte.com.cn>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477972185-24826-1-git-send-email-jiang.biao2@zte.com.cn

Add obvious description to drm_framebuffer_unregister_private()
to explain it is deprecated.
Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477915196-100299-1-git-send-email-zourongrong@gmail.com

A frequent issue that arises on shutdown is the drm_mm range manager
complaining of a leak. To aide debugging those, drm can now track the
allocation callsite and print those for the leaks.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161029184214.17329-2-chris@chris-wilson.co.uk

We can use the kernel's stack tracer and depot to record the allocation
site of every drm_mm user. Then on shutdown, as well as warning that
allocated nodes still reside with the drm_mm range manager, we can
display who allocated them to aide tracking down the leak.

v2: Move Kconfig around so it lies underneath the DRM options submenu.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161031090806.20073-1-chris@chris-wilson.co.uk

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

On LLC, or even snooped, machines rendering via the GPU ends up in the CPU
cache. This cacheline dirt also needs to be flushed to main memory when
moving to an incoherent domain, such as the display's scanout engine.
Mostly, this happens because either the object is marked as dirty from
its first use or is avoided by setting the object into the display
domain from the start.

v2: Treat WT as not requiring a clflush prior to use on the display
engine as well.

Fixes: 0f71979a ("drm/i915: Performed deferred clflush inside set-cache-level")
References: https://bugs.freedesktop.org/show_bug.cgi?id=95414Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.0+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107165204.7008-1-chris@chris-wilson.co.uk

Since the atomic modeset conversion, this should not be an issue
anymore.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>

During resume we will reset the SW/HW tracking for each ring head/tail
pointers and so are not prepared to replay any pending requests (as
opposed to GPU reset time). Add an assert for this both to the suspend
and the resume code.

v2:
- Check for ELSP port idle already during suspend and check !gt.awake
  during resume. (Chris)
v3:
- Move the !gt.awake check to i915_gem_resume().
v4:
- s/intel_lr_engines_idle/intel_execlists_idle/ (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-4-git-send-email-imre.deak@intel.com