Since Daniel documented things with a sledge hammer, we got lots of
nice backtraces in suspend/resume operations, I've check the callers
of this and they all seems safe to me,

This fixes one set of warns I reported.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The locking in drm_fb_helper_initial_config is a bit troublesome for a
few reasons:

- We can't just wrap the entire function up into modeset locks since
  the fbdev registration might call down into fbcon code, which then
  through our ->set_par implementation needs to be able to grab all
  modeset locks. So we'd have a neat deadlock.

- This implies though that all current callers don't hold any modeset
  locks by necessity, so we have free reign to grab any modeset locks
  we need to grab.

- The private state of the fbdev helper doesn't need any protection
  through locks, since once we have the fbdev registered it is mostly
  invariant or protected through the modeset locking in ->set_par and
  other callbacks. We can fully rely on driver having non-racy setup
  sequences here. For the initial config computation we actually may
  not grab locks since drivers which provide their own magic sauce
  (like i915) might need to grab locks themselves.

- We should grab locks though when we probe outputs. Currently there's
  not much risk, but already now userspace could start poking at sysfs
  files and so probe concurrently. I expect that in the future driver
  init will be much more async, and since probing is really
  time-consuming this is a prime candidate.

- We must not hold any crtc->mutex locks while calling probe functions
  since those might need to lock a crtc for e.g. load detection. i915
  is such a driver.

Also it's the probing calls which hit upon piles of new locking
asserts I've recently added in

commit 62ff94a5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jan 23 22:18:47 2014 +0100

    drm/crtc-helper: remove LOCKING from kerneldoc

and

commit 63951385
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jan 23 15:14:15 2014 +0100

    drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c

Hence the right fix is to grab the mode_config mutex, but only that
and only right around the probe calls.

It seems to be sufficient to shut up all the locking WARNINGs I see on
i915 and nouveau in drm_fb_helper_initial_config.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We have two calling contexts for thise function:

- In the crtc helper code itself as part of the ->set_config
  implementation. In this calling context all modeset locks are
  already held, as they should.

- In drivers not implementing fastboot before the fbdev/fbcon setup
  and initialization. This has been added for all drivers in

  commit 76a39dbf
  Author: Daniel Vetter <daniel.vetter@ffwll.ch>
  Date:   Sun Jan 20 23:12:54 2013 +0100

      drm/fb-helper: don't disable everything in initial_config

  In this calling context we do not hold any modeset locks since the
  immediately following call to initialize the fbev emulation grabs
  all these locks themselves.

- There are two exceptions to the above rule: shmob doesn't have fbdev
  emulation support. I've manually checked the callchain up to the
  driver load function and no kms locks are held.

The right fix therefore is to split this helper into an internal and
external version and add the required locking to the function exported
to drivers.

This remedies locking inconsistencies exposed by me adding locking
WARNs as part of the recent kerneldoc abi polishing done in

commit 62ff94a5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jan 23 22:18:47 2014 +0100

    drm/crtc-helper: remove LOCKING from kerneldoc

and

commit 63951385
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jan 23 15:14:15 2014 +0100

    drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c

v2: It helps when I actually git add the entire thing.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not sure why git didn't flag this, but the result of automerge
from 3.14-rc7 screwed up the radeon init procedure.

Reported-by: Fireburn on #radeon
Signed-off-by: NDave Airlie <airlied@redhat.com>

The sg_table made when gem cma is created isn't used anywhere. The sgt
of struct drm_gem_cma_object will have only sg_tabel imported.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

These are unused and can safely be dropped. DRM core verifies they're
non-NULL before it calls them.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Improve readability by adding/changing inline documentation
Signed-off-by: NArthur Borsboom <arthurborsboom@gmail.com>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Code cleanup by following i915 constant/variable names and ordering
Code cleanup by following directions from kernel doc: Codingstyle
Code cleanup by following directions from kernel doc: DRM
Signed-off-by: NArthur Borsboom <arthurborsboom@gmail.com>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Removed centralized exiting of function (goto statement), since it was
the only used in one single location with only a return statement.
Signed-off-by: NArthur Borsboom <arthurborsboom@gmail.com>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Previously the backlight code was called from IRQ context which isn't
allowed. This patch moves all the asle work into a work task which takes
care of the locking bug reported by users.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64221Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

The gma500 driver sets DRIVER_GEM unconditionally, so testing for the
absence of the feature will always fail.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

We'll need this for our gem create ioctl in a later patch.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

All of these ioctls are unused and most of them just duplicate what drm
already provides.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Properly init the MMU and add MMU entries when adding GTT entries
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Right now, all we need to know about the blitter is that it's not doing
anything that can be messed up when fiddling with MMU mappings.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Add 2D blit status and MMU fault interrupts to the IRQ handler.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Old MMU code never wrote PDs or PTEs to any registers. Now we do, and
that's a good start.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

This regression has been introduced in

commit b3f2333d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 11 11:34:31 2013 +0100

    drm: restrict the device list for shadow attached drivers
Reported-by: NDave Jones <davej@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>

Since we cannot make sure the 'max_conn_count' will always be none
zero from the users, and then if max_conn_count equals to zero, the
kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16).

So this patch fix this with just doing the 'max_conn_count' zero check
in the front of drm_fb_helper_init().
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
CC: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We allocate memory in drm_display_mode_from_vic_index() and use it
without checking the pointer is valid. Fix that.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use drm_fb_helper_restore_fbdev_mode() in drm_fb_helper_set_par() to
make sure extra planes get disabled whenever fbcon takes over.

Otherwise the code in drm_fb_helper_set_par() was already doing the
exact same thing as drm_fb_helper_restore_fbdev_mode(), so this doesn't
change the behaviour in any other way.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We used to protect minor-lookup and setup by the global drm lock. To
continue our attempts of dropping drm_global_mutex, this patch makes the
minor management independent of it. Furthermore, we make it all atomic and
switch to spin-locks instead of a mutex.

Now that minor-lookup is independent, we also move the
"drm_is_unplugged()" test into the minor-lookup path. There is no reason
to ever return a minor for unplugged objects, so keep that logic internal.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

We can significantly simplify this helper by using plain multiplication.
Note that we converted the minor-type to an enum earlier so this didn't
work before.

We also fix a minor range-bug here: the limit argument of idr_alloc() is
*exclusive*, not inclusive, so we should use 64 instead of 63 as offset.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

Properly name goto-labels, remove empty lines and use DRM_ERROR if
possible.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

Whenever we access minor->device, we are in a minor->kdev->...->fops
callback so the minor->kdev pointer *must* be valid. Thus, simply use
minor->kdev->devt instead of minor->device and remove the redundant field.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No need to check for DEBUGFS, we already have dummy-fallbacks in our
headers.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_get_minor() no longer allocates objects, and drm_unplug_minor() is now
the exact reverse of it. Rename it to _register/unregister() so their
name actually says what they do.

Furthermore, remove the direct minor-ptr and instead pass the minor-type.
This way we know the actual slot of the minor and can reset it if
required.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

_put/get() are used for ref-counting, which we clearly don't do here.
Rename it to _free() and also use the common drm_minor_* prefix.
Furthermore, avoid passing the minor directly but instead use the type
like the other functions do, this allows us to reset the slot.

We also drop the redundant call to drm_unplug_minor() as drm_minor_free()
is only used from paths were that has already be called.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of waiting for device-registration, we now allocate minor-objects
during device allocation. The minors are not registered or assigned an ID.
This is still postponed to device-registration.

While at it, remove the superfluous output-parameter in drm_get_minor().

The reason for this early allocation is to make
dev->primary/control/render available atomically. So once the device is
alive, all of them are already set and we never have the situation where
one of them is set after another (they're either NULL or set, but never
changed). This will eventually allow us to reduce minor-ID allocation to
one base-ID instead of a single ID for each.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of accessing drm_minors_idr directly, this adds a small helper to
hide the internals. This will help us later to remove the drm_global_mutex
requirement for minor-lookup.

Furthermore, this also makes sure that minor->dev is always valid and
takes a reference-count to the device as long as the minor is used in an
open-file. This way, "struct file*"->private_data->dev is guaranteed to be
valid (which it has to, as we cannot reset it).
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Lets not trick ourselves into thinking "drm_device" objects are not
ref-counted. That's just utterly stupid. We manage "drm_minor" objects on
each drm-device and each minor can have an unlimited number of open
handles. Each of these handles has the drm_minor (and thus the drm_device)
as private-data in the file-handle. Therefore, we may not destroy
"drm_device" until all these handles are closed.

It is *not* possible to reset all these pointers atomically and restrict
access to them, and this is *not* how this is done! Instead, we use
ref-counts to make sure the object is valid and not freed.

Note that we currently use "dev->open_count" for that, which is *exactly*
the same as a reference-count, just open coded. So this patch doesn't
change any semantics on DRM devices (well, this patch just introduces the
ref-count, anyway. Follow-up patches will replace open_count by it).

Also note that generic VFS revoke support could allow us to drop this
ref-count again. We could then just synchronously disable any fops->xy()
calls. However, this is not the case, yet, and no such patches are
in sight (and I seriously question the idea of dropping the ref-cnt
again).
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

The drm_open_helper() function is only used internally for drm_open() so
we can safely pass in the minor-object directly instead of the minor-id.
This way, we avoid the additional minor IDR lookup, which we already do
twice in drm_stub_open() and drm_open().
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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>

Our current DRM design uses a single address_space for all users of the
same DRM device. However, there is no way to create an anonymous
address_space without an underlying inode. Therefore, we wait for the
first ->open() callback on a registered char-dev and take-over the inode
of the char-dev. This worked well so far, but has several drawbacks:
 - We screw with FS internals and rely on some non-obvious invariants like
   inode->i_mapping being the same as inode->i_data for char-devs.
 - We don't have any address_space prior to the first ->open() from
   user-space. This leads to ugly fallback code and we cannot allocate
   global objects early.

As pointed out by Al-Viro, fs/anon_inode.c is *not* supposed to be used by
drivers for anonymous inode-allocation. Therefore, this patch follows the
proposed alternative solution and adds a pseudo filesystem mount-point to
DRM. We can then allocate private inodes including a private address_space
for each DRM device at initialization time.

Note that we could use:
  sysfs_get_inode(sysfs_mnt->mnt_sb, drm_device->dev->kobj.sd);
to get access to the underlying sysfs-inode of a "struct device" object.
However, most of this information is currently hidden and it's not clear
whether this address_space is suitable for driver access. Thus, unless
linux allows anonymous address_space objects or driver-core provides a
public inode per device, we're left with our own private internal mount
point.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>