If DEM_QXL is y and DRM_TTM_HELPER is m, building fails:
drivers/gpu/drm/qxl/qxl_object.o: undefined reference to `drm_gem_ttm_print_info'
Select DRM_TTM_HELPER to fix this.
Fixes: 78d54f1f6a ("drm/qxl: use drm_gem_ttm_print_info")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20191008024054.32368-1-yuehaibing@huawei.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Not needed any more because we don't have vram specific fops
any more. DEFINE_DRM_GEM_FOPS() can be used instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-12-kraxel@redhat.com
Wire up the new drm_gem_ttm_mmap() helper function,
use generic drm_gem_mmap for &fops.mmap and
delete dead drm_vram_mm_file_operations_mmap().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-10-kraxel@redhat.com
Add helper function to mmap ttm bo's using &drm_gem_object_funcs.mmap().
Note that with this code path access verification is done by
drm_gem_mmap() (which calls drm_vma_node_is_allowed(()).
The &ttm_bo_driver.verify_access() callback is is not used.
v3: use ttm_bo_mmap_obj instead of ttm_bo_mmap_vma_setup
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-9-kraxel@redhat.com
Rename ttm_fbdev_mmap to ttm_bo_mmap_obj. Move the vm_pgoff sanity
check to amdgpu_bo_fbdev_mmap (only ttm_fbdev_mmap user in tree).
The ttm_bo_mmap_obj function can now be used to map any buffer object.
This allows to implement &drm_gem_object_funcs.mmap in gem ttm helpers.
v3: patch added to series
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-8-kraxel@redhat.com
Factor out ttm vma setup to a new function.
Reduces code duplication a bit.
v2: don't change vm_flags (moved to separate patch).
v4: make ttm_bo_mmap_vma_setup static.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-7-kraxel@redhat.com
Not obvious why this is needed. According to Deniel Vetter this is most
likely a historic artefact dating back to the days where drm drivers
exposed hardware registers as mmap'able gem objects, to avoid dumping
touching those registers. shmem gem objects surely don't need that ...
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-4-kraxel@redhat.com
Switch gem shmem helper to the new mmap() workflow,
from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap.
v2: Fix vm_flags and vm_page_prot handling.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-3-kraxel@redhat.com
drm_gem_object_funcs->vm_ops alone can't handle everything which needs
to be done for mmap(), tweaking vm_flags for example. So add a new
mmap() callback to drm_gem_object_funcs where this code can go to.
Note that the vm_ops field is not used in case the mmap callback is
present, it is expected that the callback sets vma->vm_ops instead.
Also setting vm_flags and vm_page_prot is the job of the new callback.
so drivers have more control over these flags.
drm_gem_mmap_obj() will use the new callback for object specific mmap
setup. With this in place the need for driver-speific fops->mmap
callbacks goes away, drm_gem_mmap can be hooked instead.
drm_gem_prime_mmap() will use the new callback too to just mmap gem
objects directly instead of jumping though loops to make
drm_gem_object_lookup() and fops->mmap work.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-2-kraxel@redhat.com
The dependency has been changed from `PREEMPT' to `PREEMPTION'. Reflect
this change in the comment.
Use `PREEMPTION' in the comment.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015191821.11479-29-bigeasy@linutronix.de
Sets output color format according to the connector formats and
display supported formats. Default value is RGB444 and only force
YUV format which must be YUV.
Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015091019.26021-1-lowry.li@arm.com
Set color_depth according to connector->bpc.
Changes since v1:
- Fixed min_bpc is effectively set but not used in
komeda_crtc_get_color_config().
Changes since v2:
- Align the code.
Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Reviewed-by: Mihail Atanassov <mihail.atanassov@arm.com>
Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191012065030.12691-1-lowry.li@arm.com
Adds maximum line size check according to the AFBC decoder limitation
and special Line size limitation(2046) for format: YUV420_10BIT and X0L2.
Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190924080022.19250-3-lowry.li@arm.com
On D71, we are using the global line size. From D32, every
component have a line size register to indicate the fifo size.
So this patch is to set line size support and do the line size
check.
Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190924080022.19250-2-lowry.li@arm.com
The vboxvideo driver's struct vram_framebuffer stores a DRM framebuffer
with an assiciated GEM object. This functionality is also provided by
generic code. Switch vboxvideo over.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011134808.3955-4-tzimmermann@suse.de
The vboxvideo driver provides struct drm_framebuffer_funcs.dirty_fb from
its own implementation. Switch over to drm_atomic_helper_dirty_fb() and
handle screen updates in the primary plane's atomic_update function.
With dirty_fb out of the way, we can further replace struct vbox_frammebuffer
with generic code.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011134808.3955-3-tzimmermann@suse.de
LT-tunable PHY Repeaters can operate in two different modes: transparent
(default) and non-transparent. The value 0x55 specifies the transparent
mode, and 0xaa represents the non-transparent; this commit adds these
two values as definitions.
Cc: Abdoulaye Berthe <Abdoulaye.Berthe@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Abdoulaye Berthe <Abdoulaye.Berthe@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015134010.26zwopwnrbsmz5az@outlook.office365.com
When setting a new display mode, dw_hdmi_setup() calls
dw_hdmi_enable_video_path(), which disables all hdmi clocks, including
the audio clock.
We should only (re-)enable the audio clock if audio was already enabled
when setting the new mode.
Without this patch, on RK3288, there will be HDMI audio on some monitors
if i2s was played to headphone when the monitor was plugged.
ACER H277HU and ASUS PB278 are two of the monitors showing this issue.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008102145.55134-1-cychiang@chromium.org
Currently, the MXSFB DRM driver only supports a panel. But, its output
display signal can also be redirected to another encoder, like a DSI
controller. In this case, that DSI controller may act like a drm_bridge.
In order support this use-case too, this patch adds support for drm_bridge
in mxsfb.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Tested-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1567078215-31601-2-git-send-email-robert.chiras@nxp.com
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c: In function hdmi4_audio_config:
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c:689:6: warning: variable err set but not used [-Wunused-but-set-variable]
It is not used since commit f5bab22291 ("OMAPDSS:
HDMI: Add OMAP5 HDMI support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-5-git-send-email-zhengbin13@huawei.com
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c: In function hdmi5_audio_config:
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c:812:6: warning: variable err set but not used [-Wunused-but-set-variable]
It is not used since commit f5bab22291 ("OMAPDSS:
HDMI: Add OMAP5 HDMI support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-4-git-send-email-zhengbin13@huawei.com
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/omapdrm/dss/dsi.c: In function dsi_proto_timings:
drivers/gpu/drm/omapdrm/dss/dsi.c:3562:46: warning: variable tclk_trail set but not used [-Wunused-but-set-variable]
It is not used since commit 9960aa7cb5 ("drm/omap:
move omapdss & displays under omapdrm")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-3-git-send-email-zhengbin13@huawei.com
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/omapdrm/omap_fb.c: In function omap_framebuffer_update_scanout:
drivers/gpu/drm/omapdrm/omap_fb.c:130:16: warning: variable plane set but not used [-Wunused-but-set-variable]
It is not used since commit 2ecceeb53b ("drm/omap:
Move buffer pitch/offset to drm_framebuffer")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-2-git-send-email-zhengbin13@huawei.com
The rockchip_gem_alloc_object function is not exported so
make it static to avoid the following sparse warning:
drivers/gpu/drm/rockchip/rockchip_drm_gem.c:297:28: warning: symbol 'rockchip_gem_alloc_object' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20191009121022.17478-1-ben.dooks@codethink.co.uk
Include rockchip_drm_drv.h for definition of vop_platform_driver
to avoid the following sparse warning:
drivers/gpu/drm/rockchip/rockchip_vop_reg.c:982:24: warning: symbol 'vop_platform_driver' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20191009132134.18384-1-ben.dooks@codethink.co.uk
On SoCs with DMM/TILER, we have two ways to allocate buffers: normal
dma_alloc or via DMM (which basically functions as an IOMMU). DMM can
map 128MB at a time, and we only map the DMM buffers when they are used
(i.e. not at alloc time). If DMM is present, omapdrm always uses DMM.
There are use cases that require lots of big buffers that are being used
at the same time by different IPs. At the moment the userspace has a
hard maximum of 128MB.
This patch adds three new flags that can be used by the userspace to
solve the situation:
OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory.
This can be used to avoid DMM if the userspace knows it needs more than
128M of memory at the same time.
OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's not
much use for this flag at the moment, as on platforms with DMM it is
used by default, but it's here for completeness.
OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and keep
it pinned. This can be used to 1) get an error at alloc time if DMM
space is full, and 2) get rid of the constant pin/unpin operations which
may have some effect on performance.
If none of the flags are given, the behavior is the same as currently.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-9-jjhiblot@ti.com
Add a helper function omap_gem_validate_flags() which validates the
omap_bo flags passed from the userspace.
Also drop the dev_err() message, as the userspace can cause that at
will.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-8-jjhiblot@ti.com
omap_gem_new() has a comment about OMAP_BO_SCANOUT which does not make
sense. Also, for the TILER case, we drop OMAP_BO_SCANOUT flag for some
reason.
It's not clear what the original purpose of OMAP_BO_SCANOUT is, but
presuming it means "scanout buffer, something that can be consumed by
DSS", this patch cleans up the above issues.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-7-jjhiblot@ti.com
OMAP_BO_TILED does not make sense, as OMAP_BO_TILED_* values are not
bitmasks but normal values. As we already have OMAP_BO_TILED_MASK for
the mask, we can remove OMAP_BO_TILED and use OMAP_BO_TILED_MASK
instead.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-6-jjhiblot@ti.com
This would give us a WARN_ON() if the pin/unpin calls are unbalanced.
Proposed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-2-jjhiblot@ti.com
Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.
The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the latter
is supported by a different driver. This prevents the DRM driver
from requesting an entire register space.
The current implementation works for RGB 10-bit tables, as that
is what seems to work on RK3288.
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010194351.17940-3-ezequiel@collabora.com
Add the register specifier description for an
optional gamma LUT address.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010194351.17940-2-ezequiel@collabora.com
The drm_sched_fence_ops_{scheduled,finished} are not exported
from the file so make them static to avoid the following
warnings from sparse:
drivers/gpu/drm/scheduler/sched_fence.c:131:28: warning: symbol 'drm_sched_fence_ops_scheduled' was not declared. Should it be static?
drivers/gpu/drm/scheduler/sched_fence.c:137:28: warning: symbol 'drm_sched_fence_ops_finished' was not declared. Should it be static?
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191009121447.31017-1-ben.dooks@codethink.co.uk
The rectangles are usually clipped, but it can be useful to have
them unclipped, for example for cursor planes.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[mlankhorst: Change cursor plane to hardware performing clipping. (Ville)
Fix dst description that went missing.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010112918.15724-1-maarten.lankhorst@linux.intel.com
Private atomic objects have grown their own locking with
commit b962a12050
Author: Rob Clark <robdclark@gmail.com>
Date: Mon Oct 22 14:31:22 2018 +0200
drm/atomic: integrate modeset lock with private objects
which means we're no longer relying on connection_mutex for mst state
locking needs.
Cc: Lyude Paul <lyude@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191009224113.5432-1-daniel.vetter@ffwll.ch
