Граф коммитов

11 Коммитов

Автор SHA1 Сообщение Дата
Dave Airlie f073d78eeb Merge tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Driver Changes:

- Lift alpha_support protection from Cannonlake (Rodrigo)
	* Meaning the driver should mostly work for the hardware we had
	  at our disposal when testing
	* Used to be preliminary_hw_support
- Add missing Cannonlake PCI device ID of 0x5A4C (Rodrigo)
- Cannonlake port register fix (Mahesh)

- Fix Dell Venue 8 Pro black screen after modeset (Hans)
- Fix for always returning zero out-fence from execbuf (Daniele)
- Fix HDMI audio when no no relevant video output is active (Jani)
- Fix memleak of VBT data on driver_unload (Hans)

- Fix for KASAN found locking issue (Maarten)
- RCU barrier consolidation to improve igt/gem_sync/idle (Chris)
- Optimizations to IRQ handlers (Chris)
- vblank tracking improvements (64-bit resolution, PM) (Dhinakaran)
- Pipe select bit corrections (Ville)
- Reduce runtime computed device_info fields (Chris)
- Tune down some WARN_ONs to GEM_BUG_ON now that CI has good coverage (Chris)
- A bunch of kerneldoc warning fixes (Chris)

* tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel: (113 commits)
  drm/i915: Update DRIVER_DATE to 20180221
  drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced
  drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning
  drm/i915: Move the policy for placement of the GGTT vma into the caller
  drm/i915: Also check view->type for a normal GGTT view
  drm/i915: Drop WaDoubleCursorLP3Latency:ivb
  drm/i915: Set the primary plane pipe select bits on gen4
  drm/i915: Don't set cursor pipe select bits on g4x+
  drm/i915: Assert that we don't overflow frontbuffer tracking bits
  drm/i915: Track number of pending freed objects
  drm/i915/: Initialise trans_min for skl_compute_transition_wm()
  drm/i915: Clear the in-use marker on execbuf failure
  drm/i915: Prune gen8_gt_irq_handler
  drm/i915: Track GT interrupt handling using the master iir
  drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_use
  drm: intel_dpio_phy: fix kernel-doc comments at nested struct
  drm/i915: Release connector iterator on a digital port conflict.
  drm/i915/execlists: Remove too early assert
  drm/i915: Assert that we always complete a submission to guc/execlists
  drm: move read_domains and write_domain into i915
  ...
2018-03-01 14:07:22 +10:00
Daniel Vetter 83a7dff07f drm/doc: Use new substruct support
Support for this just recently landed in linux-next.

Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-5-daniel.vetter@ffwll.ch
2018-02-20 14:24:38 +01:00
Dhinakaran Pandiyan d0bb96b4be drm/vblank: Restoring vblank counts after device PM events.
The HW frame counter can get reset if device enters a low power state after
vblank interrupts were disabled. This messes up any following vblank count
update as a negative diff (huge unsigned diff) is calculated from the HW
frame counter change. We cannot ignore negative diffs altogther as there
could be legitimate wrap arounds. So, allow drivers to update vblank->count
with missed vblanks for the time interrupts were disabled. This is similar
to _crtc_vblank_on() except that vblanks interrupts are not enabled at the
end as this function is expected to be called from the driver
_enable_vblank() vfunc.

v2: drm_crtc_vblank_restore should take crtc as arg. (Chris)
    Add docs and sprinkle some asserts.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-9-dhinakaran.pandiyan@intel.com
2018-02-15 11:50:14 -08:00
Dhinakaran Pandiyan 3b765c0b76 drm/vblank: Data type fixes for 64-bit vblank sequences.
drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
space requested vblank sequence using this clipped 32-bit count(when the
value is >= 2^32) as reference, the requested sequence remains a 32-bit
value and gets queued like that. However, the code that checks if the
requested sequence has passed compares this against the 64-bit vblank
count.

With drm_vblank_count() returning all bits of the vblank count, update
drm_crtc_accurate_vblank_count() so that drm_crtc_arm_vblank_event() queues
the correct sequence. Otherwise, this leads to prolonged waits for a vblank
sequence when the current count is >=2^32.

Finally, fix drm_wait_one_vblank() too.

v2: Commit message fix (Keith)
    Squash commits (Rodrigo)

Fixes: 570e86963a ("drm: Widen vblank count to 64-bits [v3]")
Cc: Keith Packard <keithp@keithp.com>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-1-dhinakaran.pandiyan@intel.com
2018-02-15 11:48:09 -08:00
Keith Packard 3064abfa93 drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3]
These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.

v2:

 * Check for DRIVER_MODESET in new crtc-based vblank ioctls

	Failing to check this will oops the driver.

 * Ensure vblank interupt is running in crtc_get_sequence ioctl

	The sequence and timing values are not correct while the
	interrupt is off, so make sure it's running before asking for
	them.

 * Short-circuit get_sequence if the counter is enabled and accurate

	Steal the idea from the code in wait_vblank to avoid the
	expense of drm_vblank_get/put

 * Return active state of crtc in crtc_get_sequence ioctl

	Might be useful for applications that aren't in charge of
	modesetting?

 * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls

	Daniel Vetter prefers these over the old drm_vblank_put/get
	APIs.

 * Return s64 ns instead of u64 in new sequence event

Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

v3:

 * Removed FIRST_PIXEL_OUT_FLAG
 * Document that the timestamp in the query and event are
   that of the first pixel leaving the display engine for
   the display (using the same wording as the Vulkan spec).

Suggested-by: Michel Dänzer <michel@daenzer.net>
Acked-by: Dave Airlie <airlied@redhat.com>

[airlied: left->leaves (Michel)]

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-10-23 11:15:03 +10:00
Keith Packard bd386e5180 drm: Reorganize drm_pending_event to support future event types [v2]
Place drm_event_vblank in a new union that includes that and a bare
drm_event structure. This will allow new members of that union to be
added in the future without changing code related to the existing vbl
event type.

Assignments to the crtc_id field are now done when the event is
allocated, rather than when delievered. This way, delivery doesn't
need to have the crtc ID available.

v2:
 * Remove 'dev' argument from create_vblank_event

	It wasn't being used anyways, and if we need it in the future,
	we can always get it from crtc->dev.

 * Check for MODESETTING before looking for crtc in queue_vblank_event

	UMS drivers will oops if we try to get a crtc, so make sure
	we're modesetting before we try to find a crtc_id to fill into
	the event.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit dc695b85fde88eca3ef3b03fcd82f15b6bc6e462)
2017-10-21 07:23:40 +10:00
Keith Packard 570e86963a drm: Widen vblank count to 64-bits [v3]
This modifies the datatypes used by the vblank code to provide 64 bits
of vblank count.

The driver interfaces have been left using 32 bits of vblank count;
all of the code necessary to widen that value for the user API was
already included to handle devices returning fewer than 32-bits.

This will provide the necessary datatypes for the Vulkan API.

v2:

 * Re-write wait_vblank ioctl to ABSOLUTE sequence

    When an application uses the WAIT_VBLANK ioctl with RELATIVE
    or NEXTONMISS bits set, the target vblank interval is updated
    within the kernel. We need to write that target back to the
    ioctl buffer and update the flags bits so that if the wait is
    interrupted by a signal, when it is re-started, it will target
    precisely the same vblank count as before.

 * Leave driver API with 32-bit vblank count

v3:

 * Rebase on top of Arnd Bergmann's patch which had
   the switch to ktime_t parts.

[airlied: fix conflict with Ville vblank change].

Suggested-by:  Michel Dänzer <michel@daenzer.net>
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 2affbc16983e4fc90960bc7f70e7615f4228199b)
2017-10-21 07:23:24 +10:00
Arnd Bergmann 67680d3c04 drm: vblank: use ktime_t instead of timeval
The drm vblank handling uses 'timeval' to store timestamps in either
monotonic or wall-clock time base. In either case, it reads the current
time as a ktime_t in get_drm_timestamp() and converts it from there.

This is a bit suspicious, as users of 'timeval' often suffer from
the time_t overflow in y2038. I have gone through this code and
found that it is unlikely to cause problems here:

- The user space ABI does not use time_t or timeval, but uses
  'u32' and 'long' as the types. This means at least that rebuilding
  user programs against a new libc with 64-bit time_t does not
  change the ABI.

- As of commit c61eef726a ("drm: add support for monotonic vblank
  timestamps") in linux-3.8, the monotonic timestamp is the default
  and can only get reverted to wall-clock through a module-parameter.

- With the default monotonic timestamps, there is no problem at all.

- The drm_wait_vblank_ioctl() interface is alway safe on 64-bit
  architectures, on 32-bit it might overflow the 'long' timestamps
  in 2038 with wall-clock timestamps.

- The event handling uses 'u32' seconds, which overflow in 2106
  on both 32-bit and 64-bit machines, when wall-clock timestamps
  are used.

- The effect of overflowing either of the two is only temporary
  (during the overflow, and is likely to keep working again
  afterwards. It is likely the same problem as observing a
  'settimeofday()' call, which was the reason for moving to the
  monotonic timestamps in the first place.

Overall, this seems good enough, so my patch removes the use of
'timeval' from the vblank handling altogether and uses ktime_t
consistently, except for the part where we copy the data to user
space structures in the existing format.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-10-13 08:34:46 +10:00
Daniel Vetter b4164d66c4 drm/vblank: Unexport drm_vblank_cleanup
There's no reason for drivers to call this, and all the ones I've
removed looked very fishy:
- Proper quiescenting of the vblank machinery should be done by
  calling drm_crtc_vblank_off(), which is best done by shutting down
  the entire display engine with drm_atomic_helper_shutdown.

- Releasing of allocated memory is done by the core already, it calls
  drm_vblank_cleanup as a fallback.

- drm_vblank_cleanup also has checks for drivers which forget to clean
  up vblank interrupts.

This essentially reverts

commit e77cef9c2d
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jan 7 15:39:13 2010 +0100

    drm: Avoid calling vblank function is vblank wasn't initialized

which was done to fix a bug in radeon code with msi interrupts:

commit 003e69f986
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jan 7 15:39:14 2010 +0100

    drm/radeon/kms: Don't try to enable IRQ if we have no handler installed

Afaict from digging around in old code, this was needed to avoid
blowing up in the ums fallback, and has stopped serving it's purpose
long ago - if irq init fails, the driver fails to load, and there's
really no way to blow up anymore.

Long story short, this was most likely a small ums compat/fallback
hack that became a thing of it's own and got cargo-cult duplicated all
over the drm codebase for essentially no gain at all.

v2: Mention that for drivers with a ->release callback cleanup is
handled by drm_dev_fini() (Thierry).

Cc: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626161949.25629-2-daniel.vetter@ffwll.ch
2017-06-28 12:51:13 +02:00
Daniel Vetter ca814b2553 drm/vblank: Consistent drm_crtc_ prefix
We use drm_crtc_ for all the new-style vblank functions which directly
take a struct drm_crtc *. drm_accurate_vblank_count was the odd one
out, correct this to appease my OCD.

Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-13-daniel.vetter@ffwll.ch
2017-06-20 10:28:58 +02:00
Daniel Vetter 3ed4351a83 drm: Extract drm_vblank.[hc]
drm_irq.c contains both the irq helper library (optional) and the
vblank support (optional, but part of the modeset uapi, and doesn't
require the use of the irq helpers at all.

Split this up for more clarity of the scope of the individual bits.

v2: Move misplaced hunks to this patch (Stefan).

Cc: Stefan Agner <stefan@agner.ch>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170531092146.12528-1-daniel.vetter@ffwll.ch
2017-06-01 08:02:14 +02:00