summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2017-01-09drm/i915: Update DRIVER_DATE to 20170109Daniel Vetter1-2/+2
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-01-09drm/i915/gvt/kvmgt: return meaningful error for vgpu creating failureJike Song1-4/+10
The vgpu_create() routine we called returns meaningful errors to indicate failures, so we'd better to pass it to our caller, the mdev framework, whereby the sysfs is able to tell userspace what happened. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: cleanup opregion memory allocation codeJike Song2-6/+5
According to the spec, ACPI OpRegion must be placed at a physical address below 4G. That is, for a vGPU it must be associated with a GPA below 4G, but on host side, it doesn't matter where the backing pages actually are. So when allocating pages from host, the GFP_DMA32 flag is unnecessary. Also the allocation is from a sleepable context, so GFP_ATOMIC is also unnecessary. This patch also removes INTEL_GVT_OPREGION_PORDER and use get_order() instead. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: destroy the allocated idr on vgpu creating failuresJike Song1-1/+3
Once idr_alloc gets called data is allocated within the idr list, if any error occurs afterwards, we should undo that by idr_remove on the error path. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: init/destroy vgpu_idr properlyJike Song1-1/+7
An idr should be initialized before use and destroyed afterwards. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: dec vgpu->running_workload_num after the workload is really doneChangbin Du1-5/+5
The vgpu->running_workload_num is used to determine whether a vgpu has any workload running or not. So we should make sure the workload is really done before we dec running_workload_num. Function complete_current_workload is not the right place to do it, since this function is still processing the workload. This patch move the dec op afterward. v2: move dec op before wake_up(&scheduler->workload_complete_wq) (Min He) Signed-off-by: Changbin Du <changbin.du@intel.com> Reviewed-by: Min He <min.he@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: fix use after free for workloadChangbin Du1-2/+2
In the function workload_thread(), we invoke complete_current_workload() to cleanup the just processed workload (workload will be freed there). So we cannot access workload->req after that. This patch move complete_current_workload() afterward. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: remove duplicated definitionZhenyu Wang1-7/+0
Remove duplicated definition for resource size in aperture_gm.c which are already defined in gvt.h. Need only one to take effect. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: adjust high memory size for default vGPU typeZhenyu Wang1-2/+2
Previous high mem size initialized for vGPU type was too small which caused failure for some VMs. This trys to take minimal value of 384MB for each VM and enlarge default high mem size to make guest driver happy. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: print correct value for untracked mmioPei Zhang1-15/+16
In function intel_vgpu_emulate_mmio_read, the untracked mmio register is dumped through kernel log, but the register value is not correct. This patch fixes this issue. V2: fix the fromat warning from checkpatch.pl. Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: always use readq and writeqChangbin Du1-13/+2
The readq and writeq are already offered by drm_os_linux.h. So we can use them directly whithout dectecting their presence. This patch removed the duplicated code. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: fix return value in mul_force_wake_writeChangbin Du1-1/+1
All mmio handlers should return a negetive value for failure, not 1. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: fix error handing of tlb_control emulationChangbin Du1-4/+2
Return ealier for a invalid access, else it would false set tlb flag for RCS. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09drm/i915/gvt: verify functions types in new_mmio_info()Nicolas Iooss1-2/+3
The current prototype of new_mmio_info() uses void* for parameters read and write, which are functions with precise calling conventions (argument types and return type). Write down these conventions in new_mmio_info() definition. This has been reported by the following warnings when clang is used to build the kernel: drivers/gpu/drm/i915/gvt/handlers.c:124:21: error: pointer type mismatch ('void *' and 'int (*)(struct intel_vgpu *, unsigned int, void *, unsigned int)') [-Werror,-Wpointer-type-mismatch] info->read = read ? read : intel_vgpu_default_mmio_read; ^ ~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gvt/handlers.c:125:23: error: pointer type mismatch ('void *' and 'int (*)(struct intel_vgpu *, unsigned int, void *, unsigned int)') [-Werror,-Wpointer-type-mismatch] info->write = write ? write : intel_vgpu_default_mmio_write; ^ ~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This allows the compiler to detect that sbi_ctl_mmio_write() returns a "bool" value instead of an expected "int" one. Fix this. Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09Merge tag 'drm-misc-next-2016-12-30' of ↵Dave Airlie13-146/+307
git://anongit.freedesktop.org/git/drm-misc into drm-next First -misc pull for 4.11: - drm_mm rework + lots of selftests (Chris Wilson) - new connector_list locking+iterators - plenty of kerneldoc updates - format handling rework from Ville - atomic helper changes from Maarten for better plane corner-case handling in drivers, plus the i915 legacy cursor patch that needs this - bridge cleanup from Laurent - plus plenty of small stuff all over - also contains a merge of the 4.10 docs tree so that we could apply the dma-buf kerneldoc patches It's a lot more than usual, but due to the merge window blackout it also covers about 4 weeks, so all in line again on a per-week basis. The more annoying part with no pull request for 4 weeks is managing cross-tree work. The -intel pull request I'll follow up with does conflict quite a bit with -misc here. Longer-term (if drm-misc keeps growing) a drm-next-queued to accept pull request for the next merge window during this time might be useful. I'd also like to backmerge -rc2+this into drm-intel next week, we have quite a pile of patches waiting for the stuff in here. * tag 'drm-misc-next-2016-12-30' of git://anongit.freedesktop.org/git/drm-misc: (126 commits) drm: Add kerneldoc markup for new @scan parameters in drm_mm drm/mm: Document locking rules drm: Use drm_mm_insert_node_in_range_generic() for everyone drm: Apply range restriction after color adjustment when allocation drm: Wrap drm_mm_node.hole_follows drm: Apply tight eviction scanning to color_adjust drm: Simplify drm_mm scan-list manipulation drm: Optimise power-of-two alignments in drm_mm_scan_add_block() drm: Compute tight evictions for drm_mm_scan drm: Fix application of color vs range restriction when scanning drm_mm drm: Unconditionally do the range check in drm_mm_scan_add_block() drm: Rename prev_node to hole in drm_mm_scan_add_block() drm: Fix O= out-of-tree builds for selftests drm: Extract struct drm_mm_scan from struct drm_mm drm: Add asserts to catch overflow in drm_mm_init() and drm_mm_init_scan() drm: Simplify drm_mm_clean() drm: Detect overflow in drm_mm_reserve_node() drm: Fix kerneldoc for drm_mm_scan_remove_block() drm: Promote drm_mm alignment to u64 drm: kselftest for drm_mm and restricted color eviction ...
2017-01-06Merge tag 'vfio-v4.10-rc3' of git://github.com/awilliam/linux-vfioLinus Torvalds1-12/+12
Pull VFIO fixes from Alex Williamson: - Add mtty sample driver properly into build system (Alex Williamson) - Restore type1 mapping performance after mdev (Alex Williamson) - Fix mdev device race (Alex Williamson) - Cleanups to the mdev ABI used by vendor drivers (Alex Williamson) - Build fix for old compilers (Arnd Bergmann) - Fix sample driver error path (Dan Carpenter) - Handle pci_iomap() error (Arvind Yadav) - Fix mdev ioctl return type (Paul Gortmaker) * tag 'vfio-v4.10-rc3' of git://github.com/awilliam/linux-vfio: vfio-mdev: fix non-standard ioctl return val causing i386 build fail vfio-pci: Handle error from pci_iomap vfio-mdev: fix some error codes in the sample code vfio-pci: use 32-bit comparisons for register address for gcc-4.5 vfio-mdev: Make mdev_device private and abstract interfaces vfio-mdev: Make mdev_parent private vfio-mdev: de-polute the namespace, rename parent_device & parent_ops vfio-mdev: Fix remove race vfio/type1: Restore mapping performance with mdev support vfio-mdev: Fix mtty sample driver building
2017-01-06Merge branch 'stable/for-linus-4.10' of ↵Linus Torvalds1-10/+1
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb Pull swiotlb fixes from Konrad Rzeszutek Wilk: "This has one fix to make i915 work when using Xen SWIOTLB, and a feature from Geert to aid in debugging of devices that can't do DMA outside the 32-bit address space. The feature from Geert is on top of v4.10 merge window commit (specifically you pulling my previous branch), as his changes were dependent on the Documentation/ movement patches. I figured it would just easier than me trying than to cherry-pick the Documentation patches to satisfy git. The patches have been soaking since 12/20, albeit I updated the last patch due to linux-next catching an compiler error and adding an Tested-and-Reported-by tag" * 'stable/for-linus-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb: swiotlb: Export swiotlb_max_segment to users swiotlb: Add swiotlb=noforce debug option swiotlb: Convert swiotlb_force from int to enum x86, swiotlb: Simplify pci_swiotlb_detect_override()
2017-01-06swiotlb: Export swiotlb_max_segment to usersKonrad Rzeszutek Wilk1-10/+1
So they can figure out what is the optimal number of pages that can be contingously stitched together without fear of bounce buffer. We also expose an mechanism for sub-users of SWIOTLB API, such as Xen-SWIOTLB to set the max segment value. And lastly if swiotlb=force is set (which mandates we bounce buffer everything) we set max_segment so at least we can bounce buffer one 4K page instead of a giant 512KB one for which we may not have space. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reported-and-Tested-by: Juergen Gross <jgross@suse.com>
2017-01-06drm/i915: Drain freed objects for mmap space exhaustionChris Wilson1-13/+11
As we now use a deferred free queue for objects, simply retiring the active objects is not enough to immediately free them and recover their mmap space - we must now also drain the freed object list. Fixes: fbbd37b36fa5 ("drm/i915: Move object release to a freelist + worker" Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170106152240.5793-3-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-01-06drm/i915: Purge loose pages if we run out of DMA remap spaceChris Wilson1-4/+18
If the DMA remap fails, one cause can be that we have too many objects pinned in a small remapping table, such as swiotlb. (DMA remapping does not trigger the shrinker by itself on its normal failure paths.) So try purging all other objects (using i915_gem_shrink_all(), sparing our own pages as we have yet to assign them to the obj->pages) and try again. If there are no pages to reclaim (and consequently no pages to unmap), the shrinker will report 0 and we fail with -ENOSPC as before. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170106152240.5793-2-chris@chris-wilson.co.uk
2017-01-06drm/i915: Fix phys pwrite for struct_mutex-less operationChris Wilson1-30/+4
Since commit fe115628d567 ("drm/i915: Implement pwrite without struct-mutex") the lowlevel pwrite calls are now called without the protection of struct_mutex, but pwrite_phys was still asserting that it held the struct_mutex and later tried to drop and relock it. Fixes: fe115628d567 ("drm/i915: Implement pwrite without struct-mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170106152240.5793-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-01-06drm/i915: Simplify testing for am-I-the-kernel-context?Chris Wilson5-5/+21
The kernel context (dev_priv->kernel_context) is unique in that it is not associated with any user filp - it is the only one with ctx->file_priv == NULL. This is a simpler test than comparing it against dev_priv->kernel_context which involves some pointer dancing. In checking that this is true, we notice that the gvt context is allocating itself a i915_hw_ppgtt it doesn't use and not flagging that its file_priv should be invalid. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170106152013.24684-5-chris@chris-wilson.co.uk
2017-01-06drm/i915: Use range_overflows()Chris Wilson3-4/+8
Replace a few more open-coded overflow checks with the macro. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170106152013.24684-4-chris@chris-wilson.co.uk
2017-01-06drm/i915: Use fixed-sized types for stolenChris Wilson3-19/+22
Stolen memory is a hardware resource of known size, so use an accurate fixed integer type rather than the ambiguous variable size_t. This was motivated by the next patch spotting inconsistencies in our types. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170106152013.24684-3-chris@chris-wilson.co.uk
2017-01-06drm/i915: Use phys_addr_t for the address of stolen memoryChris Wilson2-24/+27
Though we know the hw is limited to keeping stolen memory inside the first 4GiB, it is clearer to the reader that we are handling physical address if we use phys_addr_t to refer to the base of stolen memory. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170106152013.24684-2-chris@chris-wilson.co.uk
2017-01-06drm/i915: Consolidate checks for memcpy-from-wc supportChris Wilson4-3/+19
In order to silence sparse: ../drivers/gpu/drm/i915/i915_gpu_error.c:200:39: warning: Using plain integer as NULL pointer add a helper to check whether we have sse4.1 and that the desired alignment is valid for acceleration. v2: Explain the macros and split the two use cases between i915_has_memcpy_from_wc() and i915_can_memcpy_from_wc(). Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170106152013.24684-1-chris@chris-wilson.co.uk
2017-01-06drm/i915: Only skip requests once a context is bannedChris Wilson1-7/+12
If we skip before banning, we have an inconsistent interface between execbuf still queueing valid request but those requests already queued being cancelled. If we only cancel the pending requests once we stop accepting new requests, the user interface is more consistent. Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: <stable@vger.kernel.org> # v4.9+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170105170059.344-1-chris@chris-wilson.co.uk
2017-01-06drm/i915: Move a few more utility macros to i915_utils.hChris Wilson2-20/+20
Now that we have split out a header file for simple macros (that maybe we can promote into a core header), move a few macros across from i915_drv.h Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170105164148.26875-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-01-05drm/i915: Clear ret before unbinding in i915_gem_evict_something()Chris Wilson1-0/+1
Missed when rebasing patches, I failed to set ret to zero before starting the unbind loop (which depends upon ret being zero). Reported-by: Matthew Auld <matthew.william.auld@gmail.com> Fixes: 9332f3b1b99a ("drm/i915: Combine loops within i915_gem_evict_something") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170105155940.10033-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Cc: <stable@vger.kernel.org> # v4.9+
2017-01-05drm/i915/guc: Exclude the upper end of the Global GTT for the GuCChris Wilson3-0/+14
The GuC uses a special mapping for the upper end of the Global GTT, similar to the way it uses a special mapping for the lower end, so exclude it from our drm_mm to prevent us using it. v2: Rename to reflect that it is unmappable similar to the region at the bottom of the GGTT, and couple it into the assertion that we don't feed unmappable addresses to the GuC. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170105153023.30575-5-chris@chris-wilson.co.uk
2017-01-05drm/i915: Move a few utility macros into a separate headerChris Wilson3-16/+45
In order to defeat some circular dependencies between headers to allow use of e.g. range_overflows() in a header, move the simple independent macros into their own header. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170105153023.30575-4-chris@chris-wilson.co.uk
2017-01-05drm/i915/execlists: Reorder execlists register enablingChris Wilson1-14/+4
Empirically we restart following a GPU reset more successfully if we call lrc_init_hws() (which contains a posting read) last. (The failure mode that was observed was that breadcrumb writes into the HWS from the recovered requests went astray leading to the context-switch maintaining forward progress, but the requests not being retired/completed.) For clarity, lrc_init_hws() is inlined (and the unused function then removed). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170105153023.30575-3-chris@chris-wilson.co.uk
2017-01-05drm/i915: Assert that we do create the deferred contextChris Wilson1-0/+1
In order to convince static analyzers that the allocation function returns an error or sets ce->state, assert that it is set afterwards. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170105153023.30575-2-chris@chris-wilson.co.uk
2017-01-05drm/i915: Assert all timeline requests are gone before finiChris Wilson1-4/+12
During i915_gem_timeline_fini(), assert that all the timeline's request are completed and removed from the timeline. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170105153023.30575-1-chris@chris-wilson.co.uk
2017-01-04drm/i915: Revoke fenced GTT mmapings across GPU resetChris Wilson4-3/+35
The fence registers are clobbered by a GPU reset. If there is concurrent user access to a fenced region via a GTT mmaping, the access will not be fenced during the reset (until we restore the fences afterwards). In order to prevent invalid access during the reset, before we clobber the fences first we must invalidate the GTT mmapings. Access to the mmap will then be forced to fault in the page, and in handling the fault, i915_gem_fault() will take the struct_mutex and wait upon the reset to complete. v2: Fix up commentary. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99274 Testcase: igt/gem_mmap_gtt/hang Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170104145110.1486-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-01-04drm/i915: enable FBC on gen9+ tooPaulo Zanoni1-1/+1
Gen9+ platforms have been seeing a lot of screen flickerings and underruns, so I never felt comfortable in enabling FBC on these platforms since I didn't want to throw yet another feature on top of the already complex problem. We now have code that automatically disables FBC if we ever get an underrun, and the screen flickerings seem to be mostly gone, so it may be a good time to try to finally enable FBC by default on the newer platforms. Besides, BDW FBC has been working fine over the year, which gives me a little more confidence now. For a little more information, please refer to commit a98ee79317b4 ("drm/i915/fbc: enable FBC by default on HSW and BDW"). v2: Enable not only on SKL, but for everything new (Daniel). v3: Rebase after the intel_sanitize_fbc_option() change. v4: New rebase after 8 months, drop expired R-B tags. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1482495839-27041-1-git-send-email-paulo.r.zanoni@intel.com
2017-01-04drm/i915: actually drive the BDW reserved IDsPaulo Zanoni1-0/+1
Back in 2014, commit fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI IDs.") added the reserved PCI IDs in order to try to make sure we had working drivers in case we ever released products using these IDs (since we had instances of this type of problem in the past). The problem is that the patch only touched the macros used by early-quirks.c and by the user space components that rely on i915_pciids.h, it didn't touch the macros used by i915_pci.c. So we correctly handled the stolen memory for these theoretical IDs, but we didn't actually drive the devices from i915.ko. So this patch fixes the original commit by actually making i915.ko drive these IDs, which was the goal. There's no information on what would be the GT count on these IDs, so we just go with the safer intel_broadwell_info, at the risk of ignoring a possibly inexistent BSD2_RING. I did some checking, and it seems that these IDs are driven by intel-gpu-tools, xf86-video-intel and libdrm (since they contain old copies of i915_pciids.h), but they are not checked by mesa. The alternative to this patch would be to just assume we're actually never going to use these IDs, and then remove them from our ID lists and make sure our user space components sync the latest i915_pciids.h copy. I'm fine with either approaches, as long as we make sure that every component tries to drive the same list of PCI IDs. Fixes: fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI IDs.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-3-git-send-email-paulo.r.zanoni@intel.com
2017-01-04Merge tag 'drm-misc-next-2016-12-30' of ↵Daniel Vetter13-133/+296
git://anongit.freedesktop.org/git/drm-misc into drm-intel-next-queued Directly merge drm-misc into drm-intel since Dave is on vacation and we need the various drm-misc patches (fb format rework, drm mm fixes, selftest framework and others). Also pulled back -rc2 in first to resync with drm-intel-fixes and make sure I can reuse the exact rerere solutions from drm-tip for safety, and because I'm lazy. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-01-04Merge tag 'v4.10-rc2' into drm-intel-next-queuedDaniel Vetter12-95/+945
Backmerge Linux 4.10-rc2 to resync with our -fixes cherry-picks. I've done the backmerge directly because Dave is on vacation. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-01-04drm/i915: Update comment that sets I915_MODE_FLAG_INHERITEDDaniel Vetter1-11/+3
The code was moved, but the comment not updated. It confused me. Fixes: 7f4c62840cc4 ("drm/i915: Assign hwmode after encoder state readout") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161219082423.27798-6-daniel.vetter@ffwll.ch
2017-01-03drm/i915: Initialize num_scalers for skl and glk tooAnder Conselvan de Oliveira1-3/+6
After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization to runtime init"), scalers are not initialized properly for skl and glk since num_scalers is left as 0 for those platforms. Fixes: 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization to runtime init") Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1483365281-10569-1-git-send-email-ander.conselvan.de.oliveira@intel.com
2017-01-03drm/i915: Update comment in vlv_set_rps_idle()Chris Wilson1-2/+12
Ville explained that the wakelock was being acquired during set-idle in order to flush the voltage change from the punit. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170102152845.32352-1-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-01-03drm/i915/guc: Make intel_guc_recv static.Michal Wajdeczko2-4/+5
This function is only used by intel_guc_send() and it doesn't need to be exposed outside of intel_uc.o file. Also when defined as static, compiler will generate smaller code. Additionally let it take guc param instead dev_priv to match function name. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161220115531.76120-1-michal.wajdeczko@intel.com
2017-01-03drm/i915: Prevent timeline updates whilst performing resetChris Wilson1-1/+9
As the fence may be signaled concurrently from an interrupt on another device, it is possible for the list of requests on the timeline to be modified as we walk it. Take both (the context's timeline and the global timeline) locks to prevent such modifications. Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-10-chris@chris-wilson.co.uk (cherry picked from commit 00c25e3f40083a6d5f1111955baccd287ee49258) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-01-03drm/i915: Silence allocation failure during sg_trim()Chris Wilson1-1/+1
As trimming the sg table is merely an optimisation that gracefully fails if we cannot allocate a new table, we do not need to report the failure either. Fixes: 0c40ce130e38 ("drm/i915: Trim the object sg table") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-4-chris@chris-wilson.co.uk (cherry picked from commit 8bfc478fa455b4908f745df368355b415460c60e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-01-03drm/i915: Don't clflush before release phys objectChris Wilson1-4/+6
When we teardown the backing storage for the phys object, we copy from the coherent contiguous block back to the shmemfs object, clflushing as we go. Trying to clflush the invalid sg beforehand just oops and would be redundant (due to it already being coherent, and clflushed afterwards). Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-3-chris@chris-wilson.co.uk (cherry picked from commit e5facdf9644f4490520e0489a0252e8feaba3744) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-01-03drm/i915: Fix oops in overlay due to frontbuffer trackingVille Syrjälä1-2/+2
The vma will be NULL if the overlay was previously off, so dereferencing it will oops. Check for NULL before doing that. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: 9b3b7841b86d ("drm/i915/overlay: Use VMA as the primary tracker for images") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481131693-27993-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 4a15cdbbc55463e55a7cdcf33f84ccc742ca9c29) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-01-03drm/i915: Fix oopses in the overlay code due to i915_gem_active stuffVille Syrjälä2-1/+21
The i915_gem_active stuff doesn't like a NULL ->retire hook, but the overlay code can set it to NULL. That obviously ends up oopsing. Fix it by introducing a new helper to assign the retirement callback that will switch out the NULL function pointer with i915_gem_retire_noop. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20161207175647.10018-1-chris@chris-wilson.co.uk (cherry picked from commit ecd9caa0522db5a6b03ac8858c42067ef9d8323b) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-01-03drm/i915: Initialize overlay->last_flip properlyVille Syrjälä1-0/+2
Initialize overlay->last_flip properly instead of leaving it zeroed. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161221144547.27319-1-ville.syrjala@linux.intel.com (cherry picked from commit 330afdb1df0f3fb48583105493a8f4f8d9e3af36) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-01-03drm/i915: Move the min_pixclk[] handling to the end of readoutVille Syrjälä1-16/+16
Trying to determine the pixel rate of the pipe can't be done until we know the clock, which means it can't be done until the encoder .get_config() hooks have been called. So let's move the min_pixclk[] stuff to the end of intel_modeset_readout_hw_state() when we actually have gathered all the required infromation. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 565602d7501a ("drm/i915: Do not acquire crtc state to check clock during modeset, v4.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161220153902.15621-1-ville.syrjala@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit aca1ebf491518910df156f3dab6a66306bb52e28) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-29 16:25:18 +0300