Since video memory needs to be accessed decrypted, be sure that the
memory encryption mask is not set for the video ranges.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Toshimitsu Kani <toshi.kani@hpe.com>
Cc: kasan-dev@googlegroups.com
Cc: kvm@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/a19436f30424402e01f63a09b32ab103272acced.1500319216.git.thomas.lendacky@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

The fault wrappers drm_vm_fault(), drm_vm_shm_fault(),
drm_vm_dma_fault() and drm_vm_sg_fault() used to provide extra logic
beyond what was in the "drm_do_*" versions of these functions, but as of
commit ca0b07d9 ("drm: convert drm from nopage to fault") they are
just unnecessary wrappers that do nothing.

Remove them, and rename the the drm_do_* fault handlers to remove the
"do_" since they no longer have corresponding wrappers.

Link: http://lkml.kernel.org/r/1486155698-25717-1-git-send-email-ross.zwisler@linux.intel.comSigned-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

->fault(), ->page_mkwrite(), and ->pfn_mkwrite() calls do not need to
take a vma and vmf parameter when the vma already resides in vmf.

Remove the vma parameter to simplify things.

[arnd@arndb.de: fix ARM build]
  Link: http://lkml.kernel.org/r/20170125223558.1451224-1-arnd@arndb.de
Link: http://lkml.kernel.org/r/148521301778.19116.10840599906674778980.stgit@djiang5-desk3.ch.intel.comSigned-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Every single user of vmf->virtual_address typed that entry to unsigned
long before doing anything with it so the type of virtual_address does
not really provide us any additional safety.  Just use masked
vmf->address which already has the appropriate type.

Link: http://lkml.kernel.org/r/1479460644-25076-3-git-send-email-jack@suse.czSigned-off-by: NJan Kara <jack@suse.cz>
Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

That constant isn't meant to be used outside of arch mm code
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1467018023.20278.65.camel@kernel.crashing.org

GEM stopped using those a while ago, and no one should ever
need to use them again to debug legacy horror show drivers.

Nuke it all. Aside: It would kinda be nice if we'd have some
generic debugfs dumps for at least kms ...
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465930269-7883-2-git-send-email-daniel.vetter@ffwll.ch

It's only used for legacy mmaping support now.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-8-git-send-email-daniel.vetter@ffwll.ch

We already express the drm/agp depencies correctly in Kconfig, so we
can rip this remnant from the shared drm core days.

Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
if ttm would provide dummy functions. I'm not going to volunteer for
that though.

v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville

v3: Polish from Ville's review.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v2)
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

../drivers/gpu/drm/drm_vm.c:405:6: warning: symbol 'drm_vm_open_locked' was not declared. Should it be static?
../drivers/gpu/drm/drm_vm.c:431:6: warning: symbol 'drm_vm_close_locked' was not declared. Should it be static?
../drivers/gpu/drm/drm_vm.c:681:5: warning: symbol 'drm_vma_info' was not declared. Should it be static?

../drivers/gpu/drm/drm_pci.c:146:5: warning: symbol 'drm_pci_set_unique' was not declared. Should it be static?
../drivers/gpu/drm/drm_pci.c:216:5: warning: symbol 'drm_irq_by_busid' was not declared. Should it be static?

../drivers/gpu/drm/drm_info.c:47:5: warning: symbol 'drm_name_info' was not declared. Should it be static?
../drivers/gpu/drm/drm_info.c:72:5: warning: symbol 'drm_vm_info' was not declared. Should it be static?
../drivers/gpu/drm/drm_info.c:116:5: warning: symbol 'drm_bufs_info' was not declared. Should it be static?
../drivers/gpu/drm/drm_info.c:159:5: warning: symbol 'drm_clients_info' was not declared. Should it be static?
../drivers/gpu/drm/drm_info.c:209:5: warning: symbol 'drm_gem_name_info' was not declared. Should it be static?

../drivers/gpu/drm/drm_ioc32.c:1019:20: warning: symbol 'drm_compat_ioctls' was not declared. Should it be static?

../drivers/gpu/drm/drm_bridge.c:52:12: warning: function 'drm_bridge_attach' with external linkage has definition
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Leftover from my previous header cleanup.

This depends upon the patch to rework exynos mmap support, otherwise
it'll break exynos.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now that we've removed the copypasted users in gem/ttm we can
relegate the legacy buffer mapping support to where it belongs.
Also give it the proper drm_legacy_ prefix.

While at it statify drm_mmap_locked, somehow I've missed that in my
previous header rework.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

What the code does is equivalent to the x86 code, so let's use
it as well
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Also sprinkle the customary legacy_ prefix.

Unfortunately we can't move the other functions since i915 is still
using them. Shame on me for that one :(

v2: Fix patch subject as spotted by David Herrmann.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DRM_DEBUG_CODE is currently always set, so distributions enable it. The
only reason to keep support in code is if developers wanted to disable
debug support. Sounds unlikely.

All the DRM_DEBUG() printks are still guarded by a drm_debug read. So if
its cacheline is read once, they're discarded pretty fast.. There should
hardly be any performance penalty, it's even guarded by unlikely().
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

pte_wrprotect() is only used by drm_vm.c, so move the include there. Also
include it unconditionally, all architectures provide this header!

Furthermore, replace asm/current.h with sched.h, which includes
asm/current.h unconditionally. This way we get the same effect and avoid
direct asm/ includes. Furthermore, drop the weird __alpha__ protection.
It's safe to include sched.h everywhere (and the wait.h comment doesn't
apply, anyway).
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Move drm_agp_head to drm_agpsupport.h and drm_agp_mem into drm_legacy.h.
Unfortunately, drivers still heavily access drm_agp_head so we cannot
move it to drm_legacy.h. However, at least it's no longer visible in
drmP.h now (it's directly included from it, though).
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make all the drm_vma_entry handling local to drm_vm.c and hide it from
global headers. This requires to extract the inlined legacy drm_vma_entry
cleanup into a small helper and also move a weirdly placed drm_vma_info
helper into drm_vm.c.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is just used for a debugfs file, and we can easily reconstruct
this number by just walking the list twice. Which isn't really bad for
a debugfs file anyway.

So let's rip this out.

There's the other issue that the dev->vmalist itself is a bit useless,
since that can be reconstructed with all the memory mapping
information from proc. But remove that is a different topic entirely.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Most place actually want to just check for dev->agp (most do, but a
few don't so this fixes a few potential NULL derefs). The only
exception is the agp init code which should check for the AGP driver
feature flag.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Gone with the new gem vma offset manager from David.

We can also ditch the uapi header definition from the enum since
userspace never used this. It ended up in there purely for historical
reasons (for reusing the old drm mmap code essentially), not because
userspace ever needed it.

Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Most architectures define virt_to_page() as a macro that casts its
argument such that an argument of type unsigned long will be accepted
without complaint.  However, the proper type is void *, and passing
unsigned long results in a warning on MIPS.

Compile-tested only.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

By definition, the page offset will not affect the result.

Compile-tested only.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.

David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected drivers. David helped a lot in that. Quoting our mail
discussion:

On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>>> -#if __OS_HAS_MTRR
>>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>>>> -{
>>>> -       return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>>>> -}
>>>> -#else
>>>> -#define drm_core_has_MTRR(dev) (0)
>>>> -#endif
>>>> -
>>>
>>> That was the last user of DRIVER_USE_MTRR (apart from drivers setting
>>> it in .driver_features). Any reason to keep it around?
>>
>> Yeah, I guess we could rip things out. Which will also force me to
>> properly audit drivers for the eventual behaviour change this could
>> entail (in case there's an x86 driver which did not ask for an mtrr,
>> but iirc there isn't).
>
> david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
> test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
> fi ; done
> drivers/gpu/drm/exynos
> drivers/gpu/drm/gma500
> drivers/gpu/drm/i2c
> drivers/gpu/drm/nouveau
> drivers/gpu/drm/omapdrm
> drivers/gpu/drm/qxl
> drivers/gpu/drm/rcar-du
> drivers/gpu/drm/shmobile
> drivers/gpu/drm/tilcdc
> drivers/gpu/drm/ttm
> drivers/gpu/drm/udl
> drivers/gpu/drm/vmwgfx
> david@david-mb ~/dev/kernel/linux $
>
> So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
> But I cannot tell whether they break if we call arch_phys_wc_add/del,
> anyway. At least nouveau seemed to work here, but it doesn't use AGP
> or drm_bufs, I guess.

Cool, thanks a lot for stitching together the list of drivers to look
at. So for real KMS drivers it's the drives responsibility to add an
mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
already. Somehow the savage driver also ends up doing that, I have no
idea why.

Note that gma500 as a pure KMS driver doesn't need MTRR setup since
the platforms that it supports all support PAT. So no MTRRs needed to
get wc iomappings.

The mtrr support in the drm core is all for legacy mappings of garts,
framebuffers and registers. All legacy drivers set the USE_MTRR flag,
so we're good there.

All in all I think we can really just ditch this

/endquote

v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann

v3: Rebase on top of David Herrmann's agp setup/cleanup changes.

Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAndy Lutomirski <luto@amacapital.net>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

io_remap_pfn_range already sets this internally.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I'm not sure I understand the intent of the previous behavior.  mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable.  But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.

The new behavior just requests WC explicitly for all AGP maps.

If there is any code out there that expects cacheable access to the
AGP aperture (because the drm driver doesn't request an MTRR or
because it's using /dev/agpgart directly), then it will now end up
with a UC or WC mapping, depending on the architecture and PAT
availability.  But cacheable access to the aperture seems like it's
asking for trouble, because, AIUI, the aperture is an alias of RAM.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.

Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine.

The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
hardcoding the bit twiddling.

The DRM_AGP case is unchanged for now.

[airlied: fix ppc build]
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The EXYNOS DRM driver uses drm_vm_open_locked in its mmap() function,
and it can be built as a loadable module, which currently fails.
This exports the symbol from the DRM core to avoid

ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
currently it lost original meaning but still has some effects:

 | effect                 | alternative flags
-+------------------------+---------------------------------------------
1| account as reserved_vm | VM_IO
2| skip in core dump      | VM_IO, VM_DONTDUMP
3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP

This patch removes reserved_vm counter from mm_struct.  Seems like nobody
cares about it, it does not exported into userspace directly, it only
reduces total_vm showed in proc.

Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.

remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.

[akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Eric Paris <eparis@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: Matt Helsley <matthltc@us.ibm.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Venkatesh Pallipadi <venki@google.com>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Since arch/arm/include/asm/pgtable.h contains:

#define io_remap_pfn_range(vma,from,pfn,size,prot) \
                remap_pfn_range(vma, from, pfn, size, prot)

there is no point treating ARM as a special case in distinguishing
between remap_pfn_range() and io_remap_pfn_range().
Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Signed-off-by: NHongliang Tao <taohl@lemote.com>
Signed-off-by: NHua Yan <yanh@lemote.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Previously these functions would assume that vma->vm_file was the
drm_file.  Although if in some cases if the drm driver needs to use
something else for the backing file (such as the tmpfs filp) then this
assumption is no longer true.  But vma->vm_private_data is still the
GEM object.

With this change, now the drm_device comes from the GEM object rather
than the drm_file so the driver is more free to play with vma->vm_file.

The scenario where this comes up is for mmap'ing of cached dmabuf's
for non-coherent systems, where the driver needs to use fault handling
and PTE shootdown to simulate coherency.  We can't use the vma->vm_file
of the dmabuf, which is using anon_inode's address_space.  The most
straightforward thing to do is to use the GEM object's obj->filp for
vma->vm_file in all cases, for which we need this patch.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Two parts to this, one is simple unplug from sysfs for the device node.

The second adds an unplugged state, if we have device opens, we
just set the unplugged state and return, if we have no device
opens we drop the drm device.

If after a lastclose we discover we are unplugged we then
drop the drm device.

v2: use an atomic for unplugged and wrap it for users,
add checks on open + mmap + ioctl entry points.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Talking to Al Viro on irc, we can see no possible reason for doing
this, the upper mmap code does it. The code has been there since
first import into drm tree I can find.

Al tracked down this as a requirement pre 2.3.51 hasn't been needed since.
Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Remove an obsolete Alpha adjustment, and modify another,
to go with the current Alpha architecture support.
Signed-off-by: NJay Estabrook <jay.estabrook@gmail.com>
Tested-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Hook the GEM vm open/close ops into the generic drm vm open/close so
that the private vma entries are created and destroy appropriately.
Fixes the leak of the drm_vma_entries during the lifetime of the filp.
Reported-by: NMatt Mackall <mpm@selenic.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Every driver used the default implementation. Fold that one into
the only callsite and drop the callback.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

All drivers happily copy&pasted the default implementation without
checking whether this callback is used at all. It's not. Sigh.

Kill it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>