- 17 Oct, 2019 6 commits
-
-
Gerd Hoffmann authored
DEFINE_DRM_GEM_SHMEM_FOPS is identical to DEFINE_DRM_GEM_FOPS now, drop it. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-6-kraxel@redhat.com
-
Gerd Hoffmann authored
VM_IO is wrong here, shmem uses normal ram not io memory. Signed-off-by:
Steven Price <steven.price@arm.com> Acked-by:
-
Gerd Hoffmann authored
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 authored
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 authored
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:
-
Thomas Zimmermann authored
The DRM TODO list now contains an entry for converting fbdev drivers over to DRM. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
- 16 Oct, 2019 8 commits
-
-
Sebastian Andrzej Siewior authored
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:
-
Lowry Li (Arm Technology China) authored
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:
-
Lowry Li (Arm Technology China) authored
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:
Mihail Atanassov <mihail.atanassov@arm.com> Reviewed-by:
-
Lowry Li (Arm Technology China) authored
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:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Lowry Li (Arm Technology China) authored
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:
-
Thomas Zimmermann authored
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:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191011134808.3955-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
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 authored
There's nothing special about vboxvideo's fbdev emulation that is not provided by the generic implementation. Switch over and remove the driver's code. Signed-off-by:
-
- 15 Oct, 2019 2 commits
-
-
Rodrigo Siqueira authored
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
-
Daniel Kurtz authored
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:
-
- 14 Oct, 2019 7 commits
-
-
Guido Günther authored
The bridge might have special requirmentes on the input bus. This is e.g. used by the imx-nwl bridge. Signed-off-by:
Guido Günther <agx@sigxcpu.org> Reviewed-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Robert Chiras authored
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:
-
Lucas De Marchi authored
Fixes: 83fa9842 ("drm/dp-mst: Drop connection_mutex check") Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
zhengbin authored
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 f5bab222 ("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
-
zhengbin authored
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 f5bab222 ("OMAPDSS: HDMI: Add OMAP5 HDMI support") Reported-by:
-
zhengbin authored
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 9960aa7c ("drm/omap: move omapdss & displays under omapdrm") Reported-by:
-
zhengbin authored
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 2ecceeb5 ("drm/omap: Move buffer pitch/offset to drm_framebuffer") Reported-by:
-
- 13 Oct, 2019 4 commits
-
-
Nickey Yang authored
Some VOP's (such as px30) dclk_pol bit is at the last. So it is necessary to distinguish dclk_pol and pin_pol. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Reviewed-by:
Sandy Huang <hjc@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20191010034452.20260-2-nickey.yang@rock-chips.com
-
Ben Dooks authored
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:
-
Ben Dooks authored
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:
-
Markus Elfring authored
Simplify this function implementation by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
- 11 Oct, 2019 11 commits
-
-
Ville Syrjälä authored
@swap@ identifier TEMP; expression A,B; @@ - TEMP = A; - A = B; - B = TEMP; + swap(A, B); @@ type T; identifier swap.TEMP; @@ ( - T TEMP; | - T TEMP = {...}; ) ... when != TEMP Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by:Boris Brezillon <boris.brezillon@collabora.com>
-
Tomi Valkeinen authored
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:
Jean-Jacques Hiblot <jjhiblot@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-9-jjhiblot@ti.com
-
Tomi Valkeinen authored
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 authored
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 authored
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 authored
Reorder OMAP_BO flags and improve the comments. Signed-off-by:
-
Tomi Valkeinen authored
Allow NULL to be passed in 'dma_addr' for omap_gem_pin(), in case the caller does not need the dma_addr. Signed-off-by:
-
Tomi Valkeinen authored
Add omap_gem_unpin_locked() which is a version of omap_gem_unpin() that expects the caller to hold the omap_obj lock. Signed-off-by:
-
Jean-Jacques Hiblot authored
This would give us a WARN_ON() if the pin/unpin calls are unbalanced. Proposed-by:
-
Ezequiel Garcia authored
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:
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
-
Ezequiel Garcia authored
Add the register specifier description for an optional gamma LUT address. Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
-
- 10 Oct, 2019 2 commits
-
-
Ben Dooks authored
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:
-
Maarten Lankhorst authored
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:
-
