Christian König [Mon, 5 Aug 2019 12:24:55 +0000 (14:24 +0200)]
dma-buf: nuke reservation_object seq number
The only remaining use for this is to protect against setting a new exclusive
fence while we grab both exclusive and shared. That can also be archived by
looking if the exclusive fence has changed or not after completing the
operation.
v2: switch setting excl fence to rcu_assign_pointer
Chris Wilson [Mon, 12 Aug 2019 15:42:47 +0000 (16:42 +0100)]
dma-buf/sw_sync: Synchronize signal vs syncpt free
During release of the syncpt, we remove it from the list of syncpt and
the tree, but only if it is not already been removed. However, during
signaling, we first remove the syncpt from the list. So, if we
concurrently free and signal the syncpt, the free may decide that it is
not part of the tree and immediately free itself -- meanwhile the
signaler goes on to use the now freed datastructure.
In particular, we get struck by commit 0e2f733addbf ("dma-buf: make
dma_fence structure a bit smaller v2") as the cb_list is immediately
clobbered by the kfree_rcu.
v2: Avoid calling into timeline_fence_release() from under the spinlock
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111381 Fixes: d3862e44daa7 ("dma-buf/sw-sync: Fix locking around sync_timeline lists")
References: 0e2f733addbf ("dma-buf: make dma_fence structure a bit smaller v2") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> # v4.14+ Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190812154247.20508-1-chris@chris-wilson.co.uk
Rob Herring [Fri, 26 Jul 2019 22:09:43 +0000 (16:09 -0600)]
drm/panfrost: Add support for GPU heap allocations
The midgard/bifrost GPUs need to allocate GPU heap memory which is
allocated on GPU page faults and not pinned in memory. The vendor driver
calls this functionality GROW_ON_GPF.
This implementation assumes that BOs allocated with the
PANFROST_BO_NOEXEC flag are never mmapped or exported. Both of those may
actually work, but I'm unsure if there's some interaction there. It
would cause the whole object to be pinned in memory which would defeat
the point of this.
On faults, we map in 2MB at a time in order to utilize huge pages (if
enabled). Currently, once we've mapped pages in, they are only unmapped
if the BO is freed. Once we add shrinker support, we can unmap pages
with the shrinker.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-9-robh@kernel.org
Rob Herring [Thu, 8 Aug 2019 20:30:39 +0000 (14:30 -0600)]
drm/panfrost: Consolidate reset handling
Runtime PM resume and job timeouts both call the same sequence of
functions, so consolidate them to a common function. This will make
changing the reset related code easier. The MMU also needs some
re-initialization on reset, so rework its call. In the process, we
hide the address space details within the MMU code in preparation to
support multiple address spaces.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-7-robh@kernel.org
Rob Herring [Thu, 11 Jul 2019 21:56:14 +0000 (15:56 -0600)]
drm/panfrost: Add a no execute flag for BO allocations
Executable buffers have an alignment restriction that they can't cross
16MB boundary as the GPU program counter is 24-bits. This restriction is
currently not handled and we just get lucky. As current userspace
assumes all BOs are executable, that has to remain the default. So add a
new PANFROST_BO_NOEXEC flag to allow userspace to indicate which BOs are
not executable.
There is also a restriction that executable buffers cannot start or end
on a 4GB boundary. This is mostly avoided as there is only 4GB of space
currently and the beginning is already blocked out for NULL ptr
detection. Add support to handle this restriction fully regardless of
the current constraints.
For existing userspace, all created BOs remain executable, but the GPU
VA alignment will be increased to the size of the BO. This shouldn't
matter as there is plenty of GPU VA space.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-6-robh@kernel.org
Rob Herring [Mon, 1 Jul 2019 23:03:30 +0000 (17:03 -0600)]
drm/panfrost: Restructure the GEM object creation
Setting the GPU VA when creating the GEM object doesn't allow for any
conditional adjustments to the mapping. In preparation to support
adjusting the mapping and per FD address spaces, restructure the GEM
object creation to map and unmap the GEM object in the GEM object .open()
and .close() hooks.
While panfrost_gem_free_object() and panfrost_gem_prime_import_sg_table()
are not really needed after this commit, keep them as we'll need them in
subsequent commits.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-4-robh@kernel.org
Rob Herring [Fri, 19 Jul 2019 14:30:12 +0000 (08:30 -0600)]
drm/shmem: Put pages independent of a SG table being set
If a driver does its own management of pages, the shmem helper object's
pages array could be allocated when a SG table is not. There's not
really any good reason to tie putting pages with having a SG table when
freeing the object, so just put pages if the pages array is populated.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-3-robh@kernel.org
Rob Herring [Fri, 19 Jul 2019 14:28:51 +0000 (08:28 -0600)]
drm/gem: Allow sparsely populated page arrays in drm_gem_put_pages
Panfrost has a need for pages allocated on demand via GPU page faults.
When releasing the pages, the only thing preventing using
drm_gem_put_pages() is needing to skip over unpopulated pages, so allow
for skipping over NULL struct page pointers.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-2-robh@kernel.org
Hans de Goede [Sun, 11 Aug 2019 14:37:24 +0000 (16:37 +0200)]
drm: gm12u320: Do not take a mutex from a wait_event condition
I made the condition of the wait_event_timeout call in
gm12u320_fb_update_work a helper which takes a mutex to make sure
that any writes to fb_update.run or fb_update.fb from other CPU cores
are seen before the check is done.
This is not necessary as the wait_event helpers contain the necessary
barriers for this themselves.
More over it is harmfull since by the time the check is done the task
is no longer in the TASK_RUNNING state and calling mutex_lock while not
in task-running is not allowed, leading to this warning when the kernel
is build with some extra locking checks enabled:
[11947.450011] do not call blocking ops when !TASK_RUNNING; state=2 set at
[<00000000e4306de6>] prepare_to_wait_event+0x61/0x190
This commit fixes this by dropping the helper and simply directly
checking the condition (without unnecessary locking) in the
wait_event_timeout call.
Hans de Goede [Tue, 30 Jul 2019 13:38:56 +0000 (15:38 +0200)]
drm: gm12u320: Some minor cleanups
3 small cleanups:
1) Drop unused DRIVER_PATCHLEVEL
2) We do not set mode_config.preferred_depth, so instead of passing the
unset mode_config.preferred_depth to drm_fbdev_generic_setup
simply pass 0
3) Use __maybe_unused instead of #ifdef CONFIG_PM around the suspend /
resume functions
Jason Ekstrand [Mon, 12 Aug 2019 14:22:11 +0000 (09:22 -0500)]
drm/syncobj: Add better overview documentation for syncobj (v2)
This patch only brings the syncobj documentation up-to-date for the
original form of syncobj. It does not contain any information about the
design of timeline syncobjs.
v2: Incorporate feedback from Lionel and Christian:
- Mention actual ioctl and flag names
- Better language around reference counting
- Misc. language cleanups
Sean Paul [Mon, 12 Aug 2019 14:01:03 +0000 (10:01 -0400)]
drm: Fix kerneldoc warns in connector-related docs
Fixes the following warnings:
../drivers/gpu/drm/drm_connector.c:989: WARNING: Unexpected indentation.
../drivers/gpu/drm/drm_connector.c:993: WARNING: Unexpected indentation.
../include/drm/drm_connector.h:544: WARNING: Inline interpreted text or phrase reference start-string without end-string.
../include/drm/drm_connector.h:544: WARNING: Inline interpreted text or phrase reference start-string without end-string.
Changes in v2:
- Use () instead of & for functions (Sam)
Fixes: 1b27fbdde1df ("drm: Add drm_atomic_get_(old|new)_connector_for_encoder() helpers") Fixes: bb5a45d40d50 ("drm/hdcp: update content protection property with uevent") Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190812140112.6702-1-sean@poorly.run
drm/komeda: Fix potential integer overflow in komeda_crtc_update_clock_ratio
Add suffix ULL to constant 1000 in order to avoid a potential integer
overflow and give the compiler complete information about the proper
arithmetic to use. Notice that this constant is being used in a context
that expects an expression of type u64, but it's currently evaluated
using 32-bit arithmetic.
Addresses-Coverity-ID: 1485796 ("Unintentional integer overflow") Fixes: ed22c6d9304d ("drm/komeda: Use drm_display_mode "crtc_" prefixed hardware timings") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.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/20190812000801.GA29204@embeddedor
Ondrej Jirman [Tue, 6 Aug 2019 15:57:41 +0000 (17:57 +0200)]
dt-bindings: display: hdmi-connector: Support DDC bus enable
Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
on-board voltage shifting logic for the DDC bus using a gpio to be able
to access DDC bus. Use ddc-en-gpios property on the hdmi-connector to
model this.
Add binding documentation for optional ddc-en-gpios property.
Chris Wilson [Sun, 11 Aug 2019 21:09:02 +0000 (22:09 +0100)]
dma-fence: Propagate errors to dma-fence-array container
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
v3: Be careful not to flag an error if we race against signal-on-any.
v4: Same applies to installing the signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Dave Airlie [Mon, 12 Aug 2019 04:20:21 +0000 (14:20 +1000)]
Merge tag 'drm-next-5.4-2019-08-09' of git://people.freedesktop.org/~agd5f/linux into drm-next
drm-next-5.4-2019-08-09:
Same as drm-next-5.4-2019-08-06, but with the
readq/writeq stuff fixed and 5.3-rc3 backmerged.
amdgpu:
- Add navi14 support
- Add navi12 support
- Add Arcturus support
- Enable mclk DPM for Navi
- Misc DC display fixes
- Add perfmon support for DF
- Add scatter/gather display support for Raven
- Improve SMU handling for GPU reset
- RAS support for GFX
- Drop last of drmP.h
- Add support for wiping memory on buffer release
- Allow cursor async updates for fb swaps
- Misc fixes and cleanups
amdkfd:
- Add navi14 support
- Add navi12 support
- Add Arcturus support
- CWSR trap handlers updates for gfx9, 10
- Drop last of drmP.h
- Update MAINTAINERS
radeon:
- Misc fixes and cleanups
- Make kexec more reliable by tearing down the GPU
ttm:
- Add release_notify callback
uapi:
- Add wipe memory on release flag for buffer creation
Sam Ravnborg [Sun, 4 Aug 2019 20:16:33 +0000 (22:16 +0200)]
drm/panel: use inline comments in drm_panel.h
Inline comments provide better space for additional comments.
Comments was slightly edited to follow the normal style,
but no change to actual content.
Used the opportuniy to change the order in drm_panel_funcs
to follow the order they will be used by a panel.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190804201637.1240-13-sam@ravnborg.org
Sam Ravnborg [Sun, 4 Aug 2019 20:16:32 +0000 (22:16 +0200)]
drm/panel: move drm_panel functions to .c file
Move inline functions from include/drm/drm_panel.h to drm_panel.c.
This is in preparation for follow-up patches that will add extra
logic to the functions.
As they are no longer static inline, EXPORT them.
v2:
- align order of functions in drm_panel.h and drm_panel.c (Laurent)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190804201637.1240-12-sam@ravnborg.org
Sam Ravnborg [Sun, 4 Aug 2019 20:16:25 +0000 (22:16 +0200)]
drm/imx: fix opencoded use of drm_panel_*
Use the drm_panel_get_modes() function to get the modes.
This patch leave one test for the function pointer:
panel->funcs->get_modes
This is used to check if the panel may have any modes.
There is no direct replacement.
We may be able to just check that drm_panel_get_modes() return > 0,
but as this is not the same functionality it is left for later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: linux-arm-kernel@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20190804201637.1240-5-sam@ravnborg.org
Christian König [Mon, 5 Aug 2019 09:16:12 +0000 (11:16 +0200)]
dma-buf: further relax reservation_object_add_shared_fence
Other cores don't busy wait any more and we removed the last user of checking
the seqno for changes. Drop updating the number for shared fences altogether.
Christian König [Wed, 7 Aug 2019 10:31:48 +0000 (12:31 +0200)]
dma-buf: make dma_fence structure a bit smaller v2
We clear the callback list on kref_put so that by the time we
release the fence it is unused. No one should be adding to the cb_list
that they don't themselves hold a reference for.
This small change is actually making the structure 16% smaller.
Tao Zhou [Fri, 9 Aug 2019 07:57:51 +0000 (15:57 +0800)]
drm/amdgpu: remove RREG64/WREG64
atomic 64 bits REG operations are useless currently
Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Tao Zhou [Fri, 9 Aug 2019 07:57:50 +0000 (15:57 +0800)]
drm/amdgpu: implement UMC 64 bits REG operations
implement 64 bits operations via 32 bits interface
v2: make use of lower_32_bits() and upper_32_bits() macros
Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Tao Zhou [Wed, 7 Aug 2019 02:28:54 +0000 (10:28 +0800)]
drm/amdgpu: replace readq/writeq with atomic64 operations
what we really want is a read or write that is guaranteed to be 64 bits
at a time, atomic64 operations are supported on all architectures
Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Julien Masson [Mon, 24 Jun 2019 14:48:50 +0000 (16:48 +0200)]
drm: meson: venc: use proper macros instead of magic constants
This patch add new macros which are used to set the following
registers:
- ENCI_CFILT_CTRL
- ENCI_CFILT_CTRL2
- ENCI_MACV_MAX_AMP
- ENCI_VIDEO_MODE_ADV
- ENCI_VFIFO2VD_CTL
- ENCI_VIDEO_EN
- ENCP_VIDEO_MODE
- VPU_HDMI_SETTING
- VENC_UPSAMPLE_CTRL0
- VENC_UPSAMPLE_CTRL1
- VENC_UPSAMPLE_CTRL2
- VENC_VDAC_FIFO_CTRL
- VENC_VDAC_DAC0_FILT_CTRL0
- VENC_INTCTRL
Julien Masson [Mon, 24 Jun 2019 14:48:43 +0000 (16:48 +0200)]
drm: meson: viu: use proper macros instead of magic constants
This patch add new macros which are used to set the following
registers:
- VIU_SW_RESET
- VIU_OSD1_CTRL_STAT
- VIU_OSD2_CTRL_STAT
- VIU_OSD1_FIFO_CTRL_STAT
- VIU_OSD2_FIFO_CTRL_STAT
- VIU_MISC_CTRL0
- VIU_OSD_BLEND_CTRL
- OSD1_BLEND_SRC_CTRL
- OSD2_BLEND_SRC_CTRL
- DOLBY_PATH_CTRL
Signed-off-by: Julien Masson <jmasson@baylibre.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fix OSD1_BLEND_SRC_CTRL register init value for G12A] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/86sgrz82em.fsf@baylibre.com
Julien Masson [Mon, 24 Jun 2019 14:48:35 +0000 (16:48 +0200)]
drm: meson: vpp: use proper macros instead of magic constants
This patch add new macros which are used to set the following
registers:
- VPP_OSD_SCALE_COEF_IDX
- VPP_DOLBY_CTRL
- VPP_OFIFO_SIZE
- VPP_HOLD_LINES
- VPP_SC_MISC
- VPP_VADJ_CTRL
Signed-off-by: Julien Masson <jmasson@baylibre.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: put back 0x1020080 in VPP_DUMMY_DATA1 for GXM] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/86tvcf82eu.fsf@baylibre.com
Lucas Stach [Fri, 5 Jul 2019 17:15:35 +0000 (19:15 +0200)]
drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value
The call site expects to get either a valid suballoc or an error
pointer, so a NULL return will not be treated as an error. Make
sure to always return a proper error pointer in case something goes
wrong.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
Linus Walleij [Mon, 5 Aug 2019 08:58:46 +0000 (10:58 +0200)]
drm/panel: simple: Support TI nspire panels
This adds support for the TI nspire panels to the simple panel
roster. This code is based on arch/arm/mach-nspire/clcd.c.
This includes likely the first grayscale panel supported.
These panels will be used with the PL11x DRM driver.
Linus Walleij [Mon, 5 Aug 2019 08:58:44 +0000 (10:58 +0200)]
drm/pl111: Support grayscale
Migrating the TI nspire calculators to use the PL111 driver for
framebuffer requires grayscale support for the elder panel
which uses 8bit grayscale only.
DRM does not support 8bit grayscale framebuffers in memory,
but by defining the bus format to be MEDIA_BUS_FMT_Y8_1X8 we
can get the hardware to turn on a grayscaling feature and
convert the RGB framebuffer to grayscale for us.
Dave Airlie [Fri, 9 Aug 2019 06:04:15 +0000 (16:04 +1000)]
Merge tag 'drm-misc-next-2019-08-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.4:
UAPI Changes:
- HDCP: Add a Content protection type property
Cross-subsystem Changes:
Core Changes:
- Continue to rework the include dependencies
- fb: Remove the unused drm_gem_fbdev_fb_create function
- drm-dp-helper: Make the link rate calculation more tolerant to
non-explicitly defined, yet supported, rates
- fb-helper: Map DRM client buffer only when required, and instanciate a
shadow buffer when the device has a dirty function or says so
- connector: Add a helper to link the DDC adapter used by that connector to
the userspace
- vblank: Switch from DRM_WAIT_ON to wait_event_interruptible_timeout
- dma-buf: Fix a stack corruption
- ttm: Embed a drm_gem_object struct to make ttm_buffer_object a
superclass of GEM, and convert drivers to use it.
- hdcp: Improvements to report the content protection type to the
userspace
Driver Changes:
- Remove drm_gem_prime_import/export from being defined in the drivers
- Drop DRM_AUTH usage from drivers
- Continue to drop drmP.h
- Convert drivers to the connector ddc helper
- ingenic: Add support for more panel-related cases
- komeda: Support for dual-link
- lima: Reduce logging
- mpag200: Fix the cursor support
- panfrost: Export GPU features register to userspace through an ioctl
- pl111: Remove the CLD pads wiring support from the DT
- rockchip: Rework to use DRM PSR helpers, fix a bug in the VOP_WIN_GET
macro
- sun4i: Improve support for color encoding and range
- tinydrm: Rework SPI support, improve MIPI-DBI support, move to drm/tiny
- vkms: Rework of the CRC tracking
- bridges:
- sii902x: Add support for audio graph card
- tc358767: Rework AUX data handling code
- ti-sn65dsi86: Add Debugfs and proper DSI mode flags support
- panels
- Support for GiantPlus GPM940B0, Sharp LQ070Y3DG3B, Ortustech
COM37H3M, Novatek NT39016, Sharp LS020B1DD01D, Raydium RM67191,
Boe Himax8279d, Sharp LD-D5116Z01B
- Conversion of the device tree bindings to the YAML description
- jh057n00900: Rework the enable / disable path
- fbdev:
- ssd1307fb: Support more devices based on that controller
Rob Herring [Mon, 5 Aug 2019 14:33:58 +0000 (08:33 -0600)]
drm/panfrost: Add madvise and shrinker support
Add support for madvise and a shrinker similar to other drivers. This
allows userspace to mark BOs which can be freed when there is memory
pressure.
Unlike other implementations, we don't depend on struct_mutex. The
driver maintains a list of BOs which can be freed when the shrinker
is called. Access to the list is serialized with the shrinker_lock.
John Keeping [Wed, 3 Jul 2019 09:51:11 +0000 (10:51 +0100)]
drm/rockchip: fix VOP_WIN_GET macro
Commit 9a61c54b9bff ("drm/rockchip: vop: group vop registers") seems to
have unintentionally changed the defintion of this macro. Since it is
unused, this was not spotted but any attempt to use it results in
compilation errors.
Emil Velikov [Mon, 27 May 2019 08:17:35 +0000 (09:17 +0100)]
drm/msm: drop DRM_AUTH usage from the driver
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: freedreno@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-7-emil.l.velikov@gmail.com
Clang warns (only Navi warning shown but Arcturus warns as well):
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1534:4: warning:
variable 'asic_default_power_limit' is used uninitialized whenever '?:'
condition is false [-Wsometimes-uninitialized]
smu_read_smc_arg(smu, &asic_default_power_limit);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:588:3: note:
expanded from macro 'smu_read_smc_arg'
((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg)) : 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1550:30: note:
uninitialized use occurs here
smu->default_power_limit = asic_default_power_limit;
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1534:4: note:
remove the '?:' if its condition is always true
smu_read_smc_arg(smu, &asic_default_power_limit);
^
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:588:3: note:
expanded from macro 'smu_read_smc_arg'
((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg)) : 0)
^
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1517:35: note:
initialize the variable 'asic_default_power_limit' to silence this
warning
uint32_t asic_default_power_limit;
^
= 0
1 warning generated.
As the code is currently written, if read_smc_arg were ever NULL, arg
would fail to be initialized but the code would continue executing as
normal because the return value would just be zero.
There are a few different possible solutions to resolve this class
of warnings which have appeared in these drivers before:
1. Assume the function pointer will never be NULL and eliminate the
wrapper macros.
2. Have the wrapper macros initialize arg when the function pointer is
NULL.
3. Have the wrapper macros return an error code instead of 0 when the
function pointer is NULL so that the callsites can properly bail out
before arg can be used.
4. Initialize arg at the top of its function.
Number four is the path of least resistance right now as every other
change will be driver wide so do that here. I only make the comment
now as food for thought.
Fixes: b4af964e75c4 ("drm/amd/powerplay: make power limit retrieval as asic specific") Link: https://github.com/ClangBuiltLinux/linux/issues/627 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_ip_block.status.hw for GMC wasn't set to
false on suspend during GPU reset and so on resume gmc_v9_0_resume
wasn't called.
Caused by 'drm/amdgpu: fix double ucode load by PSP(v3)'
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Likun Gao [Fri, 2 Aug 2019 07:18:57 +0000 (15:18 +0800)]
drm/amdgpu: pin the csb buffer on hw init for gfx v8
Without this pin, the csb buffer will be filled with inconsistent
data after S3 resume. And that will causes gfx hang on gfxoff
exit since this csb will be executed then.
Signed-off-by: Likun Gao <Likun.Gao@amd.com> Tested-by: Paul Gover <pmw.gover@yahoo.co.uk> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Block immediate flips for non-fast updates
[Why]
Underflow can occur in the case where we change buffer pitch, DCC state,
rotation or mirroring for a plane while also performing an immediate
flip. It can also generate a p-state warning stack trace on DCN1 which
is typically observed during the cursor handler pipe locking because of
how frequent cursor updates can occur.
[How]
Store the update type on each CRTC - every plane will have access to
the CRTC state if it's flipping. If the update type is not
UPDATE_TYPE_FAST then the immediate flip should be disallowed.
No changes to the target vblank sequencing need to be done, we just
need to ensure that the surface registers do a double buffered update.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Validate dc_plane_info and dc_plane_size in atomic check
[Why]
Pitch, DCC, rotation and mirroring can result in updates that are not
UPDATE_TYPE_FAST but UPDATE_TYPE_MED instead. DC needs dc_plane_info
and dc_plane_size to make this determination and we aren't currently
passing this into DC during atomic check.
Underflow (visible or non-visible) can occur if we don't validate this
correctly. This also will generally trigger p-state warnings, typically
via the cursor handler when locking.
[How]
Get the framebuffer tiling flags and generate the required structures
for DC in dm_determine_update_type_for_commit.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Brian Starkey [Tue, 6 Aug 2019 12:46:22 +0000 (13:46 +0100)]
drm/crc-debugfs: Add notes about CRC<->commit interactions
CRC generation can be impacted by commits coming from userspace, and
enabling CRC generation may itself trigger a commit. Add notes about
this to the kerneldoc.
Changes since v1:
- Clarified that anything that would disable CRCs counts as a full
modeset, and so userspace needs to reconfigure after full modesets
Changes since v2:
- Add these notes
- Rebase onto drm-misc-next (trivial conflict in comment)
Signed-off-by: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link:- https://patchwork.freedesktop.org/patch/321974/
Ramalingam C [Thu, 1 Aug 2019 11:41:18 +0000 (17:11 +0530)]
drm/i915: update the hdcp state with uevent
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320965/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:17 +0000 (17:11 +0530)]
drm/hdcp: update content protection property with uevent
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
v4:
KDoc is extended bit more [pekka]
v5:
Uevent usage is documented at kdoc of "Content Protection" also
[pekka]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320963/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:16 +0000 (17:11 +0530)]
drm: uevent for connector status change
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the property is really attached with connector [Daniel]
v4:
Typos and string length suggestions are addressed [Sean]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sean Paul <sean@poorly.run> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320961/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:15 +0000 (17:11 +0530)]
drm/i915: Attach content type property
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
v5:
Simplified the Type change procedure. [Daniel]
v6:
Type change with UNDESIRED state is ignored.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320959/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:14 +0000 (17:11 +0530)]
drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
v6:
Kernel docs are modified [pekka]
v7:
More details in Kernel docs. [pekka]
v8:
Few more clarification into kernel doc of content type [pekka]
v9:
Small fixes in coding style.
v10:
Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14
projects / linux.git / log