The drm_gem_object_release() function already performs this cleanup,
so there is no reason to do it explicitly.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

All the user of these functions are inside exynos-drm driver and
you don't need to export the symbols for that case.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The beginning of statement in function is next line of a brace.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

By if statment, some function callings are written twice. It needs
several line feed by indentation in if statment. Make to one function
calling from outside if statment.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The exynos_drm_gem_init() is used only in exynos_drm_gem.c file. Make it
static and don't export it.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

They will be freed right or was freed already, so NULL assignment is
unnecessary.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

When obj->import_attach is existed, code calling drm_prime_gem_destroy()
was removed from commit 67e93c80 ("drm/exynos: stop copying sg
table"), and it's a fault.

The drm_prime_gem_destroy() is cleanup function which GEM drivers need
to call when they use drm_gem_prime_import() to import dma-bufs, so
exynos-drm driver using drm_gem_prime_import() needs calling
drm_prime_gem_destroy().
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

There is no guarantee that DMA addresses are the same as physical
addresses, but dma_to_pfn() knows how to convert a dma_addr_t to a PFN
which can then be converted to a struct page.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

a few drm/i915 fixes, including a fix to the recent regression
reported by Sedat Dilek

* tag 'drm-intel-fixes-2015-09-24' of git://anongit.freedesktop.org/drm-intel:
  drm/i915/bios: handle MIPI Sequence Block v3+ gracefully
  drm/i915: Add primary plane to mask if it's visible
  drm/i915: workaround bad DSL readout v3
  drm/i915: fix kernel-doc warnings in intel_audio.c

Pull request of 2015-09-24

Vmwgfx fixes for 4.3:
 - A couple of uninitialized variable fixes by Christian Engelmayer
 - A TTM fix for a bug that causes problems with the new vmwgfx device init
 - A vmwgfx refcounting fix
 - A vmwgfx iomem caching fix
 - A DRM change to allow also control clients to read the drm driver version.

* tag 'vmwgfx-fixes-4.3-150924' of git://people.freedesktop.org/~thomash/linux:
  drm: Allow also control clients to check the drm version
  drm/vmwgfx: Fix uninitialized return in vmw_kms_helper_dirty()
  drm/vmwgfx: Fix uninitialized return in vmw_cotable_unbind()
  drm/vmwgfx: Only build on X86
  drm/ttm: Fix memory space allocation v2
  drm/vmwgfx: Map the fifo as cached
  drm/vmwgfx: Fix up user_dmabuf refcounting

This should be harmless.
Vmware will, due to old infrastructure reasons, be using a privileged
control client to supply GUI layout information rather than obtaining
it from the device. That control client will be needing access to DRM
version information.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>

Function vmw_kms_helper_dirty() uses the uninitialized variable ret as
return value. Make the result deterministic and directly return as the
variable is unused anyway. Detected by Coverity CID 1324255.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Function vmw_cotable_unbind() uses the uninitialized variable ret as
return value. Make the result deterministic and directly return as
the variable is unused anyway. Detected by Coverity CID 1324256.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

radeon and amdgpu fixes for 4.3.  It's a bit bigger than usual since
it's 3 weeks worth of fixes since I was on vacation, then at XDC.
- lots of stability fixes
- suspend and resume fixes
- GPU scheduler fixes
- Misc other fixes

* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux: (31 commits)
  drm/radeon: add quirk for MSI R7 370
  drm/amdgpu: Sprinkle drm_modeset_lock_all to appease locking checks
  drm/radeon: Sprinkle drm_modeset_lock_all to appease locking checks
  drm/amdgpu: sync ce and me with SWITCH_BUFFER(2)
  drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()
  drm/amdgpu: info leak in amdgpu_gem_metadata_ioctl()
  drm/amdgpu: integer overflow in amdgpu_info_ioctl()
  drm/amdgpu: unwind properly in amdgpu_cs_parser_init()
  drm/amdgpu: Fix max_vblank_count value for current display engines
  drm/amdgpu: use kmemdup rather than duplicating its implementation
  drm/amdgpu: fix UVD suspend and resume for VI APU
  drm/amdgpu: fix the UVD suspend sequence order
  drm/amdgpu: make UVD handle checking more strict
  drm/amdgpu: Disable UVD PG
  drm/amdgpu: more scheduler cleanups v2
  drm/amdgpu: cleanup fence queue init v2
  drm/amdgpu: rename fence->scheduler to sched v2
  drm/amdgpu: cleanup entity init
  drm/amdgpu: refine the scheduler job type conversion
  drm/amdgpu: refine the job naming for amdgpu_job and amdgpu_sched_job
  ...

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

mgag200_driver_load's error path just calls the drm driver's
driver_unload op. It isn't safe to call this because it doesn't handle
things well if driver_load fails somewhere mid way.

Replace the call to mgag200_driver_unload with a more finegrained
error handling path.

Link: http://lkml.kernel.org/r/55F6E68D.8070800@codeaurora.orgReported-by: NIngo Molnar <mingo@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Set up error handling in mgag200_fbdev_init and mgag200fb_create such that
they release the things they allocate, rather than relying on someone
calling mga_fbdev_destroy.

Based on a patch by Sudip Mukherjee <sudipm.mukherjee@gmail.com>

Link: http://lkml.kernel.org/r/55F6E68D.8070800@codeaurora.orgReported-by: NIngo Molnar <mingo@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the server isn't new enough to give us state, report the first
monitor as always connected, otherwise believe the server side.

Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Just adds the quirk for MSI R7 370 Armor 2X
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91294Signed-off-by: NMaxim Sheviakov <mrader3940@yandex.ru>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In

commit 7a3f3d66
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 9 23:44:28 2015 +0200

    drm: Check locking in drm_for_each_connector

I added locking checks to drm_for_each_connector but failed that
through drm_helper_connector_dpms -> drm_helper_choose_encoder_dpms
it's used in a few more places in the amdgpu resume/suspend code.

Fix them up.

Note that we could use the connector iterator macros in there too, but
that's for the future.

Port of radeon commit:
drm/radeon: Sprinkle drm_modeset_lock_all to appease locking checks
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In

commit 7a3f3d66
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 9 23:44:28 2015 +0200

    drm: Check locking in drm_for_each_connector

I added locking checks to drm_for_each_connector but failed that
through drm_helper_connector_dpms -> drm_helper_choose_encoder_dpms
it's used in a few more places in the radeon resume/suspend code.

Fix them up.

Note that we could use the connector iterator macros in there too, but
that's for the future.
Reported-and-tested-by: NBorislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

we used to adopt wait_reg_mem to let CE wait before DE finish page
updating, but from Tonga+, CE doesn't support wait_reg_mem package so
this logic no longer works.

so here is another approach to do same thing:
Insert two of SWITCH_BUFFER at both front and end of vm_flush can
guarantee that CE not go further to process IB_const before vm_flush
done.

Insert two of SWITCH_BUFFER also works on CI, so remove legency method
to sync CE and ME

v2:
Insert double SWITCH_BUFFER at front of vm flush as well.
Signed-off-by: Nmonk.liu <monk.liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

args->size is a u64.  arg->pitch and args->height are u32.  The
multiplication will overflow instead of using the high 32 bits as
intended.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There is no limit on args->data.data_size_bytes so we could read beyond
the end of the args->data.data[] array.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reported-by: NIlja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The "alloc_size" calculation can overflow leading to memory corruption.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reported-by: NIlja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The amdgpu_cs_parser_init() function doesn't clean up after itself but
instead the caller uses a free everything function amdgpu_cs_parser_fini()
on failure.  This style of error handling is often buggy.  In this
example, we call "drm_free_large(parser->chunks[i].kdata);" when it is
an unintialized pointer or when "parser->chunks" is NULL.

I fixed this bug by adding unwind code so that it frees everything that
it allocates.

I also mode some other very minor changes:
1) Renamed "r" to "ret".
2) Moved the chunk_array allocation to the start of the function.
3) Removed some initializers which are no longer needed.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reported-by: NIlja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The value was much too low, which could cause the userspace visible
vblank counter to move backwards when the hardware counter wrapped
around.

Ported from radeon commit:
b0b9bb4dReviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The patch was generated using fixed coccinelle semantic patch
scripts/coccinelle/api/memdup.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2014320Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

User space passed the same handle before suspend and after resume,
so we have remove the session and handle destroy, and keep the
firmware untouched.
Signed-off-by: NLeo Liu <leo.liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

Fixes suspend issues with UVD.
Signed-off-by: NLeo Liu <leo.liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

Invalid messages can crash the hw otherwise

Ported from radeon commit a1b403daSigned-off-by: NLeo Liu <leo.liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

This causes problems with multiple suspend/resume cycles.
Signed-off-by: NLeo Liu <leo.liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

Embed the scheduler into the ring structure instead of allocating it.
Use the ring name directly instead of the id.

v2: rebased, whitespace cleanup
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Chunming Zhou<david1.zhou@amd.com>

Move the fence related stuff into amdgpu_fence.c

v2: rework commit message, cause this is actually not a bug
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou<david1.zhou@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>

Just to be consistent with the other members.

v2: rename the ring member as well.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> (v1)
Reviewed-by: Chunming Zhou<david1.zhou@amd.com>

Reorder the fields and properly return the kfifo_alloc error code.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Chunming Zhou<david1.zhou@amd.com>

Use container_of rather than casting.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDavid Zhou <david1.zhou@amd.com>
Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com>

Use consistent naming across functions.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDavid Zhou <david1.zhou@amd.com>
Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com>

Reduces the locking and fencing overhead.

v2: add comment why we need the duplicates list in the GEM op.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>

This allows for multiple BOs to have the same reservation object.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>