Daniel Vetter [Mon, 18 Nov 2019 10:35:30 +0000 (11:35 +0100)]
dma-buf: Drop dma_buf_k(un)map
It's unused.
10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.
Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode anyway.
Also update the docs in this area to adjust them to reality.
The actual hooks in dma_buf_ops will be removed once all the
implementations are gone.
Daniel Vetter [Mon, 18 Nov 2019 10:35:28 +0000 (11:35 +0100)]
drm/omapdrm: Drop dma_buf->k(un)map
No in-tree users left.
Note that this is one of the few (if only) implementations of dma-buf
that provided a kmap, but not a vmap implemenation. Given that the
only real user (in-tree at least) of kmap was tegra, and it's
impossible to buy a chip with tegra host1x and ompadrm on the same
SoC, there's no problem here.
Daniel Vetter [Mon, 18 Nov 2019 10:35:27 +0000 (11:35 +0100)]
drm/i915: Drop dma_buf->k(un)map
No in-tree users left.
Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.
Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: "Christian König" <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118103536.17675-7-daniel.vetter@ffwll.ch
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Laura Abbott <labbott@redhat.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Laura Abbott <labbott@redhat.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: devel@driverdev.osuosl.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20191118103536.17675-5-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 18 Nov 2019 10:35:24 +0000 (11:35 +0100)]
drm/i915: Remove dma_buf_kmap selftest
It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
Delete it, before we start garbage-collecting the various
implementations.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118103536.17675-4-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 18 Nov 2019 10:35:23 +0000 (11:35 +0100)]
drm/tegra: Delete host1x_bo_ops->k(un)map
It doesn't have any callers anymore.
Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
do userspace mmaps, but a kernel vmap. I think most places use vmap
for this, except ttm, which uses kmap for vmap for added confusion.
mmap seems entirely for userspace mappings set up through mmap(2)
syscall.
Daniel Vetter [Mon, 18 Nov 2019 10:35:22 +0000 (11:35 +0100)]
drm/tegra: Map cmdbuf once for reloc processing
A few reasons to drop kmap:
- For native objects all we do is look at obj->vaddr anyway, so might
as well not call functions for every page.
- Reloc-processing on dma-buf is ... questionable.
- Plus most dma-buf that bother kernel cpu mmaps give you at least
vmap, much less kmaps. And all the ones relevant for arm-soc are
again doing a obj->vaddr game anyway, there's no real kmap going on
on arm it seems.
Plus this seems to be the only real in-tree user of dma_buf_kmap, and
I'd like to get rid of that.
Uma Shankar [Sat, 23 Nov 2019 09:18:40 +0000 (14:48 +0530)]
Revert "drm/fbdev: Fallback to non tiled mode if all tiles not present"
This reverts commit f25c7a006cd1 ("drm/fbdev: Fallback to non tiled mode
if all tiles not present"). The commit causes flip done timeouts in CI.
Below are the sample errors thrown in logs:
[IGT] core_getversion: executing
[IGT] core_getversion: exiting, ret=0
Setting dangerous option reset - tainting kernel
drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out
drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out
drm:drm_atomic_helper_wait_for_dependencies] ERROR [PLANE:92:plane 1B] flip_done timed out
[drm:drm_atomic_helper_wait_for_flip_done] ERROR [CRTC:152:pipe B] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] ERROR [PLANE:92:plane 1B] flip_done timed out
[drm:drm_atomic_helper_wait_for_flip_done] ERROR [CRTC:152:pipe B] flip_done timed out
Console: switching to colour frame buffer device 480x135
[drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out
Reverting the change for now to unblock CI execution.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Fixes: f25c7a006cd1 ("drm/fbdev: Fallback to non tiled mode if all tiles not present") Closes: https://gitlab.freedesktop.org/drm/intel/issues/6 Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191123091840.32382-1-uma.shankar@intel.com
drm/gma500: Pass struct drm_gem_object to framebuffer functions
Several framebuffer functions take a pointer to an object of type
struct gtt_range when they actually need the GEM base object. Passing
the GEM object removes some type casting and clutter.
drm/gma500: Replace struct psb_framebuffer with struct drm_framebuffer
After removing all unnecessary fields, struct psb_framebuffer is just a
wrapper around struct drm_framebuffer. So we can replace the former with
the latter.
Linus Walleij [Fri, 22 Nov 2019 07:25:08 +0000 (08:25 +0100)]
drm/mcde: Do not needlessly logically and with 3
The i index i always 0..3 in these statements so there
is no need to tag "& 3" to clamp it to 3 here. Make
the operator precedence explicit even if it's correct
as it is, the paranthesis creates less cognitive stress
for humans.
Daniel Vetter [Fri, 15 Nov 2019 09:21:15 +0000 (10:21 +0100)]
drm/mediatek: don't open-code drm_gem_fb_create
Aside: There's a few other fb_create implementations which
simply check for valid buffer format (or an approximation thereof),
and then call drm_gem_fb_create. For atomic drivers at least we could
walk all planes and make sure the format/modifier combo is valid,
and remove even more code.
For non-atomic drivers that's not possible, since the format list for
the primary buffer might be garbage (and most likely it is).
Also delete mtk_drm_fb.[hc] since it would now only contain one
function.
Acked-by: CK Hu <ck.hu@mediatek.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191115092120.4445-4-daniel.vetter@ffwll.ch
Daniel Vetter [Wed, 20 Nov 2019 10:56:07 +0000 (11:56 +0100)]
drm/msm: Don't init ww_mutec acquire ctx before needed
For locking semantics it really doesn't matter when we grab the
ticket. But for lockdep validation it does: the acquire ctx is a fake
lockdep. Since other drivers might want to do a full multi-lock dance
in their fault-handler, not just lock a single dma_resv. Therefore we
must init the acquire_ctx only after we've done all the copy_*_user or
anything else that might trigger a pagefault. For msm this means we
need to move it past submit_lookup_objects.
Aside: Why is msm still using struct_mutex, it seems to be using
dma_resv_lock for general buffer state protection?
v2:
- Add comment to explain why the ww ticket setup is separate (Rob)
- Fix up error handling, we need to make sure we don't call
ww_acquire_fini without _init.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-and-tested-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20191120105607.3023-1-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 19 Nov 2019 21:08:43 +0000 (22:08 +0100)]
dma-resv: Also prime acquire ctx for lockdep
Semnatically it really doesn't matter where we grab the ticket. But
since the ticket is a fake lockdep lock, it matters for lockdep
validation purposes.
This means stuff like grabbing a ticket and then doing
copy_from/to_user isn't allowed anymore. This is a changed compared to
the current ttm fault handler, which doesn't bother with having a full
reservation. Since I'm looking into fixing the TODO entry in
ttm_mem_evict_wait_busy() I think that'll have to change sooner or
later anyway, better get started. A bit more context on why I'm
looking into this: For backwards compat with existing i915 gem code I
think we'll have to do full slowpath locking in the i915 equivalent of
the eviction code. And with dynamic dma-buf that will leak across
drivers, so another thing we need to standardize and make sure it's
done the same way everyway.
Unfortunately this means another full audit of all drivers:
- gem helpers: acquire_init is done right before taking locks, so no
problem. Same for acquire_fini and unlocking, which means nothing
that's not already covered by the dma_resv_lock rules will be caught
with this extension here to the acquire_ctx.
- etnaviv: An absolute massive amount of code is run between the
acquire_init and the first lock acquisition in submit_lock_objects.
But nothing that would touch user memory and could cause a fault.
Furthermore nothing that uses the ticket, so even if I missed
something, it would be easy to fix by pushing the acquire_init right
before the first use. Similar on the unlock/acquire_fini side.
- i915: Right now (and this will likely change a lot rsn) the acquire
ctx and actual locks are right next to each another. No problem.
- msm has a problem: submit_create calls acquire_init, but then
submit_lookup_objects() has a bunch of copy_from_user to do the
object lookups. That's the only thing before submit_lock_objects
call dma_resv_lock(). Despite all the copypasta to etnaviv, etnaviv
does not have this issue since it copies all the userspace structs
earlier. submit_cleanup does not have any such issues.
With the prep patch to pull out the acquire_ctx and reorder it msm
is going to be safe too.
- nouveau: acquire_init is right next to ttm_bo_reserve, so all good.
Similar on the acquire_fini/ttm_bo_unreserve side.
- ttm execbuf utils: acquire context and locking are even in the same
functions here (one function to reserve everything, the other to
unreserve), so all good.
- vc4: Another case where acquire context and locking are handled in
the same functions (one function to lock everything, the other to
unlock).
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: Huang Rui <ray.huang@amd.com> Cc: Eric Anholt <eric@anholt.net> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rob Herring <robh@kernel.org> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119210844.16947-3-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 19 Nov 2019 21:08:42 +0000 (22:08 +0100)]
drm/modeset: Prime modeset lock vs dma_resv
It's kinda really hard to get this wrong on a driver with both display
and dma_resv locking. But who ever knows, so better to make sure that
really all drivers nest these the same way.
For actual lock semantics the acquire context nesting doesn't matter.
But to teach lockdep what's going on with ww_mutex the acquire ctx is
a fake lockdep lock, hence from a lockdep pov it does matter. That's
why I figured better to include it.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119210844.16947-2-daniel.vetter@ffwll.ch
Sean Paul [Fri, 15 Nov 2019 20:52:36 +0000 (15:52 -0500)]
MAINTAINERS: Remove myself from drm-misc entry
Cc: Dave Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20191115205302.246625-1-sean@poorly.run
Colin Ian King [Wed, 20 Nov 2019 17:35:09 +0000 (17:35 +0000)]
drm/dp_mst: fix multiple frees of tx->bytes
Currently tx->bytes is being freed r->num_transactions number of
times because tx is not being set correctly. Fix this by setting
tx to &r->transactions[i] so that the correct objects are being
freed on each loop iteration.
Jani Nikula [Tue, 19 Nov 2019 10:05:36 +0000 (12:05 +0200)]
drm/r128: make ATI PCI GART part of its only user, r128
The ATI Rage 128 driver has been the only user of ATI PCI GART code
since Radeon dropped UMS support in commit 8333f607a631 ("drm/radeon:
remove UMS support"). Clean up the drm top level directory, Kconfig and
Makefile by making ati_pcigart.[ch] part of r128. Drop the
CONFIG_DRM_ATI_PCIGART config option made redundant by the change.
This reduces drm.ko module size slightly when legacy drivers are
enabled, and moves the baggage to r128.ko instead.
Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119100536.12024-1-jani.nikula@intel.com
Daniel Vetter [Fri, 15 Nov 2019 09:21:18 +0000 (10:21 +0100)]
drm/xen: Simplify fb_create
The current code is a pretty good wtf moment, since we drop the
reference before we use it. It's not a big deal, because a) we only
use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
already holds a full reference for us.
Might as well take the real pointer ins't of complicated games that
baffle.
psbfb_probe performs an evaluation of the required size from the stolen
GTT memory, but gets it wrong in two distinct ways:
- The resulting size must be page-size-aligned;
- The size to allocate is derived from the surface dimensions, not the fb
dimensions.
When two connectors are connected with different modes, the smallest will
be stored in the fb dimensions, but the size that needs to be allocated must
match the largest (surface) dimensions. This is what is used in the actual
allocation code.
Fix this by correcting the evaluation to conform to the two points above.
It allows correctly switching to 16bpp when one connector is e.g. 1920x1080
and the other is 1024x768.
drm/udl: Replace fbdev code with generic emulation
The udl driver can use the generic fbdev implementation. Convert it.
v5:
* initialize console after registering device
v4:
* hardcode console bpp to 16
v3:
* remove module parameter fb_bpp in favor of fbdev's video
* call drm_fbdev_generic_setup() directly; remove udl_fbdev_init()
* use default for struct drm_mode_config_funcs.output_poll_changed
* use default for struct drm_driver.lastclose
drm/komeda: Clean warnings: candidate for 'gnu_printf’ format attribute
komeda/komeda_event.c: In function ‘komeda_sprintf’:
komeda/komeda_event.c:31:2: warning: function ‘komeda_sprintf’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
num = vsnprintf(str->str + str->len, free_sz, fmt, args);
zhengbin [Sat, 16 Nov 2019 11:04:28 +0000 (19:04 +0800)]
drm/gma500: remove set but not used variable 'channel_eq'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/cdv_intel_dp.c: In function cdv_intel_dp_complete_link_train:
drivers/gpu/drm/gma500/cdv_intel_dp.c:1596:7: warning: variable channel_eq set but not used [-Wunused-but-set-variable]
Manasi Navare [Wed, 13 Nov 2019 22:29:52 +0000 (14:29 -0800)]
drm/fbdev: Fallback to non tiled mode if all tiles not present
In case of tiled displays, if we hotplug just one connector,
fbcon currently just selects the preferred mode and if it is
tiled mode then that becomes a problem if rest of the tiles are
not present.
So in the fbdev driver on hotplug when we probe the client modeset,
if we dont find all the connectors for all tiles, then on a connector
with one tile, just fallback to the first available non tiled mode
to display over a single connector.
On the hotplug of the consecutive tiled connectors, if the tiled mode
no longer exists because of fbcon size limitation, then return
no modes for consecutive tiles but retain the non tiled mode
on the 0th tile.
Use the same logic in case of connected boot case as well.
This has been tested with Dell UP328K tiled monitor.
v2:
* Set the modes on consecutive hotplugged tiles to no mode
if tiled mode is pruned (Dave)
v1:
* Just handle the 1st connector hotplug case
* v1 Reviewed-by: Dave Airlie <airlied@redhat.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Dave Airlie <airlied@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113222952.9231-1-manasi.d.navare@intel.com
Jean Delvare [Fri, 15 Nov 2019 16:07:36 +0000 (17:07 +0100)]
drm/edid: no CEA v3 extension is not an error
It is fine for displays without audio functionality to not implement
CEA v3 extension in their EDID. Do not return an error in that case,
instead return 0 as if there was a CEA v3 extension with no audio or
speaker block.
This fixes the second half of bug fdo#107825:
https://bugs.freedesktop.org/show_bug.cgi?id=107825
Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> 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> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115170736.7d88593d@endymion
zhengbin [Fri, 15 Nov 2019 14:27:07 +0000 (22:27 +0800)]
drm/gma500: remove set but not used variable 'is_hdmi','is_crt'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/cdv_intel_display.c: In function cdv_intel_crtc_mode_set:
drivers/gpu/drm/gma500/cdv_intel_display.c:594:7: warning: variable is_hdmi set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/gma500/cdv_intel_display.c: In function cdv_intel_crtc_mode_set:
drivers/gpu/drm/gma500/cdv_intel_display.c:593:7: warning: variable is_crt set but not used [-Wunused-but-set-variable]
They are not used since commit acd7ef927e06 ("gma500:
Update the Cedarview clock handling")
zhengbin [Fri, 15 Nov 2019 14:27:06 +0000 (22:27 +0800)]
drm/gma500: remove set but not used variable 'error'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/psb_irq.c: In function psb_sgx_interrupt:
drivers/gpu/drm/gma500/psb_irq.c:210:6: warning: variable error set but not used [-Wunused-but-set-variable]
It is introduced by commit 64a4aff283ac ("drm/gma500:
Add support for SGX interrupts"), but never used, so remove it.
zhengbin [Fri, 15 Nov 2019 14:27:05 +0000 (22:27 +0800)]
drm/gma500: remove set but not used variable 'htotal'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/oaktrail_hdmi.c: In function htotal_calculate:
drivers/gpu/drm/gma500/oaktrail_hdmi.c:160:6: warning: variable htotal set but not used [-Wunused-but-set-variable]
It is introduced by commit 39ec748f7174 ("gma600: Enable HDMI support"),
but never used, so remove it.
Jani Nikula [Mon, 28 Oct 2019 10:38:21 +0000 (12:38 +0200)]
drm/print: group logging functions by prink or device based
In preparation for adding struct drm_device based logging, group the
existing functions by prink or struct device based logging. No
functional changes.
Jani Nikula [Mon, 28 Oct 2019 10:38:20 +0000 (12:38 +0200)]
drm/print: convert debug category macros into an enum
Mostly for improved documentation, convert the debug category macros
into an enum. Drop unused DRM_UT_NONE. Document previously undocumented
categories.
Jani Nikula [Mon, 28 Oct 2019 10:38:17 +0000 (12:38 +0200)]
drm/amdgpu: use drm_debug_enabled() to check for debug categories
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: David (ChunMing) Zhou <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Sean Paul <sean@poorly.run> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e30ddbd627be1fe1c67dd007e0d36f81a094bc91.1572258936.git.jani.nikula@intel.com
drm/komeda: Adds gamma and color-transform support for DOU-IPS
Adds gamma and color-transform support for DOU-IPS.
Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
If color management changed, set gamma and color-transform accordingly.
drm: Add a new helper drm_color_ctm_s31_32_to_qm_n()
Add a new helper function drm_color_ctm_s31_32_to_qm_n() for driver to
convert S31.32 sign-magnitude to Qm.n 2's complement that supported by
hardware.
V4: Address Mihai, Daniel and Ilia's review comments.
V5: Includes the sign bit in the value of m (Qm.n).
V6: Allows m = 0 according to Mihail's comments.
V7: Address Mihail's comments.
V8: Use type 'u32' to replace 'uint32_t'
V9: Rebase.
Not sure we don't yet have this as a patch somewhere ...
Motivation is that the automatic lifetime management of the generic fbdev
code is quite tricky, and it'll get even more tricky. Allowing drivers
to just use the fb_probe looks like a recipe for disaster.
Torsten Duwe [Tue, 12 Nov 2019 17:59:40 +0000 (18:59 +0100)]
drm/bridge: fix anx6345 compilation for v5.5
The anx6345 driver originally was copied from anx78xx.c, which has meanwhile
seen a few changes. In particular, the removal of drm_dp_link helpers and the
discontinuation to include drm_bridge.h from drm_crtc.h breaks compilation
in linux-5.5. Apply equivalents of these changes to anx6345.c.
drm/komeda: Optionally dump DRM state on interrupts
It's potentially useful information when diagnosing error/warn IRQs, so
dump it to dmesg with a drm_info_printer. Hide this extra debug dumping
behind another komeda_dev->err_verbosity bit.
Note that there's not much sense in dumping it for INFO events,
since the VSYNC event will swamp the log.
Stephan Gerhold [Wed, 6 Nov 2019 16:58:34 +0000 (17:58 +0100)]
drm/mcde: dsi: Enable clocks in pre_enable() instead of mode_set()
The DSI initialization sequence incorrectly assumes that the mode_set()
function of the DRM bridge is always called when (re-)enabling the display.
This is not necessarily the case.
Keeping the device idle in the framebuffer console for a while results
in the display being turned off using the disable() function. However,
as soon as any key is pressed only (pre_)enable() are called.
mode_set() is skipped because the mode has not been changed.
In this case, the DSI HS/LP clocks are never turned back on,
preventing the display from working.
Fix this by moving a part of the initialization sequence from
mode_set() to pre_enable(). Keep most of the video mode setup in
mode_set() since most of the registers are only dependent on the mode
that is set for the panel - there is no need to write them again each
time we re-enable the display.
Although both show up as connected, the first one does not have
any size and no available modes. This confuses userspace tools
(e.g. kmscube) who look for available modes for the first connector.
The reason for the duplicated connector is that mcde_dsi.c and the
DRM panel bridge helper both set up a DSI connector, with more or less
the same code. The connector set up by the DRM panel bridge is the
one that is correctly set up in the example above.
Therefore we can just remove the connector setup from mcde_dsi.c
and let the DRM core handle all the hard work.
Stephan Gerhold [Wed, 6 Nov 2019 16:58:32 +0000 (17:58 +0100)]
drm/mcde: dsi: Delay start of video stream generator
The initialization order for DSI video mode is important - if we
enable the video stream generator (VSG) before the MCDE DSI formatter
starts sending pixel data, it will immediately run into an error and
disable itself again.
Avoid this problem by delaying the activation of the VSG
until the MCDE DSI formatter is properly set up and running
(i.e. when mcde_dsi_bridge_enable() is called).
Stephan Gerhold [Wed, 6 Nov 2019 16:58:30 +0000 (17:58 +0100)]
drm/mcde: Fix frame sync setup for video mode panels
The MCDE driver differentiates only between "te_sync"
(for hardware TE0 sync) and software sync
(i.e. manually triggered updates) at the moment.
However, none of these options work correctly for video mode panels.
Therefore, we need to make some changes to make them work correctly:
- Select hardware sync coming from the (DSI) formatter.
- Keep the FIFO permanently enabled (otherwise MCDE will stop
feeding data to the panel).
- Skip manual software sync (this is not necessary in video mode).
Automatically detect if the connected panel is using video mode
and enable the necessary changes in that case.
Stephan Gerhold [Wed, 6 Nov 2019 16:58:29 +0000 (17:58 +0100)]
drm/mcde: Provide vblank handling unconditionally
At the moment, vblank handling is only enabled together with
TE synchronization. However, the vblank IRQ is also working with
on displays without TE synchronization (e.g. DSI video mode panels).
It seems like the vblank IRQ is actually generated by the
MCDE hardware for the channel.
Therefore, the vblank handling should be working correctly in
all the cases and we can enable it unconditionally.
Wambui Karuga [Thu, 7 Nov 2019 09:29:45 +0000 (12:29 +0300)]
drm/rockchip: use DRM_DEV_ERROR for log output
Replace the use of the dev_err macro with the DRM_DEV_ERROR
DRM helper macro. rockchip driver uses almost exclusively DRM_* logging
(aside from 2 dev_* instances, one of which is converted in this patch),
so this makes things more consistent.
Udl's GEM code and the generic SHMEM are almost identical. Replace
the former with SHMEM. The dmabuf support in udl is being replaced
with generic GEM PRIME functions.
The main difference is in the caching flags for mmap pages. By
default, SHMEM always sets (uncached) write combining. In udl's
memory management code, only imported buffers use write combining.
Memory pages of locally created buffer objects are mmap'ed with
caching enabled. To keep the optimization, udl provides its own
mmap function for GEM objects where it fixes up the mapping flags.
v3:
- restore udl vmap that enables caching
v2:
- remove obsolete code in a separate patch
Christian König [Fri, 27 Sep 2019 12:34:25 +0000 (14:34 +0200)]
drm/radeon: finally fix the racy VMA setup
Finally clean up the VMA setup for radeon now that TTM exports the
necessary functions.
No functional change, but only compile tested.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/339354/
Christian König [Fri, 27 Sep 2019 12:34:24 +0000 (14:34 +0200)]
drm/ttm: also export ttm_bo_vm_fault v2
That is needed by at least a cleanup in radeon.
v2: also export ttm_bo_vm_access
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/339353/
This commit sets the remaining atomic-modesetting helpers and the flag
DRIVER_ATOMIC. Legacy cursor functions are removed in favor of the cursor
plane. For power management, atomic helpers replace the indvidual
operations that the driver currently runs.
As the CRTC code has already been prepared for a split between mode
setting and plane handling, most of the CRTC's atomic modesetting is
build upon primitives of the non-atomic implementation.
Like the original mode-setting code, the primary plane supports XRGB888,
RGB565 and C8. The plane itself only pins BOs and sets the base address
and scanline offset. The mode-setting code will be located in the CRTC's
atomic helpers.
v2:
* don't set plane call-back functions to NULL explicitly
* define plane format array in global scope
The implementation of ast_set_vbios_mode() converts a DRM display mode
and framebuffer into an adjusted mode and stores information for the
video BIOS to several scratch regsiters.
Here we split the function into individual functions that do the
conversion, set the VBIOS mode information and format information.
This makes it compatible with support for primary planes and atomic
modesetting.
drm/ast: Split ast_set_ext_reg() into color and threshold function
In ast_set_ext_reg() sets several framebuffer options and CRT threshold
parameters. The former is mostly state of the primary plane; the latter
is constant. Hence, split the function in two and make it work with
atomic modesetting.
drm/ast: Don't clear base address and offset with default values
The content of the base-address and offset registers are state of
the primary plane. Clearing it to default values will interfere with
plane functions for atomic mode setting.
drm/ast: Check video-mode requirements against VRAM size
Each video mode's primary plane requires a minimum amount of video
memory. For double buffering, this is at most half the available
VRAM. Check this constraint.
drm/ast: Remove last traces of struct ast_gem_object
The ast driver has switched to struct drm_vram_gem_object a while ago.
This patch removes a function and forward declaration that were forgotten
before.
projects / mirror_ubuntu-hirsute-kernel.git / log