Joonas Lahtinen
74c0167f8b
Merge drm-next into drm-intel-next-queued
...
Pull 4.15 into drm-intel-next-queued for next feature pull.
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2018-01-29 11:51:57 +02:00
Lionel Landwerlin
5db47e37b3
Revert "drm/i915: mark all device info struct with __initconst"
...
This reverts commit 5b54eddd39
.
Conflicts:
drivers/gpu/drm/i915/i915_pci.c
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Fixes: 5b54eddd39
("drm/i915: mark all device info struct with __initconst")
Link: https://patchwork.freedesktop.org/patch/msgid/20180129083346.29173-1-lionel.g.landwerlin@intel.com
2018-01-29 09:25:05 +00:00
Chris Wilson
1d2a19c256
drm/i915/lrc: Remove superfluous WARN_ON
...
Remove the WARN_ON(ce->state) inside the static function only called
when ce->state == NULL and downgrade the w/a batch setup warning into a
developer only mode (GEM_WARN_ON).
v2: Move the deferred alloc guard into the callee, eliminating the need
for the WARN_ON:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-1 (-1)
Function old new delta
execlists_context_pin 1819 1818 -1
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180126121846.12007-1-chris@chris-wilson.co.uk
2018-01-26 13:03:07 +00:00
Manasi Navare
e0bd878a95
drm/dp: Add HBR3 support in existing DRM DP helpers
...
Existing helpers add support upto HBR2. This patch
adds support for HBR3 rate (8.1 Gbps) introduced as
part of DP 1.4 specification.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com >
Reviewed-by: Harry Wentland <harry.wentland@amd.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/1516660991-20697-1-git-send-email-manasi.d.navare@intel.com
2018-01-26 13:36:53 +02:00
Dave Airlie
baa35cc322
Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
...
Single irq regression fix
* 'linux-4.15' of git://github.com/skeggsb/linux:
drm/nouveau: Move irq setup/teardown to pci ctor/dtor
2018-01-26 15:27:07 +10:00
Lyude Paul
0fd189a95f
drm/nouveau: Move irq setup/teardown to pci ctor/dtor
...
For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not even nessecary.
This was made apparent by what appeared to be a regression in the
mainline kernel that started introducing suspend/resume issues for
nouveau:
a0c9259dc4
(irq/matrix: Spread interrupts on allocation)
After this commit was introduced, we started getting interrupts from the
GPU before we actually re-allocated our own IRQ (see references below)
and assigned the IRQ handler. Investigating this turned out that the
problem was not with the commit, but the fact that nouveau even
free/allocates it's irqs before and after suspend/resume.
For starters: drivers in the linux kernel haven't had to handle
freeing/re-allocating their IRQs during suspend/resume cycles for quite
a while now. Nouveau seems to be one of the few drivers left that still
does this, despite the fact there's no reason we actually need to since
disabling interrupts from the device side should be enough, as the
kernel is already smart enough to know to disable host-side interrupts
for us before going into suspend. Since we were tearing down our IRQs by
hand however, that means there was a short period during resume where
interrupts could be received before we re-allocated our IRQ which would
lead to us getting an unhandled IRQ. Since we never handle said IRQ and
re-arm the interrupt registers, this would cause us to miss all of the
interrupts from the GPU and cause our init process to start timing out
on anything requiring interrupts.
So, since this whole setup/teardown every suspend/resume cycle is
useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor
functions instead so they're only called at driver load and driver
unload. This should fix most of the issues with pending interrupts on
resume, along with getting suspend/resume for nouveau to work again.
As well, this probably means we can also just remove the msi rearm call
inside nvkm_pci_init(). But since our main focus here is to fix
suspend/resume before 4.15, we'll save that for a later patch.
Signed-off-by: Lyude Paul <lyude@redhat.com >
Cc: Karol Herbst <kherbst@redhat.com >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: Mike Galbraith <efault@gmx.de >
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com >
2018-01-26 09:44:39 +10:00
Chris Wilson
09b1a4e4b5
drm/i915/lrc: Clear context restore/save inhibit flags for new contexts
...
CTX_CONTEXT_CONTROL (CTX_SR_CTL) operates as a masked register and so
will only apply the bits that are selected by the upper half. In the
case of selectively enabling sr inhibit, this may mean the context keeps
the current setting (so forgetting to save the context later, eventually
leading to a very upset GPU!).
Fixes: 517aaffe0c
("drm/i915/execlists: Inhibit context save/restore for the fake preempt context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180125112443.12745-1-chris@chris-wilson.co.uk
Reviewed-by: Michel Thierry <michel.thierry@intel.com >
2018-01-25 18:04:25 +00:00
Dave Airlie
7e3f8e91e8
Merge tag 'drm-misc-fixes-2018-01-24' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
...
Two vc4 fixes that were applied in the last day.
One fixes a NULL dereference, and the other fixes
a flickering bug.
Cc: Eric Anholt <eric@anholt.net >
Cc: Boris Brezillon <boris.brezillon@free-electrons.com >
* tag 'drm-misc-fixes-2018-01-24' of git://anongit.freedesktop.org/drm/drm-misc:
drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
drm/vc4: Flush the caches before the bin jobs, as well.
2018-01-25 12:28:15 +10:00
Dave Airlie
559f17bec5
Merge tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
...
Fixes for 4.16:
Fixes one Kconfig issue and a enable some panels to work properly.
There is also a fix of error code return in sun4i.
* tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc:
drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig
drm/panel: lvds: Handle the optional regulator case properly
drm/sun4i: Fix error code in sun4i_tcon_bind()
2018-01-25 11:42:25 +10:00
Dave Airlie
22bc72c807
Merge branch 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux into drm-next
...
A few more fixes for 4.16, nothing major.
A few more fixes for 4.16. This is on top of the pull request from
last week. Most notable change here is a fix to the link order for
the now separate from amdgpu GPU scheduler to fix crashes when the
modules are build into the kernel rather than as modules.
* 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux:
drm: fix gpu scheduler link order
drm/amd/display: Demote error print to debug print when ATOM impl missing
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
drm/amd/amdgpu: Add Polaris version check
drm/amdgpu: Reenable manual GPU reset from sysfs
drm/amdgpu: disable MMHUB power gating on raven
drm/ttm: Don't unreserve swapped BOs that were previously reserved
drm/ttm: Don't add swapped BOs to swap-LRU list
drm/amdgpu: only check for ECC on Vega10
drm/amd/powerplay: Fix smu_table_entry.handle type
drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count
drm/radeon: fill in rb backend map on evergreen/ni.
drm/amdgpu/gfx9: fix ngg enablement to clear gds reserved memory (v2)
drm/ttm: only free pages rather than update global memory count together
drm/amdgpu: fix CPU based VM updates
drm/amdgpu: fix typo in amdgpu_vce_validate_bo
drm/amdgpu: fix amdgpu_vm_pasid_fault_credit
drm/ttm: check the return value of register_shrinker
drm/radeon: fix sparse warning: Should it be static?
2018-01-25 11:40:54 +10:00
Christian König
87440329b0
drm: fix gpu scheduler link order
...
It should initialize before the drivers using it.
Signed-off-by: Christian König <christian.koenig@amd.com >
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104736
Reviewed-by: Mike Lothian <mike@fireburn.co.uk >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2018-01-24 15:49:04 -05:00
Harry Wentland
30305f58eb
drm/amd/display: Demote error print to debug print when ATOM impl missing
...
I assumed wrongfully that all relevant functions should be implemented.
Apparently this isn't the case. Demote the print to debug level for now.
Signed-off-by: Harry Wentland <harry.wentland@amd.com >
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com >
Acked-by: Harry Wentland <harry.wentland@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2018-01-24 15:47:25 -05:00
Sagar Arun Kamble
2fcf06805c
drm/i915/guc: Fix comments style in intel_guc_log.c
...
Use consistent multi-line comment style as per guideline.
v2: Reverted comments prefix update to kernel-doc comment. (Chris)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-5-git-send-email-sagar.a.kamble@intel.com
2018-01-24 19:44:07 +00:00
Sagar Arun Kamble
065dd5ad6c
drm/i915/guc: Update name and prototype of i915_guc_log_control
...
i915_guc_log_control is GuC interface and GuC APIs that are not user
facing should be named with "intel_guc" prefix hence we change name to
intel_guc_log_control. Also changed the parameter to intel_guc struct.
v2: Move log vma check to intel_guc_log_control (Michal)
Return -ENODEV when log isn't initialized. (Chris)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-4-git-send-email-sagar.a.kamble@intel.com
2018-01-24 19:44:06 +00:00
Sagar Arun Kamble
70deeaddc6
drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex
...
This patch fixes lockdep issue due to circular locking dependency of
struct_mutex, i_mutex_key, mmap_sem, relay_channels_mutex.
For GuC log relay channel we create debugfs file that requires i_mutex_key
lock and we are doing that under struct_mutex. So we introduced newer
dependency as:
&dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem
However, there is dependency from mmap_sem to struct_mutex. Hence we
separate the relay create/destroy operation from under struct_mutex.
Also added runtime check of relay buffer status.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
======================================================
WARNING: possible circular locking dependency detected
4.15.0-rc6-CI-Patchwork_7614+ #1 Not tainted
------------------------------------------------------
debugfs_test/1388 is trying to acquire lock:
(&dev->struct_mutex){+.+.}, at: [<00000000d5e1d915>] i915_mutex_lock_interruptible+0x47/0x130 [i915]
but task is already holding lock:
(&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&mm->mmap_sem){++++}:
_copy_to_user+0x1e/0x70
filldir+0x8c/0xf0
dcache_readdir+0xeb/0x160
iterate_dir+0xdc/0x140
SyS_getdents+0xa0/0x130
entry_SYSCALL_64_fastpath+0x1c/0x89
-> #2 (&sb->s_type->i_mutex_key#3){++++}:
start_creating+0x59/0x110
__debugfs_create_file+0x2e/0xe0
relay_create_buf_file+0x62/0x80
relay_late_setup_files+0x84/0x250
guc_log_late_setup+0x4f/0x110 [i915]
i915_guc_log_register+0x32/0x40 [i915]
i915_driver_load+0x7b6/0x1720 [i915]
i915_pci_probe+0x2e/0x90 [i915]
pci_device_probe+0x9c/0x120
driver_probe_device+0x2a3/0x480
__driver_attach+0xd9/0xe0
bus_for_each_dev+0x57/0x90
bus_add_driver+0x168/0x260
driver_register+0x52/0xc0
do_one_initcall+0x39/0x150
do_init_module+0x56/0x1ef
load_module+0x231c/0x2d70
SyS_finit_module+0xa5/0xe0
entry_SYSCALL_64_fastpath+0x1c/0x89
-> #1 (relay_channels_mutex){+.+.}:
relay_open+0x12c/0x2b0
intel_guc_log_runtime_create+0xab/0x230 [i915]
intel_guc_init+0x81/0x120 [i915]
intel_uc_init+0x29/0xa0 [i915]
i915_gem_init+0x182/0x530 [i915]
i915_driver_load+0xaa9/0x1720 [i915]
i915_pci_probe+0x2e/0x90 [i915]
pci_device_probe+0x9c/0x120
driver_probe_device+0x2a3/0x480
__driver_attach+0xd9/0xe0
bus_for_each_dev+0x57/0x90
bus_add_driver+0x168/0x260
driver_register+0x52/0xc0
do_one_initcall+0x39/0x150
do_init_module+0x56/0x1ef
load_module+0x231c/0x2d70
SyS_finit_module+0xa5/0xe0
entry_SYSCALL_64_fastpath+0x1c/0x89
-> #0 (&dev->struct_mutex){+.+.}:
__mutex_lock+0x81/0x9b0
i915_mutex_lock_interruptible+0x47/0x130 [i915]
i915_gem_fault+0x201/0x790 [i915]
__do_fault+0x15/0x70
__handle_mm_fault+0x677/0xdc0
handle_mm_fault+0x14f/0x2f0
__do_page_fault+0x2d1/0x560
page_fault+0x4c/0x60
other info that might help us debug this:
Chain exists of:
&dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&mm->mmap_sem);
lock(&sb->s_type->i_mutex_key#3);
lock(&mm->mmap_sem);
lock(&dev->struct_mutex);
*** DEADLOCK ***
1 lock held by debugfs_test/1388:
#0 : (&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560
stack backtrace:
CPU: 2 PID: 1388 Comm: debugfs_test Not tainted 4.15.0-rc6-CI-Patchwork_7614+ #1
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.10 09/29/2016
Call Trace:
dump_stack+0x5f/0x86
print_circular_bug.isra.18+0x1d0/0x2c0
__lock_acquire+0x14ae/0x1b60
? lock_acquire+0xaf/0x200
lock_acquire+0xaf/0x200
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
__mutex_lock+0x81/0x9b0
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
i915_mutex_lock_interruptible+0x47/0x130 [i915]
? __pm_runtime_resume+0x4f/0x80
i915_gem_fault+0x201/0x790 [i915]
__do_fault+0x15/0x70
? _raw_spin_unlock+0x29/0x40
__handle_mm_fault+0x677/0xdc0
handle_mm_fault+0x14f/0x2f0
__do_page_fault+0x2d1/0x560
? page_fault+0x36/0x60
page_fault+0x4c/0x60
v2: Added lock protection to guc->log.runtime.relay_chan (Chris)
Fixed locking inside guc_flush_logs uncovered by new lockdep.
v3: Locking guc_read_update_log_buffer entirely with relay_lock. (Chris)
Prepared intel_guc_init_early. Moved relay_lock inside relay_create
relay_destroy, relay_file_create, guc_read_update_log_buffer. (Michal)
Removed struct_mutex lock around guc_log_flush and removed usage
of guc_log_has_relay() from runtime_create path as it needs
struct_mutex lock.
v4: Handle NULL relay sub buffer pointer earlier in read_update_log_buffer
(Chris). Fixed comment suffix **/. (Michal)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104693
Testcase: igt/debugfs_test/read_all_entries # with enable_guc=1 and guc_log_level=1
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Marta Lofstedt <marta.lofstedt@intel.com >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-3-git-send-email-sagar.a.kamble@intel.com
2018-01-24 19:44:04 +00:00
Sagar Arun Kamble
1ed21cb414
drm/i915/guc: Enable interrupts before resuming GuC during runtime resume
...
GuC log streaming needs interrupts enabled prior to GuC resume but
runtime pm interrupt setup was happening post GuC resume. Fix it.
While at it, fix the unwinding of steps in the runtime suspend path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104695
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Michał Winiarski <michal.winiarski@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Marta Lofstedt <marta.lofstedt@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-2-git-send-email-sagar.a.kamble@intel.com
2018-01-24 19:44:03 +00:00
Sagar Arun Kamble
1be333d34e
drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts
...
Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.
v1-v2: old changelog
1: Add comment about need to synchronize flush work and log runtime
destroy
2: Moved patch earlier in the series and removed comment about future
work. (Tvrtko)
v3: Added assert_rpm_wakelock_held() to gen9_*_guc_interrupts. (Chris)
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-1-git-send-email-sagar.a.kamble@intel.com
2018-01-24 19:44:02 +00:00
Ville Syrjälä
16af25faae
drm/i915: Add a comment exlaining CCS hsub/vsub
...
Let's document why we claim hsub==8,vsub==16 for CCS.
v2: Replace my explanation with Jason's
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Ben Widawsky <ben@bwidawsk.net >
Cc: Jason Ekstrand <jason@jlekstrand.net >
Cc: Daniel Stone <daniels@collabora.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180119144152.17224-1-ville.syrjala@linux.intel.com
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net >
2018-01-24 20:13:53 +02:00
Ville Syrjälä
0519c102f5
drm/i915: Implement display w/a #1143
...
Apparently SKL/KBL/CFL need some manual help to get the
programmed HDMI vswing to stick. Implement the relevant
workaround (display w/a #1143 ).
Note that the relevant chicken bits live in a transcoder register
even though the bits affect a specific DDI port rather than a
specific transcoder. Hence we must pick the correct transcoder
register instance based on the port rather than based on the
cpu_transcoder.
Also note that for completeness I included support for DDI A/E
in the code even though we never have HDMI on those ports.
v2: CFL needs the w/a as well (Rodrigo and Art)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Art Runyan <arthur.j.runyan@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2018-01-24 20:09:29 +02:00
Ville Syrjälä
c19e1124e7
drm/i915: Use enum plane_id for frontbuffer tracking
...
Replace the ad-hoc plane indexing scheme used by the frontbuffer
tracking with enum plane_id.
The old video overlay not being part of the plane_id namespace
will just be given the high bit.
v2: Drop the unintended whitespace change (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180123183343.9181-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
2018-01-24 19:13:59 +02:00
Chris Wilson
84a1074920
drm/i915: Shrink the GEM kmem_caches upon idling
...
When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.
v3: Defer until an rcu grace period after we idle.
v4: Think about epoch wraparound and how likely that is.
v5: Use I915_EPOCH_INVALID magic.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180124113608.14909-2-chris@chris-wilson.co.uk
2018-01-24 15:28:37 +00:00
Chris Wilson
6f56103d7e
drm/i915: Track the number of times we have woken the GPU up
...
By counting the number of times we have woken up, we have a very simple
means of defining an epoch, which will come in handy if we want to
perform deferred tasks at the end of an epoch (i.e. while we are going
to sleep) without imposing on the next activity cycle.
v2: No reason to specify precise number of bits here.
v3: Take Tvrtko's advice and reserve 0 as an invalid epoch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180124113608.14909-1-chris@chris-wilson.co.uk
2018-01-24 15:28:05 +00:00
Chris Wilson
517aaffe0c
drm/i915/execlists: Inhibit context save/restore for the fake preempt context
...
We only use the preempt context to inject an idle point into execlists.
We never need to reference its logical state, so tell the GPU never to
load it or save it.
v2: BIT(2) for save-inhibit.
N.B. Daniele mentioned this bit mbz for ICL, and has been moved into the
submission process rather than the context image.
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Reviewed-by: Michel Thierry <michel.thierry@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180123210412.17653-1-chris@chris-wilson.co.uk
2018-01-24 09:40:15 +00:00
Michel Thierry
578f1ac689
drm/i915: Move LRC register offsets to a header file
...
Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.
v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and
intel_guc_reg.h (Chris)
v3: License notice shenanigans.
v4: Documentation/process/coding-style.rst is always right (Chris)
v5: Rebase.
Signed-off-by: Michel Thierry <michel.thierry@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Lucas De Marchi <lucas.demarchi@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180124004349.22126-2-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2018-01-24 09:22:55 +00:00
Michel Thierry
751d115302
drm/i915/lrc: Update reg_state macros to pass checkpatch
...
The macros we use to init the reg_state had the following issues reported
by checkpatch --strict.
Macro argument reuse 'reg_state' - possible side-effects
Macro argument reuse 'pos' - possible side-effects
Macro argument reuse 'ppgtt' - possible side-effects
spaces preferred around that '+' (ctx:VxV)
So fix these issues before they are moved to a new header file.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Michel Thierry <michel.thierry@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180124004349.22126-1-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2018-01-24 09:19:38 +00:00
Tvrtko Ursulin
8810bc5609
drm/i915/pmu: Fix sysfs exported counter config
...
We need to generate the event config value using the uAPI class and not
the driver internal one.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Fixes: 109ec55837
("drm/i915/pmu: Only enumerate available counters in sysfs")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180123134558.3222-1-tvrtko.ursulin@linux.intel.com
2018-01-24 08:51:11 +00:00
Rodrigo Vivi
c559c2a071
drm/i915/cnl: Fix aux selection for WA 1178
...
Current code always select _CNL_AUX_ANAOVRD1_B
register regardless the pw in use.
CNL_DISP_PW_AUX_B = 9
CNL_DISP_PW_AUX_C = 10
CNL_DISP_PW_AUX_D = 11
And for pick we want
B = 0
C = 1
D = 2
Fixes: ddd39e4b3f
("drm/i915/cnl: apply Display WA #1178 to fix type C dongles")
Cc: Lucas De Marchi <lucas.demarchi@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180123215245.24026-1-rodrigo.vivi@intel.com
2018-01-23 15:20:57 -08:00
Rodrigo Vivi
a8e6f3888b
drm/i915/cnp: Ignore VBT request for know invalid DDC pin.
...
Let's ignore VBT request if the pin is clearly wrong.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139
Cc: Kai Heng Feng <kai.heng.feng@canonical.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180123174050.4261-1-rodrigo.vivi@intel.com
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com >
2018-01-23 15:17:00 -08:00
Ville Syrjälä
c60c4af36d
drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Shawn Guo <shawnguo@kernel.org >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-15-ville.syrjala@linux.intel.com
Acked-by: Shawn Guo <shawnguo@kernel.org >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:59:14 +02:00
Ville Syrjälä
4f4becef17
drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com >
Cc: Sinclair Yeh <syeh@vmware.com >
Cc: Thomas Hellstrom <thellstrom@vmware.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-14-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:59:13 +02:00
Ville Syrjälä
a7d08ff19c
drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
v2: Rebase due to tegra_plane_state_add() relocating to plane.c
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Acked-by: Thierry Reding <treding@nvidia.com >
Reviewed-by: Thierry Reding <treding@nvidia.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-13-ville.syrjala@linux.intel.com
2018-01-23 17:58:56 +02:00
Ville Syrjälä
c2d6e243ff
drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Mark Yao <mark.yao@rock-chips.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-12-ville.syrjala@linux.intel.com
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:42:03 +02:00
Ville Syrjälä
07579ed153
drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Ben Skeggs <bskeggs@redhat.com >
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-11-ville.syrjala@linux.intel.com
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:55 +02:00
Ville Syrjälä
e489c7953f
drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Rob Clark <robdclark@gmail.com >
Cc: Archit Taneja <architt@codeaurora.org >
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-10-ville.syrjala@linux.intel.com
Reviewed-by: Archit Taneja <architt@codeaurora.org >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:52 +02:00
Ville Syrjälä
13eff9ae52
drm/meson: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Neil Armstrong <narmstrong@baylibre.com >
Cc: linux-amlogic@lists.infradead.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-9-ville.syrjala@linux.intel.com
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:49 +02:00
Ville Syrjälä
bd6120dbcb
drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: CK Hu <ck.hu@mediatek.com >
Cc: Philipp Zabel <p.zabel@pengutronix.de >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-8-ville.syrjala@linux.intel.com
Acked-by: Philipp Zabel <p.zabel@pengutronix.de >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:45 +02:00
Ville Syrjälä
06edb0a0cf
drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Philipp Zabel <p.zabel@pengutronix.de >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-7-ville.syrjala@linux.intel.com
Acked-by: Philipp Zabel <p.zabel@pengutronix.de >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:42 +02:00
Ville Syrjälä
bb4dd71a75
drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Noralf Trønnes <noralf@tronnes.org >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-6-ville.syrjala@linux.intel.com
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:40 +02:00
Ville Syrjälä
de9f422e30
drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Liviu Dudau <liviu.dudau@arm.com >
Cc: Brian Starkey <brian.starkey@arm.com >
Cc: Mali DP Maintainers <malidp@foss.arm.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-5-ville.syrjala@linux.intel.com
Acked-by: Liviu Dudau <liviu.dudau@arm.com >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:36 +02:00
Ville Syrjälä
872d20dfbd
drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Liviu Dudau <liviu.dudau@arm.com >
Cc: Brian Starkey <brian.starkey@arm.com >
Cc: Mali DP Maintainers <malidp@foss.arm.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-4-ville.syrjala@linux.intel.com
Acked-by: Liviu Dudau <liviu.dudau@arm.com >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:32 +02:00
Ville Syrjälä
a2936e3d9a
drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle
...
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes since pipe_src_w/h are already filled via
drm_mode_get_hv_timing().
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-3-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:29 +02:00
Ville Syrjälä
0574bd882e
drm/i915: Reject odd pipe source width with double wide/dual link
...
In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay
we must not adjust pipe_src_w to accommodate double wide/dual link.
Instead just reject the mode outright.
This will allows us to rely on crtc_state->mode for plane clipping.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Reviewed-by: Thierry Reding <treding@nvidia.com >
2018-01-23 17:41:24 +02:00
Alex Deucher
458d876eb8
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
...
We only support vga_switcheroo and runtime pm on PX/HG systems
so forcing runpm to 1 doesn't do anything useful anyway.
Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so
that the cleanup path is correct as well. This mirrors what
radeon does as well.
v2: rework the patch originally sent by Lukas (Alex)
Acked-by: Lukas Wunner <lukas@wunner.de >
Reported-by: Lukas Wunner <lukas@wunner.de >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Lukas Wunner <lukas@wunner.de > (v1)
Cc: stable@vger.kernel.org
2018-01-23 10:24:41 -05:00
Sean Paul
a63b8e7958
drm/sun4i: Fix build warnings in sunxi_engine.h
...
Fixes the following build warnings:
In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0,
from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.h:13,
from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.c:12:
../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
struct drm_crtc_state *old_state);
^~~~~~~~~~~~~~
../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
struct drm_crtc_state *state);
^~~~~~~~~~~~~~
In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0,
from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.h:12,
from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.c:12:
../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
struct drm_crtc_state *old_state);
^~~~~~~~~~~~~~
../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
struct drm_crtc_state *state);
^~~~~~~~~~~~~~
Fixes: 6b8562c86e
("drm/sun4i: engine: Create an atomic_begin
callback")
Fixes: 656e5f6549
("drm/sun4i: engine: Add a custom crtc
atomic_check")
Cc: Chen-Yu Tsai <wens@csie.org >
Cc: Neil Armstrong <narmstrong@baylibre.com >
Cc: Maxime Ripard <maxime.ripard@free-electrons.com >
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Sean Paul <seanpaul@chromium.org >
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180122174306.231609-1-seanpaul@chromium.org
2018-01-23 10:45:01 +01:00
James Zhu
dead73d791
drm/amd/amdgpu: Add Polaris version check
...
Add Polaris version check if firmware support UVD encode
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Reviewed-by: Christian König <christian.koenig@amd.com >
Signed-off-by: James Zhu <James.Zhu@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Cc: stable@vger.kernel.org
2018-01-23 01:43:15 -05:00
Andrey Grodzovsky
54bc1398cc
drm/amdgpu: Reenable manual GPU reset from sysfs
...
Otherwise it keeps rejecting the reset.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com >
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2018-01-23 01:42:48 -05:00
Chris Wilson
bb5db7e160
drm/i915/execlists: Skip forcewake for ELSP submission
...
Now that we can read the CSB from the HWSP, we may avoid having to
perform mmio reads entirely and so forgo the rigmarole of the forcewake
dance.
v2: Include forcewake hint for GEM_TRACE readback of mmio. If we don't
hold fw ourselves, the reads may return garbage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180122100714.15137-1-chris@chris-wilson.co.uk
2018-01-22 18:27:04 +00:00
Chris Wilson
c1beabcf14
drm/i915: Increase render/media power gating hysteresis for gen9+
...
On gen9+, after an idle period the HW will disable the entire power well
to conserve power (by preventing current leakage). It takes around a 100
microseconds to bring the power well back online afterwards. With the
current hysteresis value of 25us (really 25 * 1280ns), we do not have
sufficient time to respond to an interrupt and schedule the next execution
before the HW powers itself down. (At present, we prevent this by
grabbing the forcewake for prolonged periods of time, but that overkill
fixed in the next patch.) The minimum we want to set the power gating
hysteresis to is the length of time it takes us to service the GPU, which
across a broad spectrum of machines is about 250us.
(Note this also brings guc latency into the same ballpark as execlists.)
v2: Include some notes on where I plucked the numbers from.
Testcase: igt/gem_exec_nop/sequential
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180122135541.32222-1-chris@chris-wilson.co.uk
2018-01-22 18:27:04 +00:00
Sean Paul
4ac511165b
drm/panel: panasonic-vvx10f034n00: More return value fixes
...
A couple more return value fixes which Philippe brought up during our
previous review.
Suggested-by: Philippe CORNU <philippe.cornu@st.com >
Reviewed-by: Philippe Cornu <philippe.cornu@st.com >
Signed-off-by: Sean Paul <seanpaul@chromium.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20180117213751.54668-1-seanpaul@chromium.org
2018-01-22 12:32:37 -05:00
Tvrtko Ursulin
10bde236ef
drm/i915: Per-engine scratch VMA is mandatory
...
We fail engine initialization if the scratch VMA cannot be created so
there is no point in error handle it later. If the initialization ordering
gets messed up, we can explode during development just as well.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Michel Thierry <michel.thierry@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180119100005.9072-2-tvrtko.ursulin@linux.intel.com
2018-01-22 17:15:31 +00:00