drm_vblank_count() returns the software counter. We should not pretend
it's the hw counter since we use the hw counter to figuere out what the
software counter value should be. So instead provide a new function
drm_vblank_no_hw_counter() for drivers that don't have a real hw
counter. The new function simply returns 0, which is about the only
thing it can do.

Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVincent Abriou <vincent.abriou@st.com>
[danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface
change.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This continues the pattern started in commit cc1ef118 ("drm/irq:
Make pipe unsigned and name consistent"). This is applied to the public
APIs and driver callbacks, so pretty much all drivers need to be updated
to match the new prototypes.

Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jianwei Wang <jianwei.wang.chn@gmail.com>
Cc: Alison Wang <alison.wang@freescale.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And use it in radeon to replace all the ioctls no longer valid in kms
mode. I plan to also use this later on when nuking the ums support for
i915.

Note that setting the function pointer in the ioctl table to NULL
would amount to the same, but that results in some debug output from
the drm_ioctl() function. I've figured it's cleaner to have a
special-purpose function.

Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This function is the KMS native variant of drm_vblank_count_and_time().
It takes a struct drm_crtc * instead of a struct drm_device * and an
index of the CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

pixeldur_ns is now unsued, so kill it from drm_vblank_crtc. framedur_ns
is also currently unused but we will have use for it in the near future
so leave it be. linedur_ns is still used by nouveau for some internal
delays.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

linedur_ns, and especially pixeldur_ns are becoming rather inaccurate
to be used for the vblank timestamp correction. With 4k@60 the pixel
duration is already below 2ns, so the amount of error due to the
truncation to nanoseconds is introducing quite a bit of error.

We can avoid such problems if we instead calculate the timestamp
delta_ns directly from the dislay timings, avoiding the use of
these intermediate truncated values.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Squash in fixup from Thierry Reding for amdgpu.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Collect the timestamping constants alongside the rest of the relevant
stuff under drm_vblank_crtc.

We can now get rid of the 'refcrtc' parameter to
drm_calc_vbltimestamp_from_scanoutpos().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This way drm_ioctl_permit() can be used by drivers
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Name all references to the pipe number (CRTC index) consistently to make
it easier to distinguish which is a pipe number and which is a pointer
to struct drm_crtc.

While at it also make all references to the pipe number unsigned because
there is no longer any reason why it should ever be negative.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In

commit 99264a61
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 15 19:34:43 2015 +0200

    drm/vblank: Fixup and document timestamp update/read barriers

I've switched vblank->count from atomic_t to unsigned long and
accidentally created an integer comparison bug in
drm_vblank_count_and_time since vblanke->count might overflow the u32
local copy and hence the retry loop never succeed.

Fix this by consistently using u32.

Cc: Michel Dänzer <michel@daenzer.net>
Reported-by: NMichel Dänzer <michel@daenzer.net>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Two nice things here:
- drm_dev_register will truly register everything in the right order
  if the driver doesn't have a ->load callback. Before this we had to
  init the primary mode_group after the device nodes where already
  registered.

- Less things to keep track of when reworking the connector locking,
  yay!
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

The context functions are not used by the i915 driver and should not
be used by modeset drivers. These driver functions contain several bugs
and security holes. This change makes these functions optional can be
turned on by a setting, they are turned off by default for modeset
driver with the exception of the nouvea driver that may require them with
an old version of libdrm.

The previous attempt was

commit 7c510133
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 8 15:41:21 2013 +0200

    drm: mark context support as a legacy subsystem

but this had to be reverted

commit c21eb21c
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Sep 20 08:32:59 2013 +1000

    Revert "drm: mark context support as a legacy subsystem"

v2: remove returns from void function, and formatting (Daniel Vetter)

v3:
- s/Nova/nouveau/ in the commit message, and add references to the
  previous attempts
- drop the part touching the drm hw lock, that should be a separate
  patch.

Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2)
Cc: Peter Antoine <peter.antoine@intel.com> (v2)
Reviewed-by: NPeter Antoine <peter.antoine@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch adds a kms driver for the virtio gpu.  The xorg modesetting
driver can handle the device just fine, the framebuffer for fbcon is
there too.

Qemu patches for the host side are under review currently.

The pci version of the device comes in two variants: with and without
vga compatibility.  The former has a extra memory bar for the vga
framebuffer, the later is a pure virtio device.  The only concern for
this driver is that in the virtio-vga case we have to kick out the
firmware framebuffer.

Initial revision has only 2d support, 3d (virgl) support requires
some more work on the qemu side and will be added later.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>

Add an ioctl which allows users to create blob properties from supplied
data. Currently this only supports modes, creating a drm_display_mode from
the userspace drm_mode_modeinfo.

v2: Removed size/type checks.
    Rebased on new patches to allow error propagation from create_blob,
    as well as avoiding double-allocation.
Signed-off-by: NDaniel Stone <daniels@collabora.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@intel.com>
Tested-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The magic auth tokens we have are a simple map from cyclic IDs to drm_file
objects. Remove all the old bulk of code and replace it with a simple,
direct IDR.

The previous behavior is kept. Especially calling authmagic multiple times
on the same magic results in EINVAL except on the first call. The only
difference in behavior is that we never allocate IDs multiple times as
long as a client has its FD open.

v2:
 - Fix return code of GetMagic()
 - Use non-cyclic IDR allocator
 - fix off-by-one in "magic > INT_MAX" sanity check

v3:
 - drop redundant "magic > INT_MAX" check
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This list is write-only. It's never used for read-access, so no reason to
keep it around. Drop it!
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
  under the protection of dev->vblank_time_lock. Switch to an unsigned
  long instead and update comments. Note that atomic_read is just a
  normal read of a volatile variable, so no need to audit all the
  read-side access specifically.

- The barriers for the vblank counter seqlock weren't complete: The
  read-side was missing the first barrier between the counter read and
  the timestamp read, it only had a barrier between the ts and the
  counter read. We need both.

- Barriers weren't properly documented. Since barriers only work if
  you have them on boths sides of the transaction it's prudent to
  reference where the other side is. To avoid duplicating the
  write-side comment 3 times extract a little store_vblank() helper.
  In that helper also assert that we do indeed hold
  dev->vblank_time_lock, since in some cases the lock is acquired a
  few functions up in the callchain.

Spotted while reviewing a patch from Chris Wilson to add a fastpath to
the vblank_wait ioctl.

v2: Add comment to better explain how store_vblank works, suggested by
Chris.

v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the
implicit barrier in the spin_unlock. But that can only be proven by
auditing all callers and my point in extracting this little helper was
to localize all the locking into just one place. Hence I think that
additional optimization is too risky.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Peter Hurley <peter@hurleysoftware.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-and-tested-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Improve the readability and keeps the lines shorter than 80 columns.
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

ioctl->cmd_drv is pointless and we can just as well stick the full ioctl
definition into ioctl->cmd.

Cc: Jakob Bornecrantz <jakob@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently DRM_IOCTL_DEF_DRV does '[DRM_IOCTL_NR(DRM_##ioctl)]' which
doesn't make much sense since DRM_##ioctl is already a the raw ioctl
number. So change it to 'DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE'
which means the DRM_IOCTL_NR() now makes sense, and also this also means
if there's a mistake in the DRM_IOCTL_##ioctl macros we might get a
warning about it (eg. we would have gotten a sparse warning about the
i915 colorkey get/set ioctl being defined to be the same thing).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atomic state handling adds a lot of indirection and complexity between
simple updates and drivers. For easier debugging the diagnostic output
is therefore rather chatty. Which is great for tracking down atomic
issues, but really annoying otherwise.

Add a new DRM_DEBUG_ATOMIC to be able to filter this out.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

At driver load we need to tell the vblank code about the state of the
pipes, so that the logic around reject vblank_get when the pipe is off
works correctly.

Thus far i915 used drm_vblank_off, but one of the side-effects of it
is that it also saves the vblank counter. And for that it calls down
into the ->get_vblank_counter hook. Which isn't really a good idea
when the pipe is off for a few reasons:
- With runtime pm the register might not respond.
- If the pipe is off some datastructures might not be around or
  unitialized.

The later is what blew up on gen3: We look at intel_crtc->config to
compute the vblank counter, and for a disabled pipe at boot-up that's
just not there. Thus far this was papered over by a check for
intel_crtc->active, but I want to get rid of that (since it's fairly
race, vblank hooks are called from all kinds of places).

So prep for that by adding a _reset functions which only does what we
really need to be done at driver load: Mark the vblank pipe as off,
but don't do any vblank counter saving or event flushing - neither of
that is required.

v2: Clarify the code flow slightly as suggested by Ville.

v3: Fix kerneldoc spelling, spotted by Laurent.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v2)
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Once a driver is using atomic helpers for modeset, the next step is to
switch over to atomic properties.  To do this, make sure that any
modeset objects have their ->atomic_{get,set}_property() vfuncs suitably
populated if they have custom properties (you did already remember to
plug in atomic-helper func for the legacy ->set_property() vfuncs,
right?), and then set DRIVER_ATOMIC bit in driver_features flag.

A new cap is introduced, DRM_CLIENT_CAP_ATOMIC, for the purposes of
shielding legacy userspace from atomic properties.  Mostly for the
benefit of legacy DDX drivers that do silly things like getting/setting
each property at startup (since some of the new atomic properties will
be able to trigger modeset).
Signed-off-by: NRob Clark <robdclark@gmail.com>
[danvet: Squash in fixup patch to check for DRM_MODE_PROP_ATOMIC
instaed of the CAP define when filtering properties. Reported by
Tvrtko Uruslin, acked by Rob.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The .irq and .irq_enabled fields are part of the VBLANK interrupt
handling infrastructure, so move them to the appropriate section within
the structure.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This function is the KMS native variant of drm_vblank_count(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This function is the KMS native variant of drm_handle_vblank(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This function is the KMS native variant of drm_send_vblank_event(). It
takes a struct drm_crtc * instead of a struct drm_device * and an index
of the CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Implementing a dummy of this function allows drivers that use it to be
built on platforms that don't have PCI. This can happen for example if
the nouveau driver is built on Tegra without PCI enabled (or on 64-bit
ARM where PCI is not yet implemented).
Signed-off-by: NThierry Reding <treding@nvidia.com>

The number of pages can never be negative, so an unsigned type is
enough. This also matches the type of the n_pages argument of the
sg_alloc_table_from_pages() function.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Removing the unnecessary drm_err __func__ argument by using
the equivalent %pf and __builtin_return_address(0) makes the
code smaller for every use of the DRM_ERROR macro.

For instance: (allmodconfig)

$ size drivers/gpu/drm/i915/i915.o*
   text	   data	    bss	    dec	    hex	filename
 922447	 193257	 296736	1412440	 158d58	drivers/gpu/drm/i915/i915.o.new
 928111	 193257	 296736	1418104	 15a378	drivers/gpu/drm/i915/i915.o.old
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Allows importing dma_reservation_objects from a dma-buf.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>

v2: Don't forget git add, noticed by David.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In my header cleanup I've missed the debugfs functions completely.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Somehow I've missed these three, fix this up asap. Plus move
drm_master_create since while at it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Leftover from my previous header cleanup.

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

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

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

The return value is not used by callers of this function
nor by uses of the DRM_ERROR macro so change the function
to return void.
Signed-off-by: NJoe Perches <joe@perches.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only used in one place ever, so put it right next to that.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>