drm: don't call ->firstopen for KMS drivers

It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.

v2: Don't forget to update DocBook.

v3: Go with Laurent's slightly more elaborate proposal for the DocBook
update. Add a few words on top of his diff to elaborate a bit on what
KMS drivers should and shouldn't do in lastclose. There was already a
paragraph present talking about restoring properties, I've simply
extended that one.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/vmwgfx: remove ->firstopen callback

So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
  radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)

In short besides the semantically important vga switcheroo stuff they
all try very hard to keep fbcon working in case X dies.

But none of them try to not do this at driver unload time safe for
vmwgfx, and digging through logs I couldn't find any reason for why
vmwgfx is special.

Since ->firstopen has lots of potential for abuse with kms drivers
(like delaying driver setup to pamper over races in the load sequence)
it's imo very much worth it to remove this logic so that we can
stop using the ->firstopen callback for kms drivers.

Also module unloading is rather a debug feature and developers should
know how to restore the display to a sane configuration.

Cc: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/imx: kill firstopen callback

This thing seems to do some kind of delayed setup. Really, real kms
drivers shouldn't do that at all. Either stuff needs to be dynamically
hotplugged or the driver setup sequence needs to be fixed.

This patch here just moves the setup at the very end of the driver
load callback, with the locking adjusted accordingly.

v2: Also move the corresponding put from ->lastclose to ->unload.

Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: fix minor number range calculation

Currently, both ranges overlap. Fix the limits so both ranges are mutually
exclusive. Also use the occasion to convert whitespaces to tabs.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
(fixed up tabs and adjust commit-msg accordingly)
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: fix locking in gem debugfs/procfs file

The idr is protected with our spinlock, if we don't hold that nothing
prevents the gem objects from disappearing from under us.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: remove the dma_ioctl special-case

We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.

To make really sure no mis-guided user in a kms driver pops up again
explicitly check for that in the new ioctl implementation.

v2: Drop the unused variable I've accidentally left in the code,
spotted by David Herrmann.

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

drm/docs: rip out removed driver flags documentation

I've forgotten this and shuffling all the little pieces into the
respective patches is rather cumbersome ...

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: rip out drm_core_has_MTRR checks

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: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: WARN about unbalanced handle refcounts

Trying to drop a reference we don't have is a pretty serious bug.
Trying to paper over it is an even worse offense.

So scream into dmesg with a big WARN in case that ever happens.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: remove bogus NULL check from drm_gem_object_handle_unreference_unlocked

Calling this function with a NULL object is simply a bug, so papering
over a NULL object not a good idea.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: move drm_gem_object_handle_unreference_unlocked into drm_gem.c

We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.

Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static (and remove the unused EXPORT_SYMBOL). To
avoid a forward declaration move it (and drm_gem_object_free_bug) up a
bit.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: add a bit of documentation about gem_obj->import_attach

Lifetime rules seem to be solid around ->import_attach. So this patch
just properly documents them.

Note that pointing directly at the attachment might have issues for
devices that have multiple struct device *dev parts constituting the
logical gpu and so might need multiple attachment points. Similarly
for drm devices which don't need a dma attachment at all (like udl).

But fixing that up is material for different patches.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: remove cargo-cult locking from map_sg helper

I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).

Only the grabbing of the underlying page array is anything we need to
be concerned about, and either those pages are pinned independently,
or we're screwed no matter what.

And indeed, nouveau/radeon pin the backing storage in their
attach/detach functions.

Since I've created this patch cma prime support for dma_buf was added.
drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates&maps
the sg table with dma_get_sgtable. It doesn't touch any gem object
state otherwise. So the cma helpers also look safe.

The only thing we might claim it does is prevent concurrent mapping of
dma_buf attachments. But a) that's not allowed and b) the current code
is racy already since it checks whether the sg mapping exists _before_
grabbing the lock.

So the dev->struct_mutex locking here does absolutely nothing useful,
but only distracts. Remove it.

This should also help Maarten's work to eventually pin the backing
storage more dynamically by preventing locking inversions around
dev->struct_mutex.

v2: Add analysis for recently added cma helper prime code.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/exynos: explicit store base gem object in dma_buf->priv

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: use common drm_gem_dmabuf_release in i915/exynos drivers

Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.

To use the release helper we need to export it, too.

Cc: Inki Dae <inki.dae@samsung.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/host1x: stop casting VMA offsets to 32bit

VMA offsets are 64bit so do not cast them to "unsigned int". Also remove
the (now useless) offset-retrieval helper. The VMA manager provides simple
enough helpers.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: "Terje Bergström" <tbergstrom@nvidia.com>
Cc: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: use ida to allocate connector ids

This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/omap: kill omap_gem_helpers.c

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

drm/udl: use gem get/put page helpers

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

drm/gma500: use gem get/put page helpers

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

drm/gem: add shmem get/put page helpers

Basically just extracting some code duplicated in gma500, omapdrm, udl,
and upcoming msm driver.

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

drm/gem: add drm_gem_create_mmap_offset_size()

Variant of drm_gem_create_mmap_offset() which doesn't make the
assumption that virtual size and physical size (obj->size) are the same.
This is needed in omapdrm to deal with tiled buffers.  And lets us get
rid of a duplicated and slightly modified version of
drm_gem_create_mmap_offset() in omapdrm.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/omap: use flip-work helper

And simplify how we hold a ref+pin to what is being scanned out by using
fb refcnt'ing.  The previous logic pre-dated fb refcnt, and as a result
was less straightforward than it could have been.  By holding a ref to
the fb, we don't have to care about how many plane's there are and
holding a ref to each color plane's bo.

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

drm/tilcdc: use flip-work helper

Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add flip-work helper

A small helper to queue up work to do, from workqueue context, after a
flip.  Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.

v1: original
v2: wire up docbook + couple docbook fixes

Signed-off-by: Rob Clark <robdclark@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Remove drm_mode_validate_clocks

This function is unused.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: no-op out GET_STATS ioctl

Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.

So I don't see any use for this stat gathering complexity at all.

To be able to gradually drop things start with ripping out the
interfaces to it, here the ioctl.

To prevent dristat from eating its own stack garbage we can't use the
drm_noop ioctl though, since we need to clear the return data with a
memset.

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: hollow-out GET_CLIENT ioctl

We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.

I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tests/dristat.c and drm/tests/getclients.c. The later
is a testcase for the ioctl itself since up to

commit b018fcdaa5e8b4eabb8cffda687d00004a3c4785
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Nov 22 18:46:54 2007 +1000

    drm: Make DRM_IOCTL_GET_CLIENT return EINVAL when it can't find client #idx

there was actually no way at all for userspace to enumerate all
clients since the kernel just wouldn't tell it when to stop. Which
completely broke it's only user, dristat -c.

So obviously that ioctl wasn't much use for debugging. Hence I don't
see any point in keeping support for a tool which was pretty obviously
never really used, and while we have good replacements in the form of
equivalent debugfs files.

Still, to keep dristat -c from looping forever again stop it early by
returning an unconditional -EINVAL. Also add a comment in the code
about why.

v2: Slightly less hollowed-out implementation. libva uses GET_CLIENTS
to figure out whether the fd it has is already authenticated or not.
So we need to keep that part of things working. Simplest way is to
just return one entry to keep va_drm_is_authenticated in
libva/va/drm/va_drm_auth.c working.

This is exercised by igt/drm_get_client_auth which contains a
copypasta of the libva auth check code.

Cc: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/memory: don't export agp helpers

They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.

I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that upper-case P sometimes ;-) But that's all stuff for future patch
bombs.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: remove a bunch of unused #defines from drmP.h

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: rip out a few unused DRIVER flags

The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: rip out DRIVER_FB_DMA and related code

No driver ever sets that flag, so good riddance!

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: remove FASYNC support

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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/vmwgfx: remove redundant clearing of driver->dma_quiescent

It's kzalloced ...

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: mark context support as a legacy subsystem

So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).

Also add the drm_legacy prefix for functions which are called from
common code. To further reduce the impact on common code also extract
all the ctx release handling into a function (instead of only
releasing individual handles) and make ctxbitmap_cleanup return void -
it can never fail.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: disallow legacy dma ioctls for modesetting drivers

Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature
flag set, so strictly speaking the modesetting check is redundant. But
adding it has the upside that it makes it very clear that the dma
support is legacy stuff.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: mark dma setup/teardown as legacy systems

And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: disallow legacy sg ioctls for modesetting drivers

Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup
was already only done for UMS drivers. Also a quick check of the ATI
ddx git history shows that only the UMS code ever used this facility.

So we can safely disallow these pair of ioctls for modesetting
drivers.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: hide legacy sg cleanup better from common code

I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: kill dev->driver->set_version

Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: kill firstopen callback for kms driver

Again, it does nothing.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/omap: kill firstopen callback

KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: kill unused functions

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: remove stale gem->driver_private access

This field is never read. No need to set it in radeon. Besides, DRM gem
core clears it during setup, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/qxl: remove unused object_pin/unpin() helpers

These two helpers are unused. Remove them. They rely on
gem_obj->driver_private, which is set to NULL during setup. As this field
isn't used by the driver, anymore, we can remove this assignment as well.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/cirrus: remove unused driver_private access

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: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/mgag200: remove unused driver_private access

gem_bo->driver_private is never read by mgag200 nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ast: remove unused driver_private access

gem_bo->driver_private is never read by ast nor DRM core. No need to set
it. Besides, drm core clears it during setup, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge remote-tracking branch 'pfdo/drm-rcar-for-v3.12' into drm-next

Merge the rcar stable branch that is being shared with the arm-soc tree.

Signed-off-by: Dave Airlie <airlied@redhat.com>
* pfdo/drm-rcar-for-v3.12: (220 commits)
  drm/rcar-du: Add FBDEV emulation support
  drm/rcar-du: Add internal LVDS encoder support
  drm/rcar-du: Configure RGB output routing to DPAD0
  drm/rcar-du: Rework output routing support
  drm/rcar-du: Add support for DEFR8 register
  drm/rcar-du: Add support for multiple groups
  drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU
  drm/rcar-du: Add support for the R8A7790 DU
  drm/rcar-du: Move output routing configuration to group
  drm/rcar-du: Remove register definitions for the second channel
  drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size
  drm/rcar-du: Introduce CRTCs groups
  drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_*
  drm/rcar-du: Create rcar_du_planes structure
  drm/rcar-du: Rename platform data fields to match what they describe
  drm/rcar-du: Merge LVDS and VGA encoder code
  drm/rcar-du: Split VGA encoder and connector
  drm/rcar-du: Split LVDS encoder and connector
  drm/rcar-du: Clarify comment regarding plane Y source coordinate
  drm/rcar-du: Support per-CRTC clock and IRQ
  ...

Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/qxl/qxl_release.c

drm/tilcdc fixup mode to workaround sync for tda998x

Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.

Signed-off-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i2c: tda998x: prepare for broken sync workaround

Some LCD controller cannot provide valid VESA style sync, i.e. coincident
HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to
reference pixel calculation to allow those controllers to add an offset
relative to the expected reference pixel.

Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i2c: tda998x: fix sync generation and calculation

This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i2c: tda998x: add video and audio input configuration

This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i2c: tda998x: prepare for video input configuration

The video-input-port (VIP) is highly configurable. This prepares
current driver to allow to configure VIP configuration, as some
boards connect lcd controller and TDA998x "pin-swapped" and depend
on VIP to swap the pins by register configuration.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i2c: tda998x: fix npix/nline programming

The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i2c: tda998x: ensure VIP output mux is properly set

When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation.  One such case encountered is the VIP output
mux register.  This defaults to 0x24 on powerup, but other drivers may
set this to 0x12.  This results in incorrect colours.

Fix this by ensuring that the register is always set to the power on
default setting.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i2c: tda998x: fix EDID reading on TDA19988 devices

TDA19988 devices need their RAM enabled in order to read EDID
information.  Add support for this.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: DRM should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `__drm_pci_free':
drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `drm_pci_alloc':
drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `drm_gem_unmap_dma_buf':
drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `drm_gem_map_dma_buf':
drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-rcar-stable

Create topic branch for rcar for shmobile tree to pull as well, arm-soc should
probably merge after drm merges if possible.

Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev: (23 commits)
  drm/rcar-du: Add FBDEV emulation support
  drm/rcar-du: Add internal LVDS encoder support
  drm/rcar-du: Configure RGB output routing to DPAD0
  drm/rcar-du: Rework output routing support
  drm/rcar-du: Add support for DEFR8 register
  drm/rcar-du: Add support for multiple groups
  drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU
  drm/rcar-du: Add support for the R8A7790 DU
  drm/rcar-du: Move output routing configuration to group
  drm/rcar-du: Remove register definitions for the second channel
  drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size
  drm/rcar-du: Introduce CRTCs groups
  drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_*
  drm/rcar-du: Create rcar_du_planes structure
  drm/rcar-du: Rename platform data fields to match what they describe
  drm/rcar-du: Merge LVDS and VGA encoder code
  drm/rcar-du: Split VGA encoder and connector
  drm/rcar-du: Split LVDS encoder and connector
  drm/rcar-du: Clarify comment regarding plane Y source coordinate
  drm/rcar-du: Support per-CRTC clock and IRQ
  ...

drm/rcar-du: Add FBDEV emulation support

Use the FB CMA helpers to implement FBDEV emulation support. The VGA
connector status must be reported as connector_status_connected instead
of connector_status_unknown to be usable by the emulation layer.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Add internal LVDS encoder support

The R8A7790 includes two internal LVDS encoders. Support them in the DU
driver.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Configure RGB output routing to DPAD0

The R8A7790 DU variant has a single RGB output called DPAD0 that can be
fed with the output of DU0, DU1 or DU2. Making the routing configurable.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Rework output routing support

Split the output routing specification between SoC-internal data,
specified in the rcar_du_device_info structure, and board data, passed
through platform data.

The DU has 5 possible outputs (DPAD0/1, LVDS0/1, TCON). SoC-internal
output routing data specify which output are valid, which CRTCs can be
connected to the valid outputs, and the type of in-SoC encoder for the
output.

Platform data then specifies external encoders and the output they are
connected to.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Add support for DEFR8 register

The R8A7790 DU has a new extended function control register. Support it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Add support for multiple groups

The R8A7790 DU has 3 CRTCs, split in two groups. Support them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU

The R8A7790 DU seems to require a 128 bytes pitch alignment, even though
the documentation only mentions a 16 pixels alignement as for the
R8A7779 DU. Make this configurable through a device flag.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Add support for the R8A7790 DU

The DU revision in the R8A7790 SoC uses one IRQ and clock per CRTC. Add
a corresponding entry in the module platform ID table.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Move output routing configuration to group

Output routing is configured in group registers, move the corresponding
code from rcar_du_crtc.c to rcar_du_group.c.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Remove register definitions for the second channel

Channels are accessed through a global channel memory offset, there's no
need to define register addresses for the second channel.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size

The rcar_du_device structure contains a field that stores the number of
CRTCs, use it instead of the CRTCs array size. This prepares the driver
to support a variable number of CRTCs.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Introduce CRTCs groups

The R8A7779 DU is split in per-CRTC resources (scan-out engine, blending
unit, timings generator, ...) and device-global resources (start/stop
control, planes, ...) shared between the two CRTCs.

The R8A7790 introduced a third CRTC with its own set of global resources
This would be modeled as two separate DU device instances if it wasn't
for a handful or resources that are shared between the three CRTCs
(mostly related to input and output routing). For this reason the
R8A7790 DU must be modeled as a single device with three CRTCs, two sets
of "semi-global" resources, and a few device-global resources.

Introduce a new rcar_du_group driver-specific object, without any real
counterpart in the DU documentation, that models those semi-global
resources.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_*

The functions initialize or register all planes, rename them
accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Create rcar_du_planes structure

Move the plane-related fields of struct rcar_du_device to their own
structure.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Rename platform data fields to match what they describe

The struct rcar_du_encoder_data encoder::field describes the encoder
type, and the rcar_du_encoder_lvds_data and rcar_du_encoder_vga_data
structures describe connector properties. Rename them accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Merge LVDS and VGA encoder code

Create a single rcar_du_encoder structure that implements a KMS encoder.
The current implementation is straightforward and only configures CRTC
output routing.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Split VGA encoder and connector

This prepares for the encoders rework.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Split LVDS encoder and connector

This prepares for the encoders rework.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Clarify comment regarding plane Y source coordinate

The R8A7790 DU documentation contains further information regarding the
plane Y source coordinate. Update the comment accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Support per-CRTC clock and IRQ

Some of the DU revisions use one clock and IRQ per CRTC instead of one
clock and IRQ per device. Retrieve the correct clock and register the
correct IRQ for each CRTC.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Add platform module device table

The platform device id driver data field points to a device information
structure that only contains a (currently empty) features field for now.
Support for additional model-dependent features will be added later.

Only the R8A7779 variant is currently supported.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Use devm_ioremap_resource()

Replace the devm_request_mem_region() and devm_ioremap_nocache() calls
with devm_ioremap_resource().

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/rcar-du: Add missing alpha plane register definitions

Several alpha plane register definitions are missing, add them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: provide agp dummies for CONFIG_AGP=n

We currently rely on gcc dead-code elimination so the drm_agp_* helpers
are not called if drm_core_has_AGP() is false. That's ugly as hell so
provide "static inline" dummies for the case that AGP is disabled.

Fixes a build-regression introduced by:

  commit 28ec711cd427f8b61f73712a43b8100ba8ca933b
  Author: David Herrmann <dh.herrmann@gmail.com>
  Date:   Sat Jul 27 16:37:00 2013 +0200

      drm/agp: move AGP cleanup paths to drm_agpsupport.c

v2: switch #ifdef -> #if (spotted by Stephen)

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>

Merge tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Neat that QA (and Ben) keeps on humming along while I'm on vacation, so
you already get the next feature pull request:
- proper eLLC support for HSW from Ben
- more interrupt refactoring
- add w/a tags where we implement them already (Damien)
- hangcheck fixes (Chris) + hangcheck stats (Mika)
- flesh out the new vm structs for ppgtt and ggtt (Ben)
- PSR for Haswell, still disabled by default (Rodrigo et al.)
- pc8+ refclock sequence code from Paulo
- more interrupt refactoring from Paulo, unifying ilk/snb with the ivb/hsw
  interrupt code
- full solution for the Haswell concurrent reg access issues (Chris)
- fix racy object accounting, used by some new leak tests
- fix sync polarity settings on ch7xxx dvo encoder
- random bits&pieces, little fixes and better debug output all over

[airlied: fix conflict with drm_mm cleanups]

* tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel: (289 commits)
  drm/i915: Do not dereference NULL crtc or fb until after checking
  drm/i915: fix pnv display core clock readout out
  drm/i915: Replace open-coded offset_in_page()
  drm/i915: Retry DP aux_ch communications with a different clock after failure
  drm/i915: Add messages useful for HPD storm detection debugging (v2)
  drm/i915: dvo_ch7xxx: fix vsync polarity setting
  drm/i915: fix the racy object accounting
  drm/i915: Convert the register access tracepoint to be conditional
  drm/i915: Squash gen lookup through multiple indirections inside GT access
  drm/i915: Use the common register access functions for NOTRACE variants
  drm/i915: Use a private interface for register access within GT
  drm/i915: Colocate all GT access routines in the same file
  drm/i915: fix reference counting in i915_gem_create
  drm/i915: Use Graphics Base of Stolen Memory on all gen3+
  drm/i915: disable stolen mem for OVERLAY_NEEDS_PHYSICAL
  drm/i915: add functions to disable and restore LCPLL
  drm/i915: disable CLKOUT_DP when it's not needed
  drm/i915: extend lpt_enable_clkout_dp
  drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
  drm/i915: Add some debug breadcrumbs to connector detection
  ...

drm/ttm: inline drm_bo_setup_vm()

This helper is used only once and just wraps a call to
drm_vma_offset_add(). Remove this unneeded indirection to safe 10 lines of
code.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm/mm: remove unused API

We used to pre-allocate drm_mm nodes and save them in a linked list for
later usage so we always have spare ones in atomic contexts. However, this
is really racy if multiple threads are in an atomic context at the same
time and we don't have enough spare nodes. Moreover, all remaining users
run in user-context and just lock drm_mm with a spinlock. So we can easily
preallocate the node, take the spinlock and insert the node.

This may have worked well with BKL in place, however, with today's
infrastructure it really doesn't make any sense. Besides, most users can
easily embed drm_mm_node into their objects so no allocation is needed at
all.

Thus, remove the old pre-alloc API and all the helpers that it provides.
Drivers have already been converted and we should not use the old API for
new code, anymore.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i915: pre-alloc instead of drm_mm search/get_block

i915 is the last user of the weird search+get_block drm_mm API. Convert it
to an explicit kmalloc()+insert_node(). This drops the last user of the
node-cache in drm_mm. We can remove it now in a follow-up patch.

v2:
 - simplify error path in i915_setup_compression()
v3:
 - simplify error path even more

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: replace drm_mm_pre_get() by direct alloc

Instead of calling drm_mm_pre_get() in a row, we now preallocate the node
and then use the atomic insertion functions. This has the exact same
semantics and there is no reason to use the racy pre-allocations.

Note that ttm_bo_man_get_node() does not run in atomic context. Nouveau
already uses GFP_KERNEL alloc in nouveau/nouveau_ttm.c in
nouveau_gart_manager_new(). So we can do the same in
ttm_bo_man_get_node().

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

drm/agp: move AGP cleanup paths to drm_agpsupport.c

Introduce two new helpers, drm_agp_clear() and drm_agp_destroy() which
clear all AGP mappings and destroy the AGP head. This allows to reduce the
AGP code in core DRM and move it all to drm_agpsupport.c.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: don't push static constants on stack for %*ph

There is no need to pass constants via stack. The width may be explicitly
specified in the format.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: const'ify ioctls table (v2)

Because, there is no reason for it not to be const.

v1: original
v2: fix compile break in vmwgfx, and couple related cleanups suggested
    by Ville Syrjälä

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-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/mm: add "best_match" flag to drm_mm_insert_node()

Add a "best_match" flag similar to the drm_mm_search_*() helpers so we
can convert TTM to use them in follow up patches. We can also inline the
non-generic helpers and move them into the header to allow compile-time
optimizations.

To make calls to drm_mm_{search,insert}_node() more readable, this
converts the boolean argument to a flagset. There are pending patches that
add additional flags for top-down allocators and more.

v2:
 - use flag parameter instead of boolean "best_match"
 - convert *_search_free() helpers to also use flags argument

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

drm: Apply kref_put_mutex() optimisations to drm_gem_object_unreference_unlocked()

We can apply the same optimisation tricks as kref_put_mutex() in our
local equivalent function. However, we have a different locking semantic
(we unlock ourselves, in kref_put_mutex() the callee unlocks) so that we
can use the same callbacks for both locked and unlocked kref_put()s and
so can not simply convert to using kref_put_mutex() directly.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: create drm_gem_dumb_destroy

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: Inki Dae <inki.dae@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Ben Skeggs <skeggsb@gmail.com>
Reviwed-by: Rob Clark <robdclark@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i915: Do not dereference NULL crtc or fb until after checking

Fixes regression from
commit 4906557eb37b7fef84fad4304acef6dedf919880
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Thu Jul 11 18:45:05 2013 -0300

    drm/i915: Hook PSR functionality

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67526
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/mm: include required headers in drm_mm.h

We need BUG_ON(), spinlock_t and standard kernel data-types so include the
right headers.

Subject: [drm-intel:drm-intel-nightly 154/166] include/drm/drm_mm.h:67:2:
 error: unknown type name 'spinlock_t'
Message-ID: <51f14693.g5HGdcuw2v3m8FOd%fengguang.wu@intel.com>

In case it didn't link to it correctly. Somehow this bug doesn't occur
here on my machine, hmm. But I think fixing drm_mm.h is better than
changing the include-order in drm_vma_manager.h, so this is what I
did.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Linux 3.11-rc3

Merge tag 'pinctrl-for-v3.11-2' of git://git./linux/kernel/git/linusw/linux-pinctrl

Pull pin control fixes from Linus Walleij:
 - Driver fixes for AM33xx, SIRF and PFC pin controllers
 - Fix a compile warning from the pinctrl single-register driver
 - Fix a little nasty memory leak

* tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  pinctrl: fix a memleak when freeing maps
  pinctrl: pinctrl-single: fix compile warning when no CONFIG_PM
  pinctrl: sh-pfc: fix SDHI0 VccQ regulator on sh73a0 with DT
  arm/dts: sirf: fix the pingroup name mismatch between drivers and dts
  pinctrl: sirf: add usp0_uart_nostreamctrl pin group for usp-uart without flowctrl
  pinctrl: sirf: fix the pin number and mux bit for usp0
  pinctrl: am33xx dt binding: correct include path

Merge tag 'trace-fixes-3.11-rc2' of git://git./linux/kernel/git/rostedt/linux-trace

Pull tracing fixes from Steven Rostedt:
 "Oleg is working on fixing a very tight race between opening a event
  file and deleting that event at the same time (both must be done as
  root).

  I also found a bug while testing Oleg's patches which has to do with a
  race with kprobes using the function tracer.

  There's also a deadlock fix that was introduced with the previous
  fixes"

* tag 'trace-fixes-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus()
  ftrace: Add check for NULL regs if ops has SAVE_REGS set
  tracing: Kill trace_cpu struct/members
  tracing: Change tracing_fops/snapshot_fops to rely on tracing_get_cpu()
  tracing: Change tracing_entries_fops to rely on tracing_get_cpu()
  tracing: Change tracing_stats_fops to rely on tracing_get_cpu()
  tracing: Change tracing_buffers_fops to rely on tracing_get_cpu()
  tracing: Change tracing_pipe_fops() to rely on tracing_get_cpu()
  tracing: Introduce trace_create_cpu_file() and tracing_get_cpu()

Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "This is five bug fixes, two of which fix long standing problems
  causing crashes (sd and mvsas).  The remaining three are hung (isci
  race) or lost (qla2xxx, isci) devices"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  [SCSI] isci: fix breakage caused by >16byte CDB patch
  [SCSI] mvsas: Fix kernel panic on tile due to unaligned data access
  [SCSI] sd: fix crash when UA received on DIF enabled device
  [SCSI] qla2xxx: Properly set the tagging for commands.
  [SCSI] isci: Fix a race condition in the SSP task management path