The final parameter to ttm_bo_reserve() is a pointer, therefore callers
should use NULL instead of 0.

Fixes a bunch of sparse warnings of this type:

	warning: Using plain integer as NULL pointer
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.

At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.

Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.

Spotted by coverity.
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NIan Romanick <ian.d.romanick@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.

Spotted by coverity.
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NIan Romanick <ian.d.romanick@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Many drm connectors do not need mode validation.
The patch makes this callback optional and removes dumb implementations.

v2: Rebase:
- imx move to a shared (but still dummy) ->mode_valid implementation.
- probe helpers have been extracted to drm_probe_helper.c

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

cirrus kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.

Fix this by adding suspend and resume functions.
Also make the mode_set function unblank the screen.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC.  Replace all references to the CRTC fb with the
primary plane's fb.

This patch was generated by the Coccinelle semantic patching tool using
the following rules:

        @@ struct drm_crtc C; @@
        -   (C).fb
        +   C.primary->fb

        @@ struct drm_crtc *C; @@
        -   (C)->fb
        +   C->primary->fb

v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
    moved to a subsequent patch.

v2: Fixup several lingering crtc->fb instances that were missed in the
    first patch iteration.  [Rob Clark]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

With dev->anon_inode we have a global address_space ready for operation
right from the beginning. Therefore, there is no need to do a delayed
setup with TTM. Instead, set dev_mapping during initialization in
ttm_bo_device_init() and remove any "if (dev_mapping)" conditions.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

DRM drivers share a common address_space across all character-devices of a
single DRM device. This allows simple buffer eviction and mapping-control.
However, DRM core currently waits for the first ->open() on any char-dev
to mark the underlying inode as backing inode of the device. This delayed
initialization causes ugly conditions all over the place:
  if (dev->dev_mapping)
    do_sth();

To avoid delayed initialization and to stop reusing the inode of the
char-dev, we allocate an anonymous inode for each DRM device and reset
filp->f_mapping to it on ->open().
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

I totally sign inverted my way out of this one.

Cc: stable@vger.kernel.org
Reported-by: N"Sabrina Dubroca" <sd@queasysnail.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

these 3 were checking in_interrupt but we have situations where
calling vunmap under this could cause a BUG to be hit in
smp_call_function_many. Use the drm_can_sleep macro instead,
which should stop this path from been taken in this case.

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

When the mode is set with 16bpp on QEMU, the output gets totally broken.
The culprit is the bogus register values set for 16bpp, which was likely
copied from from a wrong place.

Addresses https://bugzilla.novell.com/show_bug.cgi?id=799216Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: David Airlie <airlied@linux.ie>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Mark functions cirrus_ttm_global_release(), cirrus_ttm_bo_is_cirrus_bo()
and cirrus_ttm_tt_create() as static in drm/cirrus/cirrus_ttm.c because
they are not used outside this file. Remove unused function
cirrus_bo_unpin() from drm/cirrus/cirrus_ttm.c.

This eliminates the following warnings in drm/cirrus/cirrus_ttm.c:
drivers/gpu/drm/cirrus/cirrus_ttm.c:84:1: warning: no previous prototype for ‘cirrus_ttm_global_release’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_ttm.c:105:6: warning: no previous prototype for ‘cirrus_ttm_bo_is_cirrus_bo’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_ttm.c:211:16: warning: no previous prototype for ‘cirrus_ttm_tt_create’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_ttm.c:378:5: warning: no previous prototype for ‘cirrus_bo_unpin’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Mark functions cirrus_set_start_address(), cirrus_encoder_destroy(),
cirrus_vga_get_modes() and cirrus_connector_best_encoder() as static in
drm/cirrus/cirrus_mode.c because they are not used outside this file.

This eliminates the following warnings in drm/cirrus/cirrus_mode.c:
drivers/gpu/drm/cirrus/cirrus_mode.c:105:6: warning: no previous
prototype for ‘cirrus_set_start_address’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_mode.c:456:6: warning: no previous
prototype for ‘cirrus_encoder_destroy’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_mode.c:495:5: warning: no previous
prototype for ‘cirrus_vga_get_modes’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_mode.c:512:21: warning: no previous
prototype for ‘cirrus_connector_best_encoder’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Mark function cirrus_bo_unref() as static in drm/cirrus/cirrus_main.c
because it is not used outside this file.

This eliminates the following warning in drm/cirrus/cirrus_main.c:
drivers/gpu/drm/cirrus/cirrus_main.c:258:6: warning: no previous
prototype for ‘cirrus_bo_unref’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Xorg fbdev driver requires smem_start/smem_len, otherwise
it tries to map 0 bytes as video memory.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856760Signed-off-by: NMartin Koegler <martin.koegler@chello.at>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I've killed them a long time ago in drm/i915, let's get rid of this
remnant of shared drm core days for good.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Explicitly set 1024x768 as default mode, so the display doesn't come up
with the largest supported mode.

While being at it drop first three drm_add_modes_noedid calls.  As
drm_add_modes_noedid fills the mode list with modes from the database
*up to* the specified size it is pretty pointless to call it multiple
times with different sizes.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For drivers which might want to disable fbdev legacy support.

Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by adding per-driver options. At least as long
as most drivers don't support disabling the fbdev support.

v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
driver can already take advantage of this, which allows us to build
msm without any fbdev depencies in the kernel!

v3: Move the MODULE_* stuff from the fbdev helper file to
drm_crtc_helper.c.

Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.

New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.

Cc: Dave Airlie <airlied@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().

TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0.

All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).

v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
    access was denied.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
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>

So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.

First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...

Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.

No merged drm driver has ever done that.

After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:

commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie <airlied@linux.ie>
Date:   Sun Aug 29 12:04:35 2004 +0000

    Drop GAMMA DRM from a great height ...

Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.

So stop this particular cargo-cult and rip it all out.

v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.

v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.

v4: Actually git add ... tsk.

Cc: Dave Airlie <airlied@linux.ie>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

gem_bo->driver_private is never read by cirrus nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is a cirrus version of Egbert Eich's patch for mgag200.

Without bo.bdev->dev_mapping set, the ttm_bo_unmap_virtual_locked
called from ttm_bo_handle_move_mem returns with no effect. If any
application accessed the memory before it was moved, it will
access wrong memory next time. This causes crashes when changing
resolution down.
Signed-off-by: NMichal Srb <msrb@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.

So give it to them and roll it out in all drivers.

This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Acked-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Ben Skeggs <skeggsb@gmail.com>
Reviwed-by: NRob Clark <robdclark@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use the new vma-manager infrastructure. This doesn't change any
implementation details as the vma-offset-manager is nearly copied 1-to-1
from TTM.

The vm_lock is moved into the offset manager so we can drop it from TTM.
During lookup, we use the vma locking helpers to take a reference to the
found object.
In all other scenarios, locking stays the same as before. We always
guarantee that drm_vma_offset_remove() is called only during destruction.
Hence, helpers like drm_vma_node_offset_addr() are always safe as long as
the node has a valid offset.

This also drops the addr_space_offset member as it is a copy of vm_start
in vma_node objects. Use the accessor functions instead.

v4:
 - remove vm_lock
 - use drm_vma_offset_lock_lookup() to protect lookup (instead of vm_lock)

Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Martin Peres <martin.peres@labri.fr>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't. This fixes the following lockdep splat:

[   13.044313] ------------[ cut here ]------------
[   13.044367] WARNING: at /c/kernel-tests/src/tip/kernel/mutex.c:858 mutex_trylock+0x87/0x220()
[   13.044378] DEBUG_LOCKS_WARN_ON(in_interrupt())
[   13.044378] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-rc4-00296-ga2963dd #20
[   13.044379] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[   13.044390]  0000000000000009 ffff88000de039f8 ffffffff81fc86d5 ffff88000de03a38
[   13.044395]  ffffffff810d511b ffff880000000018 ffff88000f33c690 0000000000000001
[   13.044398]  00000000000003f0 ffff88000f4677c8 0000000000000000 ffff88000de03a98
[   13.044400] Call Trace:
[   13.044412]  <IRQ>  [<ffffffff81fc86d5>] dump_stack+0x19/0x1b
[   13.044441]  [<ffffffff810d511b>] warn_slowpath_common+0x6b/0x90
[   13.044445]  [<ffffffff810d51a6>] warn_slowpath_fmt+0x46/0x50
[   13.044448]  [<ffffffff81fd34d7>] mutex_trylock+0x87/0x220
[   13.044482]  [<ffffffff8186484d>] cirrus_dirty_update+0x1cd/0x330
[   13.044486]  [<ffffffff818649e8>] cirrus_imageblit+0x38/0x50
[   13.044506]  [<ffffffff8165782e>] soft_cursor+0x22e/0x240
[   13.044510]  [<ffffffff81656c31>] bit_cursor+0x581/0x5b0
[   13.044525]  [<ffffffff815de9f4>] ? vsnprintf+0x124/0x670
[   13.044529]  [<ffffffff81651333>] ? get_color.isra.16+0x43/0x130
[   13.044532]  [<ffffffff81653fca>] fbcon_cursor+0x18a/0x1d0
[   13.044535]  [<ffffffff816566b0>] ? update_attr.isra.2+0xa0/0xa0
[   13.044556]  [<ffffffff81754b82>] hide_cursor+0x32/0xa0
[   13.044565]  [<ffffffff81755bd3>] vt_console_print+0x103/0x3b0
[   13.044569]  [<ffffffff810d58ac>] ? print_time+0x9c/0xb0
[   13.044576]  [<ffffffff810d5960>] ? print_prefix+0xa0/0xc0
[   13.044580]  [<ffffffff810d63f6>] call_console_drivers.constprop.6+0x146/0x1f0
[   13.044593]  [<ffffffff815f9b38>] ? do_raw_spin_unlock+0xc8/0x100
[   13.044597]  [<ffffffff810d6f27>] console_unlock+0x2f7/0x460
[   13.044600]  [<ffffffff810d787a>] vprintk_emit+0x59a/0x5e0
[   13.044615]  [<ffffffff81fb676c>] printk+0x4d/0x4f
[   13.044650]  [<ffffffff82ba5511>] print_local_APIC+0x28/0x41c
[   13.044672]  [<ffffffff8114db55>] generic_smp_call_function_single_interrupt+0x145/0x2b0
[   13.044688]  [<ffffffff8106f9e7>] smp_call_function_single_interrupt+0x27/0x40
[   13.044697]  [<ffffffff81fd8f72>] call_function_single_interrupt+0x72/0x80
[   13.044707]  <EOI>  [<ffffffff81078166>] ? native_safe_halt+0x6/0x10
[   13.044717]  [<ffffffff811425cd>] ? trace_hardirqs_on+0xd/0x10
[   13.044738]  [<ffffffff8104f669>] default_idle+0x59/0x120
[   13.044742]  [<ffffffff810501e8>] arch_cpu_idle+0x18/0x40
[   13.044754]  [<ffffffff811320c5>] cpu_startup_entry+0x235/0x410
[   13.044763]  [<ffffffff81f9e781>] rest_init+0xd1/0xe0
[   13.044766]  [<ffffffff81f9e6b5>] ? rest_init+0x5/0xe0
[   13.044778]  [<ffffffff82b93ec2>] start_kernel+0x425/0x493
[   13.044781]  [<ffffffff82b93810>] ? repair_env_string+0x5e/0x5e
[   13.044786]  [<ffffffff82b93595>] x86_64_start_reservations+0x2a/0x2c
[   13.044789]  [<ffffffff82b93688>] x86_64_start_kernel+0xf1/0x100
[   13.044799] ---[ end trace 113ad28772af4058 ]---
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}.  The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Port over the mgag200 fix to cirrus as it suffers the same issue.

    On F19 testing, it was noticed we get a lot of errors in dmesg
    about being unable to reserve the buffer when plymouth starts,
    this is due to the buffer being in the process of migrating,
    so it makes sense we can't reserve it.

    In order to deal with it, this adds delayed updates for the dirty
    updates, when the bo is unreservable, in the normal console case
    this shouldn't ever happen, its just when plymouth or X is
    pushing the console bo to system memory.

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

The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should be done in the drivers for two reasons:
- it gets in the way of fastboot efforts
- it links the fb helpers with the crtc helpers instead of going
  through the real interface vfuncs, forcing i915 to fake all the
  ->disable callbacks used by the crtc helper to avoid ugly Oopsen

v2: Resolve conflicts since drivers still call
drm_fb_helper_single_add_all_connectors.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have two classes of framebuffer
- Created by the driver (atm only for fbdev), and the driver holds
  onto the last reference count until destruction.
- Created by userspace and associated with a given fd. These
  framebuffers will be reaped when their assoiciated fb is closed.

Now these two cases are set up differently, the framebuffers are on
different lists and hence destruction needs to clean up different
things. Also, for userspace framebuffers we remove them from any
current usage, whereas for internal framebuffers it is assumed that
the driver has done this already.

Long story short, we need two different ways to cleanup such drivers.
Three functions are involved in total:
- drm_framebuffer_remove: Convenience function which removes the fb
  from all active usage and then drops the passed-in reference.
- drm_framebuffer_unregister_private: Will remove driver-private
  framebuffers from relevant lists and drop the corresponding
  references. Should be called for driver-private framebuffers before
  dropping the last reference (or like for a lot of the drivers where
  the fbdev is embedded someplace else, before doing the cleanup
  manually).
- drm_framebuffer_cleanup: Final cleanup for both classes of fbs,
  should be called by the driver's ->destroy callback once the last
  reference is gone.

This patch just rolls out the new interfaces and updates all drivers
(by adding calls to drm_framebuffer_unregister_private at all the
right places)- no functional changes yet. Follow-on patches will move
drm core code around and update the lifetime management for
framebuffers, so that we are no longer required to keep framebuffers
alive by locking mode_config.mutex.

I've also updated the kerneldoc already.

vmwgfx seems to again be a bit special, at least I haven't figured out
how the fbdev support in that driver works. It smells like it's
external though.

v2: The i915 driver creates another private framebuffer in the
load-detect code. Adjust its cleanup code, too.
Reviewed-by: NRob Clark <rob@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some drivers don't have real ->create_handle callbacks.

- cirrus/ast/mga200: Returns either 0 or -EINVAL.

- udl: Didn't even bother with a callback, leading to a nice
  userspace-triggerable OOPS.

- vmwgfx: This driver bothered with an implementation to return 0 as
  the handle (which is the canonical no-obj gem handle).

All have in common that ->create_handle doesn't really make too much
sense for them - that ioctl is used only for seamless fb takeover in
the radeon/nouveau/i915 ddx drivers. So allow drivers to not implement
this and return a consistent -ENODEV.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by the time drivers
call drm_framebuffer_init.

This patch here is the drivers part of that reorg. Nothing really fancy
going on safe for three special cases.

- exynos needs to be careful to properly unref all handles.
- nouveau gets a resource leak fixed for free: one of the error
  cases didn't cleanup the framebuffer, which is now moot since
  the framebuffer is only registered once it is fully set up.
- vmwgfx requires a slight reordering of operations, I'm hoping I didn't
  break anything (but it's refcount management only, so should be safe).

v2: Split out exynos, since it's a bit more hairy than expected.

v3: Drop bogus cirrus hunk noticed by Richard Wilbur.

v4: Split out vmwgfx since there's a small change in return values.

Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Dave Airlie <airlied@redhat.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, and __devexit
from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>