aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2018-09-25drm: rcar-du: lvds: D3/E3 supportLaurent Pinchart2-47/+355
The LVDS encoders in the D3 and E3 SoCs differ significantly from those in the other R-Car Gen3 family members: - The LVDS PLL architecture is more complex and requires computing PLL parameters manually. - The PLL uses external clocks as inputs, which need to be retrieved from DT. - In addition to the different PLL setup, the startup sequence has changed *again* (seems someone had trouble making his/her mind). Supporting all this requires DT bindings extensions for external clocks, brand new PLL setup code, and a few quirks to handle the differences in the startup sequence. The implementation doesn't support all hardware features yet, namely - Using the LV[01] clocks generated by the CPG as PLL input. - Providing the LVDS PLL clock to the DU for use with the RGB output. Those features can be added later when the need will arise. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
2018-09-25drm: bridge: thc63: Restrict modes based on hardware operating frequencyLaurent Pinchart1-0/+18
The THC63LVD1024 is restricted to a pixel clock frequency in the range of 8 to 135 MHz. Implement the bridge .mode_valid() operation accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
2018-09-24drm/i915/icl: Program T_INIT_MASTER registersMadhav Chauhan1-0/+19
This patch programs the time (in escape clocks) to drive the link in the initialization (i.e. LP-11) state. v2: Rebase v3: Remove step hard coding comments (Jani N) Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1537095223-5184-5-git-send-email-madhav.chauhan@intel.com
2018-09-24drm/i915/icl: Enable DDI BufferMadhav Chauhan1-0/+22
This patch enables DDI buffer by writing to DDI_BUF_CTL register and wait for DDI status to be *not idle* for a port. v2: Rebase v3: Remove step hard coding comments (Jani N) Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1537095223-5184-4-git-send-email-madhav.chauhan@intel.com
2018-09-24drm/i915/icl: DSI vswing programming sequenceMadhav Chauhan1-0/+120
This patch setup voltage swing before enabling combo PHY DDI (shared with DSI). Note that DSI voltage swing programming is for high speed data buffers. HW automatically handles the voltage swing for the low power data buffers. v2: Rebase v3: Address various review comments related to VSWING programming (Jani N) Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1537095223-5184-3-git-send-email-madhav.chauhan@intel.com
2018-09-24drm/i915/icl: Configure lane sequencing of combo phy transmitterMadhav Chauhan1-0/+39
This patch set the loadgen select and latency optimization for aux and transmit lanes of combo phy transmitters. It will be used for MIPI DSI HS operations. v2: Rebase v3: Add empty line to make code more legible (Ville). Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1537095223-5184-2-git-send-email-madhav.chauhan@intel.com
2018-09-24drm/tegra: dpaux: Use the correct definition for pad modesDmitry Osipenko1-1/+1
Some of definitions in the code changed the meaning, unfortunately one place missed the change. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-09-21drm/i915: Force planar YUV coordinates to be a multiple of 2, v2.Maarten Lankhorst1-1/+8
We can't make NV12 work any other way. The scaler doesn't handle odd coordinates well, and we will get visual corruption on the screen. Changes since v1: - Put the check in intel_plane_check_src_coordinates. (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-9-maarten.lankhorst@linux.intel.com
2018-09-21drm/i915: Move programming plane scaler to its own function.Maarten Lankhorst1-38/+52
This cleans the code up slightly, and will make other changes easier. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-8-maarten.lankhorst@linux.intel.com
2018-09-21drm/i915: Clean up scaler setup, v2.Maarten Lankhorst3-51/+66
On skylake we can switch to a high quality scaler mode when only 1 out of 2 scalers are used, but on GLK and later bit 28 has a different meaning. Don't set it, and make clear the distinction between SKL and later PS values. Changes since v1: - Add missing break statement. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [mlankhorst: Remove extra newline] Link: https://patchwork.freedesktop.org/patch/msgid/20180921144437.20037-1-maarten.lankhorst@linux.intel.com
2018-09-21drm/i915: Replace call to commit_planes_on_crtc with internal update, v2.Maarten Lankhorst3-22/+33
drm_atomic_helper_commit_planes_on_crtc calls begin_commit, then plane_update hooks, then flush_commit. Because we keep our own visibility tracking through plane_state->visible there's no need to rely on the atomic hooks for this. By explicitly writing our own helper, we can update visible planes as needed, which is useful to make NV12 support work as intended. Changes since v1: - Reword commit message. (Matt Roper) - Rename to intel_update_planes_on_crtc(). (Matt) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-6-maarten.lankhorst@linux.intel.com
2018-09-21drm/i915: Make intel_crtc_disable_planes() use active planes mask.Maarten Lankhorst1-15/+14
This will only disable planes we actually had marked as visible in crtc_state->visible_planes and cleans up intel_crtc_disable_plane() slightly. This is also useful for when we start enabling NV12 support for gen11, in which we will make the separate Y plane visible, but ignore the Y plane's state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-5-maarten.lankhorst@linux.intel.com
2018-09-21drm/i915: Unconditionally clear plane visibility, v2.Maarten Lankhorst1-5/+6
We need to assume the plane has been visible before, even if no CRTC is assigned to the plane. This is because when enabling a nv12 plane on gen11, we will have to enable an extra plane and make it visible by marking it in crtc_state->active_planes for intel_update_planes_on_crtc(). Additionally, clear visible flag in intel_plane_atomic_check, in case we ever hit a bug with visibility. Our code implicitly assumes that plane_state->visible is only true when crtc and fb are set, so we will either null deref in intel_fbc_choose_crtc() or do something bad during the actual commit which cares even more. Changes since v1: - Unconditionally clear crtc_state->active_planes as well. - Reword commit message, since this is now a preparation patch for NV12 Y / UV plane linking. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [mlankhorst: Clear nv12_planes in the beginning as well, clarify commit message] Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-4-maarten.lankhorst@linux.intel.com
2018-09-21drm/i915: Handle cursor updating active_planes correctly, v2.Maarten Lankhorst1-8/+28
While we may not update new_crtc_state, we may clear active_planes if the new cursor update state will disable the cursor, but we fail after. If this is immediately followed by a modeset disable, we may soon not disable the planes correctly when we start depending on active_planes. Changes since v1: - Clarify why we cannot swap crtc_state. (Matt) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-3-maarten.lankhorst@linux.intel.com
2018-09-21drm/i915: Clean up casts to crtc_state in intel_atomic_commit_tail()Maarten Lankhorst1-10/+12
Use old/new_intel_crtc_state, and get rid of all the conversion casts where they don't add anything. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-2-maarten.lankhorst@linux.intel.com
2018-09-21drm/malidp: Fix writeback in NV12Alexandru Gheorghe4-7/+48
When we want to writeback to memory in NV12 format we need to program the RGB2YUV coefficients. Currently, we don't program the coefficients and NV12 doesn't work at all. This patchset fixes that by programming a sane default(bt709, limited range) as rgb2yuv coefficients. In the long run, probably we need to think of a way for userspace to be able to program that, but for now I think this is better than not working at all or not advertising NV12 as a supported format for memwrite. Changes since v1: - Write the rgb2yuv coefficients only once, since we don't change them at all, just write them the first time NV12 is programmed, suggested by Brian Starkey, here [1] [1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186819.html Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-09-21drm: mali-dp: Call drm_crtc_vblank_reset on device initAlexandru Gheorghe1-0/+1
Currently, if userspace calls drm_wait_vblank before the crtc is activated the crtc vblank_enable hook is called, which in case of malidp driver triggers some warninngs. This happens because on device init we don't inform the drm core about the vblank state by calling drm_crtc_vblank_on/off/reset which together with drm_vblank_get have some magic that prevents calling drm_vblank_enable when crtc is off. Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2018-09-21drm: Fix syncobj handing of schedule() returning 0Chris Wilson1-26/+15
After schedule() returns 0, we must do one last check of COND to determine the reason for the wakeup with 0 jiffies remaining before reporting the timeout -- otherwise we may lose the signal due to scheduler delays. References: https://bugs.freedesktop.org/show_bug.cgi?id=106690 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/20180920200530.2836-2-chris@chris-wilson.co.uk Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-09-21drm: Use default dma_fence hooks where possible for null syncobjChris Wilson1-11/+0
Both the .enable_signaling and .release of the null syncobj fence can be replaced by the default callbacks for a small reduction in code size. In particular the default callback for .release was changed in commit e28bd101ae1b ("drm: rename null fence to stub fence in syncobj v2") which neglected its RCU protection. Fixes: e28bd101ae1b ("drm: rename null fence to stub fence in syncobj v2") 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/20180920200530.2836-1-chris@chris-wilson.co.uk Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-09-21drm/i915: Update DRIVER_DATE to 20180921Joonas Lahtinen1-1/+1
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-09-21drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMSJosé Roberto de Souza1-0/+6
All DRM_CLIENT capabilities are tied to KMS support, so returning -EOPNOTSUPP when KMS is not supported. v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available in uapi) instead of -ENOTSUPP v3: adding comments about the feature requirement about capabilities Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180918174809.17123-1-jose.souza@intel.com
2018-09-21drm/vkms: Fix possible memory leak in _vkms_get_crc()Wei Yongjun1-0/+1
'vaddr_out' is malloced in _vkms_get_crc() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: db7f419c06d7 ("drm/vkms: Compute CRC with Cursor Plane") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1536976399-1295-1-git-send-email-weiyongjun1@huawei.com
2018-09-21drm/i915: Update DRIVER_DATE to 20180921Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-09-21Merge tag 'drm-fixes-2018-09-21' of git://anongit.freedesktop.org/drm/drmGreg Kroah-Hartman29-116/+151
David writes: "drm fixes for 4.19-rc5: - core: fix debugfs for atomic, fix the check for atomic for non-modesetting drivers - amdgpu: adds a new PCI id, some kfd fixes and a sdma fix - i915: a bunch of GVT fixes. - vc4: scaling fix - vmwgfx: modesetting fixes and a old buffer eviction fix - udl: framebuffer destruction fix - sun4i: disable on R40 fix until next kernel - pl111: NULL termination on table fix" * tag 'drm-fixes-2018-09-21' of git://anongit.freedesktop.org/drm/drm: (21 commits) drm/amdkfd: Fix ATS capablity was not reported correctly on some APUs drm/amdkfd: Change the control stack MTYPE from UC to NC on GFX9 drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7 drm/vmwgfx: Fix buffer object eviction drm/vmwgfx: Don't impose STDU limits on framebuffer size drm/vmwgfx: limit mode size for all display unit to texture_max drm/vmwgfx: limit screen size to stdu_max during check_modeset drm/vmwgfx: don't check for old_crtc_state enable status drm/amdgpu: add new polaris pci id drm: sun4i: drop second PLL from A64 HDMI PHY drm: fix drm_drv_uses_atomic_modeset on non modesetting drivers. drm/i915/gvt: clear ggtt entries when destroy vgpu drm/i915/gvt: request srcu_read_lock before checking if one gfn is valid drm/i915/gvt: Add GEN9_CLKGATE_DIS_4 to default BXT mmio handler drm/i915/gvt: Init PHY related registers for BXT drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation drm/fb-helper: Remove set but not used variable 'connector_funcs' drm: udl: Destroy framebuffer only if it was initialized drm/sun4i: Remove R40 display pipeline compatibles drm/pl111: Make sure of_device_id tables are NULL terminated ...
2018-09-21Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-nextDave Airlie275-8170/+81755
This is a new pull for drm-next on top of last weeks with the following changes: - Fixed 64 bit divide - Fixed vram type on vega20 - Misc vega20 fixes - Misc DC fixes - Fix GDS/GWS/OA domain handling Previous changes from last week: amdgpu/kfd: - Picasso (new APU) support - Raven2 (new APU) support - Vega20 enablement - ACP powergating improvements - Add ABGR/XBGR display support - VCN JPEG engine support - Initial xGMI support - Use load balancing for engine scheduling - Lots of new documentation - Rework and clean up i2c and aux handling in DC - Add DP YCbCr 4:2:0 support in DC - Add DMCU firmware loading for Raven (used for ABM and PSR) - New debugfs features in DC - LVDS support in DC - Implement wave kill for gfx/compute (light weight reset for shaders) - Use AGP aperture to avoid gart mappings when possible - GPUVM performance improvements - Bulk moves for more efficient GPUVM LRU handling - Merge amdgpu and amdkfd into one module - Enable gfxoff and stutter mode on Raven - Misc cleanups Scheduler: - Load balancing support - Bug fixes ttm: - Bulk move functionality - Bug fixes radeon: - Misc cleanups Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920150438.12693-1-alexander.deucher@amd.com
2018-09-21Merge branch 'drm-fixes-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-fixesDave Airlie11-18/+49
A few fixes for 4.19: - Add a new polaris pci id - KFD fixes for raven and gfx7 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920155850.5455-1-alexander.deucher@amd.com
2018-09-20drm/i915/execlists: Onion unwind for logical_ring_init() failureChris Wilson1-7/+11
Fix up the error unwind for logical_ring_init() failing by moving the cleanup into the callers who own the various bits of state during initialisation, so we don't forget to free the state allocated by the caller. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920195948.16448-1-chris@chris-wilson.co.uk
2018-09-20drm/i915: Park the GPU on module loadChris Wilson1-0/+8
Once we have flushed the first request through the system to both load a context and record the default state; tell the GPU to park and idle itself, putting itself immediately (hopefully at least) into a powersaving state, and allowing ourselves to start from known state after setting up all our bookkeeping. 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/20180920161343.1117-1-chris@chris-wilson.co.uk
2018-09-20drm/i2c: tda9950: set MAX_RETRIES for errors onlyHans Verkuil1-1/+2
The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to prevent the CEC framework from retrying the transmit. If the transmit was successful, then don't set this flag. Found by running 'cec-compliance -A' on a beaglebone box. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-09-20drm/i2c: tda9950: fix timeout counter checkColin Ian King1-1/+1
Currently the check to see if the timeout has reached zero is incorrect and the check is instead checking if the timeout is non-zero and not zero, hence it will break out of the loop on the first iteration and the msleep is never executed. Fix this by breaking from the loop when timeout is zero. Detected by CoverityScan, CID#1469404 ("Logically Dead Code") Fixes: f0316f93897c ("drm/i2c: tda9950: add CEC driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-09-20drm/i915/selftests: Live tests emit requests and so require rpmChris Wilson6-0/+33
As we emit requests or touch HW directly for some of the live tests, the requirement is that we hold the rpm wakeref before doing so. We want a mix of granularity since we will want to test runtime suspend, so try to mark up only the critical sections where we need rpm for the live test. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108002 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/20180920144934.16611-1-chris@chris-wilson.co.uk
2018-09-20drm/i915: pass dev_priv to i915_gem_cleanup_stolenMatthew Auld3-5/+3
It really wants dev_priv anyway, also now matches i915_gem_init_stolen. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@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/20180920142707.19659-2-matthew.auld@intel.com
2018-09-20drm/i915: don't assume struct page in i915_sg_trimMatthew Auld2-1/+5
If we copy all the contents of the sg across and not just the page link, we can then also put it to work in fake_get_huge_pages and beyond. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180920142707.19659-1-matthew.auld@intel.com
2018-09-20drm/amdkfd: Fix ATS capablity was not reported correctly on some APUsYong Zhao3-6/+29
Because CRAT_CU_FLAGS_IOMMU_PRESENT was not set in some BIOS crat, we need to workaround this. For future compatibility, we also overwrite the bit in capability according to the value of needs_iommu_device. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yong Zhao <Yong.Zhao@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-09-20drm/amdkfd: Change the control stack MTYPE from UC to NC on GFX9Yong Zhao5-5/+10
CWSR fails on Raven if the control stack is MTYPE_UC, which is used for regular GART mappings. As a workaround we map it using MTYPE_NC. The MEC firmware expects the control stack at one page offset from the start of the MQD so it is part of the MQD allocation on GFXv9. AMDGPU added a memory allocation flag just for this purpose. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yong Zhao <yong.zhao@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-09-20drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7Amber Lin1-1/+1
A wrong register bit was examinated for checking SDMA status so it reports false failures. This typo only appears on gfx_v7. gfx_v8 checks the correct bit. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Amber Lin <Amber.Lin@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-09-20drm/atomic: Initialise planes with opaque alpha valuesKieran Bingham1-3/+1
Planes without an alpha property, using __drm_atomic_helper_plane_reset will have their plane state alpha initialised as zero, which represents a transparent alpha. If this value is then used for the plane, it may not be visible by default, and thus doesn't represent a good initialisation state. Update the default state->alpha value to DRM_BLEND_ALPHA_OPAQUE unconditionally when the plane is reset. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180919155700.10342-2-kieran.bingham+renesas@ideasonboard.com
2018-09-20drm/i915/guc: Restore preempt-context across S3/S4Chris Wilson1-53/+27
Stolen memory is lost across S4 (hibernate) or S3-RST as it is a portion of ordinary volatile RAM. As we allocate our rings from stolen, this may include the rings used for our preempt context and their breadcrumb instructions. In order to allow preemption following hibernation and loss of stolen memory, we therefore need to repopulate the instructions inside the lost ring upon resume. To handle both module load and resume, we simply defer constructing the ring to first use. Testcase: igt/drv_selftest/live_gem Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180919205432.18394-1-chris@chris-wilson.co.uk
2018-09-20drm/i915/selftests: Basic stress test for rapid context switchingChris Wilson1-0/+195
We need to exercise the HW and submission paths for switching contexts rapidly to check that features such as execlists' wa_tail are adequate. Plus it's an interesting baseline latency metric. v2: Check the initial request for allocation errors v3: Use finite waits for more robust handling of broken code Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920105809.1872-1-chris@chris-wilson.co.uk
2018-09-20drm/i915/selftests: Free the batch along the contexts error pathChris Wilson1-0/+1
Remember to release the batch bo reference if we hit an error trying to submit our MI_STORE_DWORD_IMM. References: https://bugs.freedesktop.org/show_bug.cgi?id=107979 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180919195544.1511-9-chris@chris-wilson.co.uk
2018-09-20gpu/drm/exynos: Convert drm_atomic_helper_suspend/resume()Souptick Joarder4-52/+2
convert drm_atomic_helper_suspend/resume() to use drm_mode_config_helper_suspend/resume(). exynos_drm_fbdev_suspend/resume can be removed as drm_mode_config_helper_suspend/resume has implement the same in generic way. Remove suspend_state from exynos_drm_private struct as it is no more useful. Signed-off-by: Ajit Negi <ajitn.linux@gmail.com> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-09-20drm/exynos: enable out_bridge in exynos_dsi_enableMaciej Purski1-15/+23
As the out bridge will not be enabled directly by the framework, it should be enabled by DSI. exynos_dsi_enable() should handle a case, when there is an out_bridge connected as a DSI peripheral. Changed in v5: - fixed error path in exynos_dsi_enable Signed-off-by: Maciej Purski <m.purski@samsung.com> [ a.hajda@samsung.com: v5 ] Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-09-20drm/exynos: move connector creation to attach callbackMaciej Purski1-21/+32
The current implementation assumes that the only possible peripheral device for DSIM is a panel. Using an output bridge child device should also be possible. If an output bridge is available, don't create a new connector. Instead, call drm_bridge_attach() and set encoder's bridge to NULL in order to avoid an out bridge from being visible by the framework, as the DSI bus needs control on enabling its child output bridge. Such sequence is required by Toshiba TC358764 bridge, which is a DSI peripheral bridge device. changed in v5: - detach bridge in mipi_dsi detach callback Signed-off-by: Maciej Purski <m.purski@samsung.com> [ a.hajda@samsung.com: v5 ] Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Manually merged due to merge conflict. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-09-20drm/exynos: rename bridge_node to in_bridge_nodeMaciej Purski1-8/+8
Driver uses bridge_node to refer to bridge on input side of DSI. Since we want to add support for bridges on output side lets add "in" prefix to avoid confusion with out bridges. Changes in v5: - replace mic_ prefix with in_ Signed-off-by: Maciej Purski <m.purski@samsung.com> [ a.hajda@samsuung.com: v5 ] Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-09-20Merge tag 'sound-4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundGreg Kroah-Hartman1-0/+2
Takashi writes: "sound fixes for 4.19-rc5 here comes a collection of various fixes, mostly for stable-tree or regression fixes. Two relatively high LOCs are about the (rather simple) conversion of uapi integer types in topology API, and a regression fix about HDMI hotplug notification on AMD HD-audio. The rest are all small individual fixes like ASoC Intel Skylake race condition, minor uninitialized page leak in emu10k1 ioctl, Firewire audio error paths, and so on." * tag 'sound-4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (33 commits) ALSA: fireworks: fix memory leak of response buffer at error path ALSA: oxfw: fix memory leak of discovered stream formats at error path ALSA: oxfw: fix memory leak for model-dependent data at error path ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path ALSA: hda - Enable runtime PM only for discrete GPU ALSA: oxfw: fix memory leak of private data ALSA: firewire-tascam: fix memory leak of private data ALSA: firewire-digi00x: fix memory leak of private data sound: don't call skl_init_chip() to reset intel skl soc sound: enable interrupt after dma buffer initialization Revert "ASoC: Intel: Skylake: Acquire irq after RIRB allocation" ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO ASoC: cs4265: fix MMTLR Data switch control ASoC: AMD: Ensure reset bit is cleared before configuring ALSA: fireface: fix memory leak in ff400_switch_fetching_mode() ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping ASoC: rsnd: don't fallback to PIO mode when -EPROBE_DEFER ASoC: rsnd: adg: care clock-frequency size ASoC: uniphier: change status to orphan ASoC: rsnd: fixup not to call clk_get/set under non-atomic ...
2018-09-20drm/vmwgfx: Fix buffer object evictionThomas Hellstrom1-1/+1
Commit 19be55701071 ("drm/ttm: add operation ctx to ttm_bo_validate v2") introduced a regression where the vmwgfx driver refused to evict a buffer that was still busy instead of waiting for it to become idle. Fix this. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2018-09-20drm/vmwgfx: Don't impose STDU limits on framebuffer sizeDeepak Rawat2-35/+14
If framebuffers are larger, we create bounce surfaces that are within STDU limits. Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2018-09-20drm/vmwgfx: limit mode size for all display unit to texture_maxDeepak Rawat1-3/+7
For all display units, limit mode size exposed to texture_max_width/ height as this is the maximum framebuffer size that virtual device can create. Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2018-09-20drm/vmwgfx: limit screen size to stdu_max during check_modesetDeepak Rawat1-8/+22
For STDU individual screen target size is limited by SVGA_REG_SCREENTARGET_MAX_WIDTH/HEIGHT registers so add that limit during atomic check_modeset. An additional limit is placed in the update_layout ioctl to avoid requesting layouts that current user-space typically can't support. Also modified the comments to reflect current limitation on topology. Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2018-09-20drm/vmwgfx: don't check for old_crtc_state enable statusDeepak Rawat1-1/+1
During atomic check to prepare the new topology no need to check if old_crtc_state was enabled or not. This will cause atomic_check to fail because due to connector routing a crtc can be in atomic_state even if there was no change to enable status. Detected this issue with igt run. Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>