summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Increase AMDGPU_MAX_UVD_INSTANCES to 3polaris-working-raptor-devraptor-dma-dev-4.18-preTimothy Pearson2018-06-231-1/+1
| | | | | | | | | | | | | amdgpu_fence_driver_start_ring() attempts to access UVD instance 2 during setup, while the existing UVD instance count only allows instances 0 and 1. Increase AMDGPU_MAX_UVD_INSTANCES by one to avoid the invalid array access. Caught by UBSAN. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
* drm/amdgpu: GPU vs CPU page size fixes in amdgpu_vm_bo_split_mappingMichel Dänzer2018-06-231-3/+5
| | | | | start / last / max_entries are numbers of GPU pages, pfn / count are numbers of CPU pages.
* Fix undefined behaviour from signed integer overflowTimothy Pearson2018-06-231-1/+1
| | | | | | Caught by UBSAN Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
* powerpc/powernv/pci: Don't use the lower 4G TCEs in pseudo-DMA modeTimothy Pearson2018-06-231-1/+7
| | | | | | | | Four TCEs are reserved for legacy 32-bit DMA mappings in psuedo DMA mode. Mark these with an invalid address to avoid their use by the TCE cache mapper. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
* powerpc/powernv/pci: Invalidate TCE cache after DMA map setupTimothy Pearson2018-06-231-2/+1
| | | | | | | | Per the IODA2, TCEs must be invalidated after their settings have been changed. Invalidate the cache after the address is changed during TCE allocation when using pseudo DMA. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
* powerpc/powernv/pci: Export pnv_pci_ioda2_tce_invalidate_peTimothy Pearson2018-06-232-1/+2
| | | | | | | | Pseudo DMA support requires a method to invalidate the TCE cache Export pnv_pci_ioda2_tce_invalidate_pe for use by the pseudo DMA mapper. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
* powerpc/powernv/pci: Safety fixes for pseudobypass TCE allocationRussell Currey2018-06-231-2/+4
| | | | Signed-off-by: Russell Currey <ruscur@russell.cc>
* powerpc/powernv/pci: Track DMA and TCE tables in debugfsRussell Currey2018-06-221-0/+43
| | | | | | | | | | | Add a new debugfs entry to trigger dumping out the tracking table and TCEs for a given PE, for example PE 0x4 of PHB 2: echo 0x4 > /sys/kernel/debug/powerpc/PCI0002/sketchy This will result in the table being dumped out in dmesg. Signed-off-by: Russell Currey <ruscur@russell.cc>
* powerpc/powernv: DMA operations for discontiguous allocationRussell Currey2018-06-225-50/+381
| | | | | | | | | | | | | | | | | | | | | | | | | | | Cognitive DMA is a new set of DMA operations that solve some issues for devices that want to address more than 32 bits but can't address the 59 bits required to enable direct DMA. The previous implementation for POWER8/PHB3 worked around this by configuring a bypass from the default 32-bit address space into 64-bit address space. This approach does not work for POWER9/PHB4 because regions of memory are discontiguous and many devices will be unable to address memory beyond the first node. Instead, implement a new set of DMA operations that allocate TCEs as DMA mappings are requested so that all memory is addressable even when a one-to-one mapping between real addresses and DMA addresses isn't possible. These TCEs are the maximum size available on the platform, which is 256M on PHB3 and 1G on PHB4. Devices can now map any region of memory up to the maximum amount they can address according to the DMA mask set, in chunks of the largest available TCE size. This implementation replaces the need for the existing PHB3 solution and should be compatible with future PHB versions. Signed-off-by: Russell Currey <ruscur@russell.cc>
* powerpc/powernv/pci: Track largest available TCE order per PHBRussell Currey2018-06-222-0/+19
| | | | | | | | | | | | | Knowing the largest possible TCE size of a PHB is useful, so get it out of the device tree. This relies on the property being added in OPAL. It is assumed that any PHB4 or later machine would be running firmware that implemented this property, and otherwise assumed to be PHB3, which has a maximum TCE order of 28 bits or 256MB TCEs. This is used later in the series. Signed-off-by: Russell Currey <ruscur@russell.cc>
* Merge tag 'drm-fixes-2018-06-22' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2018-06-2231-337/+408
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm fixes from Dave Airlie: "Just run of the mill fixes, core: - regression fix in device unplug qxl: - regression fix for might sleep in cursor handling nouveau: - regression fix in multi-screen cursor handling amdgpu: - switch off DC by default on Kaveri and older - some minor fixes i915: - some GEM regression fixes - doublescan mode fixes sun4i: - revert fix for a regression sii8620 bridge: - misc fixes" * tag 'drm-fixes-2018-06-22' of git://anongit.freedesktop.org/drm/drm: (28 commits) drm/bridge/sii8620: fix display of packed pixel modes in MHL2 drm/amdgpu: Make amdgpu_vram_mgr_bo_invisible_size always accurate drm/amdgpu: Refactor amdgpu_vram_mgr_bo_invisible_size helper drm/amdgpu: Update pin_size values before unpinning BO drm/amdgpu:All UVD instances share one idle_work handle drm/amdgpu: Don't default to DC support for Kaveri and older drm/amdgpu: Use kvmalloc_array for allocating VRAM manager nodes array drm/amd/pp: Fix uninitialized variable drm/i915: Enable provoking vertex fix on Gen9 systems. drm/i915: Fix context ban and hang accounting for client drm/i915: Turn off g4x DP port in .post_disable() drm/i915: Disallow interlaced modes on g4x DP outputs drm/i915: Fix PIPESTAT irq ack on i965/g4x drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI drm/i915/execlists: Avoid putting the error pointer drm/i915: Apply batch location restrictions before pinning drm/nouveau/kms/nv50-: cursors always use core channel vram ctxdma Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE" drm/atmel-hlcdc: check stride values in the first plane drm/bridge/sii8620: fix HDMI cable connection to dongle ...
| * Merge tag 'drm-misc-fixes-2018-06-21' of ↵Dave Airlie2018-06-223-218/+118
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Fixes for v4.18-rc2: - A reversion of a commit in drm/sun4i to fix a run-time fault. - Various fixes to the sii8620 bridge. - Small bugfix to correctly check stride in atmel-hlcdc. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/787d4bef-a579-4046-d0fc-f8c2c5b80c25@linux.intel.com
| | * drm/bridge/sii8620: fix display of packed pixel modes in MHL2Maciej Purski2018-06-211-16/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently packed pixel modes in MHL2 can't be displayed. The device automatically recognizes output format, so setting format other than RGB causes failure. Fix it by writing proper values to registers. Tested on MHL1 and MHL2 using various vendors' dongles both in DVI and HDMI mode. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1516706239-9104-1-git-send-email-m.purski@samsung.com
| | * Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"Paul Kocialkowski2018-06-181-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70. The offending commit triggers a run-time fault when accessing the panel element of the sun4i_tcon structure when no such panel is attached. It was apparently assumed in said commit that a panel is always used with the TCON. Although it is often the case, this is not always true. For instance a bridge might be used instead of a panel. This issue was discovered using an A13-OLinuXino, that uses the TCON in RGB mode for a simple DAC-based VGA bridge. Cc: stable@vger.kernel.org Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613081647.31183-1-paul.kocialkowski@bootlin.com
| | * drm/atmel-hlcdc: check stride values in the first planeStefan Agner2018-06-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The statement always evaluates to true since the struct fields are arrays. This has shown up as a warning when compiling with clang: warning: address of array 'desc->layout.xstride' will always evaluate to 'true' [-Wpointer-bool-conversion] Check for values in the first plane instead. Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support") Cc: <stable@vger.kernel.org> Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180617084826.31885-1-stefan@agner.ch
| | * drm/bridge/sii8620: fix HDMI cable connection to dongleMaciej Purski2018-06-131-23/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MHL bridge is usually connected to TV via MHL dongle. Currently plugging HDMI cable to dongle is handled improperly. Fix it by splitting connecting of a dongle and a HDMI cable. The driver should now handle unplugging a sink from a dongle and plugging a different sink with new edid. Tested on MHL1, MHL2 and MHL3 using various vendors' dongles both in DVI and HDMI mode. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1516705996-8928-1-git-send-email-m.purski@samsung.com
| | * drm/bridge/sii8620: remove HSIC initializationMaciej Purski2018-06-131-38/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HSIC initialization was taken from the vendor code. HSIC in MHL circuit is not connected, so it is not possible to test it. Tests prove that without HSIC the device works well. Therefore it can be removed. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1511968368-30884-1-git-send-email-m.purski@samsung.com
| | * drm/bridge/sii8620: start MHL transmission after HDMI signal detectionMaciej Purski2018-06-131-51/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vendor code waits for infoframe to detect video mode set by source. We do not need to follow this pattern, because video mode information is provided by drm core. As a result most of the infoframe handling code can be removed. Start transmission immediately after detecting stream on HDMI lines in irq_scdt() function without waiting for infoframe interrupt. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1511956130-24482-1-git-send-email-m.purski@samsung.com
| | * drm/bridge/sii8620: fix potential buffer overflowMaciej Purski2018-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Buffer overflow error should not occur, as mode_fixup() callback filters pixel clock value and it should never exceed 600000. However, current implementation is not obviously safe and relies on implementation of mode_fixup(). Make 'i' variable never reach unsafe value in order to avoid buffer overflow error. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: bf1722ca ("drm/bridge/sii8620: rewrite hdmi start sequence") Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1511341718-6974-1-git-send-email-m.purski@samsung.com
| | * drm/bridge/sii8620: fix display modes validationMaciej Purski2018-06-131-39/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current implementation of mode_valid() and mode_fixup() callbacks handle packed pixel modes improperly. Fix it by using proper maximum clock values from the documentation. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1517568865-25219-1-git-send-email-m.purski@samsung.com
| | * drm/bridge/sii8620: fix loops in EDID fetch logicAndrzej Hajda2018-06-131-11/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Function should constantly check if cable is connected and finish in finite time. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maciej Purski <m.purski@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180115173357.31067-4-a.hajda@samsung.com
| | * drm/bridge/sii8620: simplify hardware reset procedureAndrzej Hajda2018-06-131-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no need to flip reset pin twice. Also delays can be changed to values present in vendor's code. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maciej Purski <m.purski@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180608060457.18357-1-a.hajda@samsung.com
| * | Merge tag 'drm-intel-fixes-2018-06-21' of ↵Dave Airlie2018-06-2217-77/+204
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v4.18-rc2: - Mostly cc: stable display fixes, including a DBLSCAN regression fix - GEM fixes for this merge window Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/87d0wkuypy.fsf@intel.com
| | * | drm/i915: Enable provoking vertex fix on Gen9 systems.Kenneth Graunke2018-06-192-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SF and clipper units mishandle the provoking vertex in some cases, which can cause misrendering with shaders that use flat shaded inputs. There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN (for the clipper) that work around the issue. These registers are unfortunately not part of the logical context (even the power context), and so we must reload them every time we start executing in a context. Bugzilla: https://bugs.freedesktop.org/103047 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180615190605.16238-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org (cherry picked from commit b77422f80337d363eed60c8c48db9cb6e33085c9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Fix context ban and hang accounting for clientMika Kuoppala2018-06-193-25/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If client is smart or lucky enough to create a new context after each hang, our context banning mechanism will never catch up, and as a result of that it will be saved from client banning. This can result in a never ending streak of gpu hangs caused by bad or malicious client, preventing access from other legit gpu clients. Fix this by always incrementing per client ban score if it hangs in short successions regardless of context ban scoring. The exception are non bannable contexts. They remain detached from client ban scoring mechanism. v2: xchg timestamp, tidyup (Chris) v3: comment, bannable & banned together (Chris) Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180615104429.31477-1-mika.kuoppala@linux.intel.com (cherry picked from commit 14921f3cef85b0167a9145e5f29b9dfc3b2a84dc) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Turn off g4x DP port in .post_disable()Ville Syrjälä2018-06-191-16/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While Bspec doesn't list a specific sequence for turning off the DP port on g4x we are getting an underrun if the port is disabled in the .disable() hook. Looks like the pipe stops when the port stops, and by that time the plane disable may not have completed yet. Also the plane(s) seem to end up in some wonky state when this happens as they also signal another underrun immediately after we turn them back on during the next enable sequence. We could add a vblank wait in .disable() to avoid wedging the planes, but I assume we're still tripping up the pipe in some way. So it seems better to me to just follow the ILK+ sequence and turn off the DP port in .post_disable() instead. This sequence doesn't seem to suffer from this problem. Could be it was always the intended sequence for DP and the gen4 bspec was just never updated to include it. Originally we used the bad sequence even on ilk+, but I changed that in commit 08aff3fe26ae ("drm/i915: Move DP port disable to post_disable for pch platforms") as it was causing issues on those platforms as well. I left out g4x then only because I didn't have the hardware to test it. Now that I do it's fairly clear that the ilk+ sequence is also the right choice for g4x. v2: Fix whitespace fail (Jani) Mention the ilk+ commit (Jani) Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 51a9f6dfc00d35f927ecfaf6f0ae8ebaba39b3fe) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Disallow interlaced modes on g4x DP outputsVille Syrjälä2018-06-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like interlaced DP output doesn't work on g4x either. Not all that surprising considering we already established that interlaced DP output is busted on VLV/CHV. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-1-ville.syrjala@linux.intel.com (cherry picked from commit 929168c5f3df5d9ea0ef426c33e971157d045eab) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Fix PIPESTAT irq ack on i965/g4xVille Syrjälä2018-06-191-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On i965/g4x IIR is edge triggered. So in order for IIR to notice that there is still a pending interrupt we have to force and edge in ISR. For the ISR/IIR pipe event bits we can do that by temporarily clearing all the PIPESTAT enable bits when we ack the status bits. This will force the ISR pipe event bit low, and it can then go back high when we restore the PIPESTAT enable bits. This avoids the following race: 1. stat = read(PIPESTAT) 2. an enabled PIPESTAT status bit goes high 3. write(PIPESTAT, enable|stat); 4. write(IIR, PIPE_EVENT) The end result is IIR==0 and ISR!=0. This can lead to nasty vblank wait/flip_done timeouts if another interrupt source doesn't trick us into looking at the PIPESTAT status bits despite the IIR PIPE_EVENT bit being low. Before i965 IIR was level triggered so this problem can't actually happen there. And curiously VLV/CHV went back to the level triggered scheme as well. But for simplicity we'll use the same i965/g4x compatible code for all platforms. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 132c27c97cb958f637dc05adc35a61b47779bcd8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSIVille Syrjälä2018-06-1910-5/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When encountering a connector with the scaling mode property both intel and modesetting ddxs sometimes add tons of DBLSCAN modes to the output's mode list. The idea presumably being that since the output will be going through the panel fitter anyway we can pretend to use any kind of mode. Sadly that means we can't reject user modes with the DBLSCAN flag until we know whether we're going to be using the panel's native mode or the user mode directly. Doing otherwise means X clients using xf86vidmode/xrandr will get a protocol error (and often self terminate as a result) when the kernel refuses to use the requested mode with the DBLSCAN flag. To undo the regression we'll move the DBLSCAN checks into the connector->mode_valid() and encoder->compute_config() hooks. Cc: stable@vger.kernel.org Cc: Vito Caputo <vcaputo@pengaru.com> Reported-by: Vito Caputo <vcaputo@pengaru.com> Fixes: e995ca0b8139 ("drm/i915: Provide a device level .mode_valid() hook") References: https://lkml.org/lkml/2018/5/21/715 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180524125403.23445-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106804 Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl> (cherry picked from commit e4dd27aadd205417a2e9ea9902b698a0252ec3a0) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915/execlists: Avoid putting the error pointerChris Wilson2018-06-191-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On allocation error, do not jump to the unwind handler that tries to free the error pointer. Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611153332.14824-1-chris@chris-wilson.co.uk (cherry picked from commit 467d35789e5a4f47428b65ef711b30fdabbb0fd4) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Apply batch location restrictions before pinningChris Wilson2018-06-191-22/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We special case the position of the batch within the GTT to prevent negative self-relocation deltas from underflowing. However, that restriction is being applied after a trial pin of the batch in its current position. Thus we are not rejecting an invalid location if the batch has been used before, leading to an assertion if we happen to need to rearrange the entire payload. In the worst case, this may cause a GPU hang on gen7 or perhaps missing state. References: https://bugs.freedesktop.org/show_bug.cgi?id=105720 Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180610194325.13467-2-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 746c8f143afad7aaa66c484485fc39888d437a3f) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | Merge branch 'drm-fixes-4.18' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2018-06-217-27/+65
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes Bunch of amdgpu fixes mostly all going to stable. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180620190021.2775-1-alexander.deucher@amd.com
| | * | | drm/amdgpu: Make amdgpu_vram_mgr_bo_invisible_size always accurateMichel Dänzer2018-06-191-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least partially in CPU visible VRAM, in particular when all VRAM is visible. v2: * Don't take VRAM mgr spinlock, not needed (Christian König) * Make loop logic simpler and clearer. Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amdgpu: Refactor amdgpu_vram_mgr_bo_invisible_size helperMichel Dänzer2018-06-193-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preparation for the following fix, no functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amdgpu: Update pin_size values before unpinning BOMichel Dänzer2018-06-191-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least in theory, ttm_bo_validate may move the BO, in which case the pin_size accounting would be inconsistent with when the BO was pinned. Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amdgpu:All UVD instances share one idle_work handleJames Zhu2018-06-192-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All UVD instanses have only one dpm control, so it is better to share one idle_work handle. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Tested-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amdgpu: Don't default to DC support for Kaveri and olderHarry Wentland2018-06-191-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've had a number of users report failures to detect and light up display with DC with LVDS and VGA. These connector types are not currently supported with DC. I'd like to add support but unfortunately don't have a system with LVDS or VGA available. In order not to cause regressions we should probably fallback to the non-DC driver for ASICs that support VGA and LVDS. These ASICs are: * Bonaire * Kabini * Kaveri * Mullins ASIC support can always be force enabled with amdgpu.dc=1 v2: Keep Hawaii on DC v3: Added Mullins to the list Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amdgpu: Use kvmalloc_array for allocating VRAM manager nodes arrayMichel Dänzer2018-06-191-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It can be quite big, and there's no need for it to be physically contiguous. This is less likely to fail under memory pressure (has actually happened while running piglit). Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amd/pp: Fix uninitialized variableRajan Vaja2018-06-191-1/+1
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initialize variable to 0 before performing logical OR operation. Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Rajan Vaja <rajan.vaja@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | Merge tag 'drm-misc-fixes-2018-06-12' of ↵Dave Airlie2018-06-201-2/+5
| |\ \ \ | | | |/ | | |/| | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Only a small qxl fix that was queued for v4.17. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/08dcbd63-ed18-6232-7bbd-547a3d63b90f@linux.intel.com
| | * | drm/qxl: Call qxl_bo_unref outside atomic contextJeremy Cline2018-06-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "qxl_bo_unref" may sleep, but calling "qxl_release_map" causes "preempt_disable()" to be called and "preempt_enable()" isn't called until "qxl_release_unmap" is used. Move the call to "qxl_bo_unref" out from in between the two to avoid sleeping from an atomic context. This issue can be demonstrated on a kernel with CONFIG_LOCKDEP=y by creating a VM using QXL, using a desktop environment using Xorg, then moving the cursor on or off a window. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1571128 Fixes: 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Cline <jcline@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180601200532.13619-1-jcline@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
| * | | Merge tag 'drm-misc-next-fixes-2018-06-15' of ↵Dave Airlie2018-06-201-7/+7
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Single fix for v4.18: - Fix possible race conditions while unplugging DRM device. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/1fd8b7d1-e60a-0105-dfb5-d36f99ea0239@linux.intel.com
| | * | | drm: Fix possible race conditions while unplugging DRM deviceOleksandr Andrushchenko2018-05-311-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When unplugging a hotpluggable DRM device we first unregister it with drm_dev_unregister and then set drm_device.unplugged flag which is used to mark device critical sections with drm_dev_enter()/ drm_dev_exit() preventing access to device resources that are not available after the device is gone. But drm_dev_unregister may lead to hotplug uevent(s) fired to user-space on card and/or connector removal, thus making it possible for user-space to try accessing a disconnected device. Fix this by first making sure device is properly marked as disconnected and only then unregister it. Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged") Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reported-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180522141304.18646-1-andr2000@gmail.com
| * | | | Merge branch 'linux-4.18' of git://github.com/skeggsb/linux into drm-fixesDave Airlie2018-06-202-6/+9
| |\ \ \ \ | | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | Single nouveau regression fix. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5VDDKaYKJShyVAGK0MJAHMZOJ02FKQ_aW5DnBCNVgRUw@mail.gmail.com
| | * | | drm/nouveau/kms/nv50-: cursors always use core channel vram ctxdmaBen Skeggs2018-06-192-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ctxdmas for cursors from all heads are setup in the core channel, and due to us tracking allocated handles per-window, we were failing with -EEXIST on multiple-head setups trying to allocate duplicate handles. The cursor code is hardcoded to use the core channel vram ctxdma already, so just skip ctxdma allocation for cursor fbs to fix the issue. Fixes: 5bca1621c07 ("drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows") Reported-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | | Merge tag 'nfs-for-4.18-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds2018-06-226-16/+59
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull NFS client bugfixes from Trond Myklebust: "Hightlights include: - fix an rcu deadlock in nfs_delegation_find_inode() - fix NFSv4 deadlocks due to not freeing the session slot in layoutget - don't send layoutreturn if the layout is already invalid - prevent duplicate XID allocation - flexfiles: Don't tie up all the rpciod threads in resends" * tag 'nfs-for-4.18-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: pNFS/flexfiles: Process writeback resends from nfsiod context as well pNFS/flexfiles: Don't tie up all the rpciod threads in resends sunrpc: Prevent duplicate XID allocation pNFS: Don't send layoutreturn if the layout is already invalid pNFS: Always free the session slot on error in nfs4_layoutget_handle_exception NFS: Fix an rcu deadlock in nfs_delegation_find_inode()
| * | | | | pNFS/flexfiles: Process writeback resends from nfsiod context as wellTrond Myklebust2018-06-191-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although the writeback resends are more robust than the reads, since they are not immediately rescheduled by the same thread, we are better off processing them in the same place as the reads. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
| * | | | | pNFS/flexfiles: Don't tie up all the rpciod threads in resendsTrond Myklebust2018-06-192-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do not want to have rpciod threads perform recursive calls into the RPC layer since that can deadlock. In particular, having to wait for a layoutget can be nasty... We want rather to defer scheduling those retries until we're in the rpc_release() callback, since that is called from the nfsiod workqueue. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
| * | | | | sunrpc: Prevent duplicate XID allocationChuck Lever2018-06-191-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Krzysztof Kozlowski <krzk@kernel.org> reports that a heavy NFSv4 WRITE workload against a slow NFS server causes his Raspberry Pi clients to stall. Krzysztof bisected it to commit 37ac86c3a76c ("SUNRPC: Initialize rpc_rqst outside of xprt->reserve_lock") . I was able to reproduce similar behavior and it appears that rarely the RPC client layer is re-allocating an XID for an RPC that it has already partially sent. This results in the client ignoring the subsequent reply, which carries the original XID. For various reasons, checking !req->rq_xmit_bytes_sent in xprt_prepare_transmit is not a 100% reliable mechanism for determining when a fresh XID is needed. Trond's preference is to allocate the XID at the time each rpc_rqst slot is initialized. This patch should also address a gcc 4.1.2 complaint reported by Geert Uytterhoeven <geert@linux-m68k.org>. Reported-by: Krzysztof Kozlowski <krzk@kernel.org> Fixes: 37ac86c3a76c ("SUNRPC: Initialize rpc_rqst outside of ... ") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
| * | | | | pNFS: Don't send layoutreturn if the layout is already invalidTrond Myklebust2018-06-192-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the layout was invalidated due to a reboot, then don't try to send a layoutreturn for it. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
OpenPOWER on IntegriCloud