aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2015-10-23drm/amdgpu/dce8: optimize pageflipAlex Deucher1-31/+7
Taking the grph update lock is only necessary when updating the the secondary address (for single pipe stereo). Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-23drm/amdgpu: don't try to recreate sysfs entries on resumeAlex Deucher2-0/+6
Fixes an error on resume caused by: fa022a9b65d2886486a022fd66b20c823cd76ad9 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-10-23drm/radeon: don't try to recreate sysfs entries on resumeAlex Deucher2-14/+22
Fixes a harmless error message caused by: 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-10-23drm/amdgpu: stop leaking page flip fenceChristian König1-4/+0
reservation_object_get_fences_rcu already takes the references. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-10-23drm/i915: Cope with request list state change during error state captureTomas Elf1-0/+19
Since we're not synchronizing the ring request list during error state capture the request list state might change between the time the corresponding error request list was allocated and dimensioned to the time when the ring request list is actually captured into the error state. If this happens then do an early exit and be aware that the captured error state might not be fully reliable. * v2: - Chris Wilson: Removed WARN_ON from size check since having the error state request list and the live driver request list diverge like this is a legitimate behaviour. - Tomas Elf: Removed update of num_request field since this made no sense. Just exit and move on. * v3: - Chris Wilson: Removed error message at the point of early exit. The user is not interested in any state changes happening during the error state capture, only in the state that we're trying to capture at the point of the error. Signed-off-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-23Revert "drm/i915: Add soft-pinning API for execbuffer"Daniel Vetter1-19/+0
This reverts commit 510567234180d7d65d2db9f7bd8424cabef13d3c. I somehow managed to combine a patch from Tomas Elf with a totally unrelated commit message from Chris Wilson. Let's revert this and reapply properly. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-10-23drm/i915: Update DRIVER_DATE to 20151023Daniel Vetter1-1/+1
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-23drm/i915: shut up gen8+ SDE irq dmesg noiseDaniel Vetter1-3/+7
We get tons of cases where the master interrupt handler apparently set a bit, with the SDEIIR disagreeing. No idea what's going on there, but it's consistent on gen8+, no one seems to care about it and it's making CI results flaky. Shut it up. No idea what's going on here, but we've had fun with PCH interrupts before: commit 44498aea293b37af1d463acd9658cdce1ecdf427 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 22 17:05:28 2013 -0300 drm/i915: also disable south interrupts when handling them Note that there's a regression report in Bugzilla, and other regression reports on the mailing lists keep croping up. But no ill effects have ever been reported. But for paranoia still keep the message at a debug level as a breadcrumb, just in case. This message was introduced in commit 38cc46d73ed99dd7002f1406002e52d7975d16cc Author: Oscar Mateo <oscar.mateo@intel.com> Date: Mon Jun 16 16:10:59 2014 +0100 drm/i915/bdw: Ack interrupts before handling them (GEN8) v2: Improve commit message a bit. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445590572-23631-2-git-send-email-daniel.vetter@ffwll.ch Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80896 Acked-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-23Merge branch 'topic/hw-constraint-single' into for-nextTakashi Iwai38-109/+317
2015-10-22drm/msm: Remove local fbdev emulation Kconfig optionArchit Taneja3-21/+3
DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the msm kms driver. Replace this with the top level DRM_FBDEV_EMULATION config option where applicable. This also prevents build breaks caused by undefined drm_fb_helper_* functions when legacy fbdev support was disabled. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm/mdp5: Basic support for MDP5 v1.7 (MSM8996)Stephane Viau6-14/+133
This change adds the basic MDP5 support for MSM8996. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm/mdp: Add Software Pixel Extension supportStephane Viau2-30/+127
In order to produce an image, the scalar needs to be fed extra pixels. These top/bottom/left/right values depend on a various of factors, including resolution, scaling type, phase step and initial phase. Pixel Extension are programmed by hardware in most targets - and can be overwritten by software. For some targets (e.g.: msm8996), software *must* program those registers. In order to ease this computation, let's always use bilinear filters, which are easier to program from kernel. Eventually, all of these values will come down from user space for better quality. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm/mdp5: Use the newly introduced enum mdp_component_typeStephane Viau1-12/+13
When calculating phase steps, let's use the same enum mdp_component_type in order to ease the readability; 0/1 indexes are a bit confusing and we now have explicit values to index this type of arrays. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm/hdmi: Add basic HDMI support for msm8996Stephane Viau1-3/+14
The HDMI controller is new in MDP5 v1.7. As of now, this change doesn't reflect the novelty and only adds the basics so the probe gets triggered. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm/mdp5: Avoid printing error messages for optional clocksStephane Viau1-11/+16
The current behavior is to try to get optional clocks and print a dev_err message in case of failure. This looks rather confusing and may increase with the amount of optional clocks. We may need a cleaner way to handle per-device clocks but in the meantime, let's reduce the amount of dev_err messages during the probe. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm: Fix IOMMU clean up path in case msm_iommu_new() failsStephane Viau2-0/+9
msm_iommu_new() can fail and this change makes sure that we detect the failure and free the allocated domain before going any further. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm/mdp5: remove the cfg pointer from SMP structStephane Viau2-5/+5
We want to make sure we control all the information being passed down to SMP block. Having access to the cfg pointer here may create bad things in the future. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm/dsi: Updata LNn_CFG4 register settings for 28nm PHYHai Li1-4/+2
The current settings for 28nm PHY data lane CFG4 registers do not work with certain panels. This change is to modify them to hw recommended values. Signed-off-by: Hai Li <hali@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm: msm: dsi: Don't attempt changing voltage of switchesBjorn Andersson2-2/+2
In some configurations the supplies are voltage switches and not LDOs, making the set voltage call to fail. Check with the regulator framework if the supply can change voltage before attempting. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/msm: update generated headersRob Clark14-114/+359
Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-10-22drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.Tomas Elf1-9/+14
Grab execlist lock when cleaning up execlist queues after GPU reset to avoid concurrency problems between the context event interrupt handler and the reset path immediately following a GPU reset. * v2 (Chris Wilson): Do execlist check and use simpler form of spinlock functions. Signed-off-by: Tomas Elf <tomas.elf@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-22drm/i915: add hotplug activation period to hotplug update maskJani Nikula1-3/+4
commit 0706f17c307b056ff6f1848320ba82d76945a6ff Author: Egbert Eich <eich@suse.de> Date: Wed Sep 23 16:15:27 2015 +0200 drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2 added a check with WARN to ensure only bits within the mask are enabled. Turns out that doesn't hold for G4X, which spits out: [ 2.641439] ------------[ cut here ]------------ [ 2.641444] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:182 i915_hotplug_interrupt_update_locked+0x45/0x83() [ 2.641446] WARN_ON(bits & ~mask) etc. Add CRT_HOTPLUG_ACTIVATION_PERIOD_64 to the mask to fix the warning. Reported-and-tested-by: Oleksij Rempel <linux@rempel-privat.de> References: https://bugzilla.kernel.org/show_bug.cgi?id=104991 Fixes: 0706f17c307b ("drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2") Cc: Egbert Eich <eich@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1445437363-3030-1-git-send-email-jani.nikula@intel.com
2015-10-22drm/i915: Add soft-pinning API for execbufferChris Wilson1-0/+19
Userspace can pass in an offset that it presumes the object is located at. The kernel will then do its utmost to fit the object into that location. The assumption is that userspace is handling its own object locations (for example along with full-ppgtt) and that the kernel will rarely have to make space for the user's requests. v2: Fix i915_gem_evict_range() (now evict_for_vma) to handle ordinary and fixed objects within the same batch Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Daniel, Thomas" <thomas.daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-22Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-nextDave Airlie2-3/+29
rcar-du support for r8a7793/4 * 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev: drm: rcar-du: Add support for the R8A7794 DU drm: rcar-du: Add support for the R8A7793 DU
2015-10-22Merge tag 'drm-vc4-next-2015-10-21' of http://github.com/anholt/linux into drm-nextDave Airlie14-0/+2949
This pull request introduces the vc4 driver, for kernel modesetting on the Raspberry Pi (bcm2835/bcm2836 architectures). It currently supports a display plane and cursor on the HDMI output. The driver doesn't do 3D, power management, or overlay planes yet. [airlied: fixup the enable/disable vblank APIs] Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> * tag 'drm-vc4-next-2015-10-21' of http://github.com/anholt/linux: drm/vc4: Allow vblank to be disabled drm/vc4: Use the fbdev_cma helpers drm/vc4: Add KMS support for Raspberry Pi. drm/vc4: Add devicetree bindings for VC4.
2015-10-22Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-fixesDave Airlie3-4/+15
Just a crash fix for radeon and amdgpu if the user has forcibly disabled dpm and tries to access the pwm sysfs controls. * 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: add missing dpm check for KV dpm late init drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled drm/radeon/dpm: don't add pwm attributes if DPM is disabled
2015-10-22Merge tag 'drm-intel-fixes-2015-10-16' of git://anongit.freedesktop.org/drm-intel into drm-fixesDave Airlie5-55/+75
The revert dance could use some explanation: we had stuff fixed in -next, and initially backported one commit to v4.3. Now, turns out we need more fixes, and we could cherry-pick them all without conflicts if we reverted the backported one first. So did that to not have to edit and backport them all. * tag 'drm-intel-fixes-2015-10-16' of git://anongit.freedesktop.org/drm-intel: drm/i915: Add primary plane to mask if it's visible drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc() drm/i915: Assign hwmode after encoder state readout Revert "drm/i915: Add primary plane to mask if it's visible" drm/i915: Deny wrapping an userptr into a framebuffer drm/i915: Enable DPLL VGA mode before P1/P2 divider write drm/i915: Restore lost DPLL register write on gen2-4 drm/i915: Flush pipecontrol post-sync writes drm/i915: Fix kerneldoc for i915_gem_shrink_all
2015-10-22Merge branch 'linux-4.3' of git://anongit.freedesktop.org/nouveau/linux-2.6 into drm-fixesDave Airlie1-2/+3
Just one fix from Ilia to resolve various issues that have resulted from buffer eviction. * 'linux-4.3' of git://anongit.freedesktop.org/nouveau/linux-2.6: drm/nouveau/gem: return only valid domain when there's only one
2015-10-22drm/nouveau/gem: return only valid domain when there's only oneIlia Mirkin1-2/+3
On nv50+, we restrict the valid domains to just the one where the buffer was originally created. However after the buffer is evicted to system memory, we might move it back to a different domain that was not originally valid. When sharing the buffer and retrieving its GEM_INFO data, we still want the domain that will be valid for this buffer in a pushbuf, not the one where it currently happens to be. This resolves fdo#92504 and several others. These are due to suspend evicting all buffers, making it more likely that they temporarily end up in the wrong place. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-10-22drm: fix mutex leak in drm_dp_get_mst_branch_deviceAdam Richter1-3/+4
In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device that returns without releasing mgr->lock, resulting a spew of kernel messages about a kernel work function possibly having leaked a mutex and presumably more serious adverse consequences later. This patch changes the error to "goto out" to unlock the mutex before returning. [airlied: grabbed from drm-next as it fixes something we've seen] Signed-off-by: Adam J. Richter <adam_richter2004@yahoo.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-21drm/i915: Calculate watermark configuration during atomic check (v2)Matt Roper4-55/+72
v2: Don't forget to actually check the cstate->active value when tallying up the number of active CRTC's. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/59561/
2015-10-21drm/i915: Don't set plane visible during HW readout if CRTC is offMatt Roper1-1/+1
We already ensure that pstate->visible = false when crtc->active = false during runtime programming; make sure we follow the same logic when reading out initial hardware state. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/59564/
2015-10-21drm/i915: Calculate ILK-style watermarks during atomic check (v3)Matt Roper3-45/+51
Calculate pipe watermarks during atomic calculation phase, based on the contents of the atomic transaction's state structure. We still program the watermarks at the same time we did before, but the computation now happens much earlier. While this patch isn't too exciting by itself, it paves the way for future patches. The eventual goal (which will be realized in future patches in this series) is to calculate multiple sets up watermark values up front, and then program them at different times (pre- vs post-vblank) on the platforms that need a two-step watermark update. While we're at it, s/intel_compute_pipe_wm/ilk_compute_pipe_wm/ since this function only applies to ILK-style watermarks and we have a completely different function for SKL-style watermarks. Note that the original code had a memcmp() in ilk_update_wm() to avoid calling ilk_program_watermarks() if the watermarks hadn't changed. This memcmp vanishes here, which means we may do some unnecessary result generation and merging in cases where watermarks didn't change, but the lower-level function ilk_write_wm_values already makes sure that we don't actually try to program the watermark registers again. v2: Squash a few commits from the original series together; no longer leave pre-calculated wm's in a separate temporary structure since it's easier to follow the logic if we just cut over to using the pre-calculated values directly. v3: - Pass intel_crtc instead of drm_crtc to .compute_pipe_wm() entrypoint and use intel_atomic_get_crtc_state() to avoid need for extra casting. (Ander) - Drop unused intel_check_crtc() function prototype. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/60363/
2015-10-21drm/i915: Calculate pipe watermarks into CRTC state (v3)Matt Roper2-35/+57
A future patch will calculate these during the atomic 'check' phase rather than at WM programming time, so let's store the watermark values we're planning to use in the CRTC state; the values actually active on the hardware remains in intel_crtc. While we're at it, do some minor restructuring to keep ILK and SKL values in a union. v2: Don't move cxsr_allowed to state (Maarten) v3: Only calculate watermarks in state. Still keep active watermarks in intel_crtc itself. (Ville) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/59556/
2015-10-21drm/i915: Refactor ilk_update_wm (v3)Ville Syrjälä1-29/+35
Split ilk_update_wm() into two parts; one doing the programming and the other the calculations. v2: Fix typo in commit message v3 (by Matt): Heavily rebased for current codebase. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/60366/
2015-10-21drm/i915: Drop intel_update_sprite_watermarksMatt Roper5-88/+0
The only platform that still has an update_sprite_wm entrypoint is SKL; on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and then performs a regular watermark update. However intel_plane->wm is only used to update a couple fields in intel_wm_config, and those fields are never used by the SKL code, so on SKL an update_sprite_wm is effectively identical to an update_wm call. Since we're already ensuring that the regular intel_update_wm is called any time we'd try to call intel_update_sprite_watermarks, the whole call is redundant and can be dropped. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/60372/
2015-10-21drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic checkMatt Roper4-30/+48
Determine whether we need to apply this workaround at atomic check time and just set a flag that will be used by the main watermark update routine. Moving this workaround into the atomic framework reduces ilk_update_sprite_wm() to just a standard watermark update, so drop it completely and just ensure that ilk_update_wm() is called whenever a sprite plane is updated in a way that would affect watermarks. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/60367/
2015-10-21drm/vmwgfx: Stabilize the command buffer submission codeThomas Hellstrom1-14/+20
This commit addresses some stability problems with the command buffer submission code recently introduced: 1) Make the vmw_cmdbuf_man_process() function handle reruns internally to avoid losing interrupts if the caller forgets to rerun on -EAGAIN. 2) Handle default command buffer allocations using inline command buffers. This avoids rare allocation deadlocks. 3) In case of command buffer errors we might lose fence submissions. Therefore send a new fence after each command buffer error. This will help avoid lengthy fence waits. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2015-10-21drm/amdgpu: change VM size default to 64GBChristian König1-2/+2
That's still small enough to not waste to much memory on PD/PTs. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: add Stoney pci idsSamuel Li1-0/+2
Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: update the core VI support for StoneySamuel Li2-6/+33
Add core VI enablement for Stoney. Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: add VCE support for Stoney (v2)Samuel Li2-2/+8
Stoney is VCE 3.x single. v2: Stoney is single pipe like Fiji Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: add UVD support for StoneySamuel Li1-0/+5
Stoney is UVD 6.x. Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: add GFX support for Stoney (v2)Samuel Li1-18/+382
Stoney is GFX 8.1. v2: update to latest golden settings Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: add SDMA support for Stoney (v2)Samuel Li1-0/+28
Stoney is SDMA 3.x. v2: update to latest golden register settings Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: add DCE support for StoneySamuel Li1-1/+18
Stoney is DCE 11.x. Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: Update SMC/DPM for StoneySamuel Li2-16/+65
Stoney is SMC 8.x. Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: add GMC support for StoneySamuel Li1-0/+12
Stoney is GMC 8.x. Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm/amdgpu: add Stoney chip familySamuel Li2-0/+2
Stoney is based on Carrizo with some IP upgrades. Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-10-21drm: rcar-du: Add support for the R8A7794 DULaurent Pinchart2-2/+26
The R8A7794 DU has a fixed output routing configuration with one RGB output per CRTC and thus lacks the RGB output routing register field. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>