Here are some fixes for drm/rockchip, these fixes base on drm-next.
These fixes works on my popmetal(rk3288) board.
About patch: drm/atomic-helper: Export framebuffer_changed()
Daniel Vetter ack for merging it through rockchip git trees, so framebuffer_changed() can be reused by drm/rockchip.
All others looks good, so I'd like you can land them.
* 'drm-rockchip-next-fixes-2016-01-22' of https://github.com/markyzq/kernel-drm-rockchip:
drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION
drm/rockchip: fix wrong pitch/size using on gem
drm/rockchip: explain why we can't wait_for_vblanks
drm/rockchip: don't wait for vblank if fb hasn't changed
drm/atomic-helper: Export framebuffer_changed()
drm/rockchip/dsi: fix handling mipi_dsi_pixel_format_to_bpp result
drm/rockchip: vop: fix mask when updating interrupts
drm/rockchip: cleanup unnecessary export symbol
drm/rockchip: Don't build rockchip_drm_vop as modules
This pull request just includes the !CONFIG_PM_SLEEP build fix for
vc4.
* tag 'drm-vc4-fixes-2015-01-19' of http://github.com/anholt/linux:
drm/vc4: Remove broken attempt at GPU reset using genpd.
A bunch of etnaviv fixes for 4.5-rc. Most of them are fixing
things in code paths that will only be hit if something goes
wrong, which have been unearthed by more extensive testing.
The only thing that doesn't really qualify as fixes is an UAPI
extension that userspace wants to rely on being present, so
I want to fast-track this into 4.5 before etnaviv ends up in a
released kernel.
* 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux:
drm/etnaviv: call correct function when trying to vmap a DMABUF
drm/etnaviv: rename etnaviv_gem_vaddr to etnaviv_gem_vmap
drm/etnaviv: fix get pages error path in etnaviv_gem_vaddr
drm/etnaviv: fix memory leak in IOMMU init path
drm/etnaviv: add further minor features and varyings count
drm/etnaviv: add helper for comparing model/revision IDs
drm/etnaviv: add helper to extract bitfields
drm/etnaviv: use defined constants for the chip model
drm/etnaviv: update common and state_hi xml.h files
drm/etnaviv: ignore VG GPUs with FE2.0
drm/etnaviv: fix failure path if model is zero
drm/etnaviv: hold object lock while getting pages for coredump
drm/etnaviv: remove owner assignment from platform_driver
Misc radeon and amdgpu fixes:
- SMU firmware loading fix for Stoney
- DP audio fixes for DCE4.1
- Don't expose fbdev device if no connectors
- fix page table LRU list update handling
* 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: only move pt bos in LRU list on success
drm/radeon: fix DP audio support for APU with DCE4.1 display engine
drm/radeon: Add a common function for DFS handling
drm/radeon: cleaned up VCO output settings for DP audio
drm/amd/powerplay: Update SMU firmware loading for Stoney
drm/amdgpu: don't init fbdev if we don't have any connectors
drm/radeon: only init fbdev if we have connectors
drm/radeon: Ensure radeon bo is unreserved in radeon_gem_va_ioctl
drm/amdgpu: fix next_rptr handling for debugfs
drm/radeon: properly byte swap vce firmware setup
drm/amdgpu: add a message to indicate when powerplay is enabled (v2)
drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2
drm/amd/amdgpu: Improve amdgpu_dpm* macros to avoid unexpected result (v2)
drm/amdgpu: Allow the driver to load if amdgpu.powerplay=1 on asics without powerplay support
drm/amdgpu: Use drm_calloc_large for VM page_tables array
drm/amdgpu: Add some tweaks to gfx 8 soft reset
drm/amdgpu: fix tonga smu resume
This fixes a race condition in the error case: since the pt bos have not
necessarily been reserved in case of an error, we could move a pt bo that
is currently in the middle of being evicted/moved by another process,
which then resulted in a BUG_ON in ttm_bo_add_to_lru.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When trying to get the vmap address of an imported buffer, we must
call into the appropriate helper function, to allow the exporter to
establish the vmap, instead of trying to vmap the buffer on our own.
Add an indirection through etnaviv_gem_ops to allow the correct
implementation to be called.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
This function follows the semantics of vmap() by returning
NULL in case of an error. To make things less confusing
rename it to make make both functions more closely related.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
In case that etnaviv_gem_get_pages is unable to get the required
pages the object mutex needs to be unlocked. Also return NULL in
this case instead of propagating the error, as callers of this
function might not be prepared to handle a pointer error, but
expect this call to follow the semantics of a plain vmap to return
NULL in case of an error.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Ignore GPUs with a 2.0 front end. These have a different register
layout for the front end, which provokes imprecise aborts from the
register accesses in the 'gpu' debugfs file.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Don't init fbdev if we don't have connectors. E.g., if you have
a PX laptop with the displays attached to an IGP with no driver
support, you may end up with a blank screen rather than falling
back to vesa, etc.
Based on a similar radeon patch from Rob Clark.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This fixes an issue that was noticed on an optimus/prime laptop with
a kernel that was old enough to not support the integrated intel gfx
(which was driving all the outputs), but did have support for the
discrete radeon gpu. The end result was not falling back to VESA and
leaving the user with a black screen.
(Plus it is kind of silly to create an framebuffer device if there
are no outputs hooked up to the gpu.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
While all objects that get coredumped have an active IOVA and thus
pages already populated, etnaviv_gem_get_pages() still requires the
object lock to be held.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
