The i2c and aux buses use the same pads so add
a mutex to protect access to the pads.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Setting the power state prior to restoring the display
hardware leads to blank screens on some systems. Drop
the power state set from dpm resume. The power state
will get set as part of the mode set sequence. Also
add an explicit power state set after mode set resume
to cover PX and headless systems.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=76761
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
So a few people complained that
commit 177cf92de4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Apr 1 22:14:59 2014 +0200
drm/crtc-helpers: fix dpms on logic
which was merged into 3.15-rc1, broke resume on radeons. Strangely git
bisect lead everyone to
commit 25f397a429
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 19 18:57:11 2013 +0200
drm/crtc-helper: explicit DPMS on after modeset
which was merged long ago and actually part of 3.14.
Digging deeper I've noticed (again) that the call to
drm_helper_resume_force_mode in the radeon resume handlers was a no-op
previously because everything gets shut down on suspend. radeon does
this with explicit calls to drm_helper_connector_dpms with DPMS_OFF.
But with 177c we now force the dpms state to ON, so suddenly
resume_force_mode actually forced the crtcs back on.
This is the intention of the change after all, the problem is that
radeon resumes the fbdev console layer _before_ restoring the display,
through calling fb_set_suspend. And fbcon does an immediate ->set_par,
which in turn causes the same forced mode restore to happen.
Two concurrent modeset operations didn't lead to happiness. Fix this
by delaying the fbcon resume until the end of the readeon resum
functions.
v2: Fix up a bit of the spelling fail.
References: https://lkml.org/lkml/2014/5/29/1043
References: https://lkml.org/lkml/2014/5/2/388
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751
Tested-by: Ken Moffat <zarniwhoop@ntlworld.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ken Moffat <zarniwhoop@ntlworld.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
When accel is not working on device with virtual address space radeon
segfault because the ib buffer is NULL and trying to map it inside the
virtual address space trigger segfault. This patch only map the ib
buffer if accel is working.
Cc: <stable@vger.kernel.org>
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Some buffers (UVD/VM page tables) must be placed in VRAM,
but the byte restriction for moving buffers didn't took this
into account.
v2: keep closer to the original code
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
v2 (chk): fix image size storage
v3 (chk): fix UV size calculation
Signed-off-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
- Use vddc/sclk dep table for voltage if available
- Fix UVD DPM setup
- Patch voltage tables properly for non-UVD blocks
- Fix DPM + UVD/VCE on Mullins
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
The way the tile mode array index was calculated only makes sense for
the CIK specific macrotile mode array. For SI, we need to use one of the
tile mode array indices reserved for displayable surfaces.
This happened to result in correct display most if not all of the time
because most of the SI tiling modes use the same number of banks.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Check to make sure the transaction succeeded before
using the register value. Fixes occasional link training
problems.
Noticed-by: Sergei Antonov <saproj@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Testing the update pending bit directly after issuing an
update is nonsense cause depending on the pixel clock the
CRTC needs a bit of time to execute the flip even when we
are in the VBLANK period.
This is just a non invasive patch to solve the problem at
hand, a more complete and cleaner solution should follow
in the next merge window.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76564
v2: fix source IDs for CRTC2-6
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Next pull request, this time more of the drm de-midlayering work. The big
thing is that his patch series here removes everything from drm_bus except
the set_busid callback. Thierry has a few more patches on top of this to
make that one optional to.
With that we can ditch all the non-pci drm_bus implementations, which
Thierry has already done for the fake tegra host1x drm_bus.
Reviewed by Thierry, Laurent and David and now also survived some testing
on my intel boxes to make sure the irq fumble is fixed correctly ;-) The
last minute rebase was just to add the r-b tags from Thierry for the 2
patches I've redone.
* 'drm-init-cleanup' of git://people.freedesktop.org/~danvet/drm:
drm/<drivers>: don't set driver->dev_priv_size to 0
drm: Remove dev->kdriver
drm: remove drm_bus->get_name
drm: rip out dev->devname
drm: inline drm_pci_set_unique
drm: remove bus->get_irq implementations
drm: pass the irq explicitly to drm_irq_install
drm/irq: Look up the pci irq directly in the drm_control ioctl
drm/irq: track the irq installed in drm_irq_install in dev->irq
drm: rename dev->count_lock to dev->buf_lock
drm: Rip out totally bogus vga_switcheroo->can_switch locking
drm: kill drm_bus->bus_type
drm: remove drm_dev_to_irq from drivers
drm/irq: remove cargo-culted locking from irq_install/uninstall
drm/irq: drm_control is a legacy ioctl, so pci devices only
drm/pci: fold in irq_by_busid support
drm/irq: simplify irq checks in drm_wait_vblank
Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.
With that we can now also remove drm_dev_to_irq from drm_irq.c.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.
Unfortunately the vga switcheroo callbacks took this comment at face
value. The problem is that we can't just take the drm_global_mutex
because:
- It would lead to a locking inversion with the driver load/unload
paths.
- It wouldn't actually protect anything, for that we'd need to wrap
the entire vga switcheroo code in the drm_global_mutex. And I'm not
sure whether that would actually solve anything.
What we probably want is a try_to_grab_switcheroo reference kind of
thing which is used in the driver's ->open callback. Then we could
move all that ->can_switch madness into the vga switcheroo core where
it really belongs.
But since that would amount to real work take the easy way out and
just add a comment. It's definitely not going to make anything worse
since doing switcheroo state changes while restarting X just isn't
recommended. Even though the delayed switching code does exactly that.
v2:
- Simplify the ->can_switch implementations more (Thierry)
- Fix comment about the dev->open_count locking (Thierry)
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v1)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only used in some legacy pci drivers, and dereferencing the PCI irq is
actually shorter ...
Since this removes all users for drm_dev_to_irq from the tree except
in drm_irq.c, move the inline helper in there. It'll disappear soon,
too.
v2: Polish commit message (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hpd (hot plug detect) pin assignment got lost
in the conversion to to the common i2c over aux
code. Without this information, aux transactions
do not work properly. Fixes DP failures.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
