- 12 Nov, 2018 2 commits
-
-
Chris Wilson authored
We need to include the revert of commit 783195ec ("drm/syncobj: disable the timeline UAPI for now v2") along with undoing the change to drm/i915. Fixes: 131280a1 ("drm: Revert syncobj timeline changes.") Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chunming Zhou <david1.zhou@amd.com> Cc: Eric Anholt <eric@anholt.net> Cc: Joonas Lahtinen <joonas.lahtinen@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> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181112152130.12275-1-chris@chris-wilson.co.uk
-
Eric Anholt authored
Daniel suggested I submit this, since we're still seeing regressions from it. This is a revert to before 48197bc5 ("drm: add syncobj timeline support v9") and its followon fixes. Fixes this on first V3D testcase execution: [ 48.767088] ============================================ [ 48.772410] WARNING: possible recursive locking detected [ 48.777739] 4.19.0-rc6+ #489 Not tainted [ 48.781668] -------------------------------------------- [ 48.786993] shader_runner/3284 is trying to acquire lock: [ 48.792408] ce309d7f (&(&array->lock)->rlock){....}, at: dma_fence_add_callback+0x30/0x23c [ 48.800714] [ 48.800714] but task is already holding lock: [ 48.806559] c5952bd3 (&(&array->lock)->rlock){....}, at: dma_fence_add_callback+0x30/0x23c [ 48.814862] [ 48.814862] other info that might help us debug this: [ 48.821410] Possible unsafe locking scenario: [ 48.821410] [ 48.827338] CPU0 [ 48.829788] ---- [ 48.832239] lock(&(&array->lock)->rlock); [ 48.836434] lock(&(&array->lock)->rlock); [ 48.840640] [ 48.840640] *** DEADLOCK *** [ 48.840640] [ 48.846582] May be due to missing lock nesting notation [ 130.763560] 1 lock held by cts-runner/3270: [ 130.767745] #0: 7834b793 (&(&array->lock)->rlock){-...}, at: dma_fence_add_callback+0x30/0x23c [ 130.776461] stack backtrace: [ 130.780825] CPU: 1 PID: 3270 Comm: cts-runner Not tainted 4.19.0-rc6+ #486 [ 130.787706] Hardware name: Broadcom STB (Flattened Device Tree) [ 130.793645] [<c021269c>] (unwind_backtrace) from [<c020db1c>] (show_stack+0x10/0x14) [ 130.801404] [<c020db1c>] (show_stack) from [<c0c2c4b0>] (dump_stack+0xa8/0xd4) [ 130.808642] [<c0c2c4b0>] (dump_stack) from [<c0281a84>] (__lock_acquire+0x848/0x1a68) [ 130.816483] [<c0281a84>] (__lock_acquire) from [<c02835d8>] (lock_acquire+0xd8/0x22c) [ 130.824326] [<c02835d8>] (lock_acquire) from [<c0c49948>] (_raw_spin_lock_irqsave+0x54/0x68) [ 130.832777] [<c0c49948>] (_raw_spin_lock_irqsave) from [<c086bf54>] (dma_fence_add_callback+0x30/0x23c) [ 130.842183] [<c086bf54>] (dma_fence_add_callback) from [<c086d4c8>] (dma_fence_array_enable_signaling+0x58/0xec) [ 130.852371] [<c086d4c8>] (dma_fence_array_enable_signaling) from [<c086c00c>] (dma_fence_add_callback+0xe8/0x23c) [ 130.862647] [<c086c00c>] (dma_fence_add_callback) from [<c06d8774>] (drm_syncobj_wait_ioctl+0x518/0x614) [ 130.872143] [<c06d8774>] (drm_syncobj_wait_ioctl) from [<c06b8458>] (drm_ioctl_kernel+0xb0/0xf0) [ 130.880940] [<c06b8458>] (drm_ioctl_kernel) from [<c06b8818>] (drm_ioctl+0x1d8/0x390) [ 130.888782] [<c06b8818>] (drm_ioctl) from [<c03a4510>] (do_vfs_ioctl+0xb0/0x8ac) [ 130.896187] [<c03a4510>] (do_vfs_ioctl) from [<c03a4d40>] (ksys_ioctl+0x34/0x60) [ 130.903593] [<c03a4d40>] (ksys_ioctl) from [<c0201000>] (ret_fast_syscall+0x0/0x28) Cc: Chunming Zhou <david1.zhou@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
-
- 09 Nov, 2018 5 commits
-
-
Boris Brezillon authored
The HVS spec recommends using PPF when the downscaling ratio is between 2/3 and 1. Let's modify vc4_get_scaling_mode() to follow this recommendation. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by:
-
Boris Brezillon authored
For the YUV conversion to work properly, ->x_scaling[1] should never be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE into VC4_SCALING_PPF when that happens. The old ->x_scaling[0] adjustment is dropped as I couldn't find any mention to this constraint in the spec and it's proven to be unnecessary (I tested various multi-planar YUV formats with scaling disabled, and all of them worked fine without this adjustment). Fixes: fc04023f ("drm/vc4: Add support for YUV planes.") Signed-off-by:
-
Paul Kocialkowski authored
Some panels need an active-low data enable (DE) signal for the RGB interface. This requires flipping a bit in the TCON0 polarity register when setting up the mode for the RGB interface. Match the associated bus flag and use it to set the polarity inversion bit for the DE signal when required. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181107181843.27628-4-contact@paulk.fr
-
Paul Kocialkowski authored
Features such as dithering and pixel data edge configuration currently rely on the panel registered with the TCON driver. However, bridges are also supported in addition to panels for RGB setup. Instead of retrieving the connector from the panel, get it from the encoder with the dedicated helper. Even in the case of bridges, the connector is registered with the encoder from our driver and is accessible when iterating connectors. Signed-off-by:
-
Paul Kocialkowski authored
Passing the encoder to the TCON RGB setup functions allows accessing the connector from the encoder directly instead of relying on the panel. Signed-off-by:
-
- 08 Nov, 2018 1 commit
-
-
Christian König authored
Until we have sorted out all problems. v2: return -EINVAL during create if flag is set. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/260937/
-
- 07 Nov, 2018 3 commits
-
-
Ville Syrjälä authored
Convert drm_atomic_plane_check() over to using explicit old vs. new plane states. Avoids the confusion of "what does plane->state mean again?". v2: Stick to the multi-stage logic in plane_switching_crtc() (Daniel) Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Convert drm_atomic_crtc_check() over to using explicit old vs. new crtc states. Avoids the confusion of "what does crtc->state mean again?". Signed-off-by:
-
Ville Syrjälä authored
Replace 'crtc->state' with the explicit old crtc state. Actually it shouldn't matter whether we use the old or the new crtc state here since any plane that has been removed from the crtc since the crtc state was duplicated will have been added to the atomic state already. That is, you can't call drm_atomic_set_crtc_for_plane() without having the new plane state already in hand. Signed-off-by:
Harry Wentland <harry.wentland@amd.com>
-
- 06 Nov, 2018 5 commits
-
-
Ville Syrjälä authored
Add a function to check whether there is at least one plane that supports a specific format and modifier combination. Drivers can use this to reject unsupported formats/modifiers in .fb_create(). v2: Accept anyformat if the driver doesn't do planes (Eric) s/planes_have_format/any_plane_has_format/ (Eric) Check the modifier as well since we already have a function that does both v3: Don't do the check in the core since we may not know the modifier yet, instead export the function and let drivers call it themselves Cc: Eric Anholt <eric@anholt.net> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181029183453.28541-1-ville.syrjala@linux.intel.com
-
Daniel Vetter authored
It's lockless, and userspace might chance it underneath us. That's not really a problem, all userspace gets is a slightly dysfunctional lease with the current code. But this might change, and gcc might decide to reload a few too many times, and then boom. So better safe than sorry. v2: Remove the now unused lessor_priv argument from validate_lease() (Keith). v3: Actually add everything ... silly me. Cc: Keith Packard <keithp@keithp.com> Cc: Dave Airlie <airlied@gmail.com> Acked-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181105101211.22737-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
This essentially undoes commit 39868bd7 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Oct 29 08:55:58 2013 +0000 drm: Compact booleans within struct drm_file We do lockless access to these flags everywhere, and it's kinda not a great idea to mix lockless and bitfields. Aside from that gcc isn't generating great code for these. If this ever becomes an issue size-wise, I think we need atomic_t here and atomic bitflag ops. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Acked-by:
-
Daniel Vetter authored
I spent a bit of time scratching heads and figuring out why the igts don't work. Probably useful to keep this work. Cc: Keith Packard <keithp@keithp.com> Cc: Dave Airlie <airlied@gmail.com> Acked-by:
-
Eric Anholt authored
This broke rendering on V3D, where we almost always have a 0 in-syncobj. Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Acked-by:
-
- 05 Nov, 2018 22 commits
-
-
Imre Deak authored
Fix typo in struct field initializer. Fixes: 3a6eb795 ("drm/vgem: create a render node for vgem") Cc: Emil Velikov <emil.velikov@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181105145428.5590-1-imre.deak@intel.com
-
Emil Velikov authored
VGEM doesn't do anything modeset specific, so in a way exposing a primary node is 'wrong'. At the same time, we extensively use if for creating dumb buffers, fences, prime fd <> handle imports/exports. To the point that we explicitly annotate the vgem fence ioctls as DRM_RENDER_ALLOW and have an IGT test which opens the render node. close(drm_open_driver_render(DRIVER_VGEM)) Better late than never, let's flip the switch. Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Icenowy Zheng authored
The TCON TOP on Allwinner H6 SoC is a cut down version of the R40 TCON TOP, which dropped TCON_TV1 and DSI (which do not exist on H6). Add support for it. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Signed-off-by:
-
Icenowy Zheng authored
Allwinner H6 SoC has a cut down version of TCON TOP. Add binding documentation for it. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Icenowy Zheng authored
Some SoCs, such as H6, doesn't have a full-featured TCON TOP. Add quirks support for TCON TOP. Currently the presence of TCON_TV1 and DSI is controlled via the quirks structure. Acked-by:
-
Jernej Skrabec authored
It turns out that TCON TOP registers in H6 SoC have non-zero reset value. This may cause issues if bits are not changed during configuration. To prevent that, initialize registers to 0. Signed-off-by:
-
Jernej Skrabec authored
H6 has Synopsys DWC HDMI 2.0 TX PHY. There is no freely available documentation for it, only code found in BSP kernel. However, judging by the code, PHY is very similar to older Synopsys HDMI PHY described in i.MX6 documentation. Most registers seem to be the same. According to i.MX6 documentation, mpll settings are based on pixel clock and are not specific to each SoC. Because of that, mpll table in this commit is based on that documentation and not on BSP code. Other PHY settings were derived from BSP PHY driver code. Signed-off-by:
-
Jernej Skrabec authored
Currently sun8i-hdmi-phy driver supports only custom PHYs connected to DW HDMI controller. Since newest Allwinner SoCs have unmodified Synopsys PHY, driver has to be reorganized to support them. Variant structure is expanded to allow differentiation between custom and Sysnopsys PHYs and to hold Synopsys PHY settings. Since DW HDMI bridge platform data has different fields for custom and Sysnopsys PHY, function sun8i_hdmi_phy_get_ops() is replaced with sun8i_hdmi_phy_set_ops(). Signed-off-by:
-
Jernej Skrabec authored
Currently, quirks and compatibles are sorted alphabetically. However, they should be sorted by family release date and then alphabetically. Fix that by moving A64 quirks and compatible to bottom. No functional change is made. Signed-off-by:
-
Jernej Skrabec authored
H6 has DW HDMI 2.0b controller v2.12a. It supports 4K at 60 Hz and HDCP 2.2. Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Icenowy Zheng authored
The Allwinner H6 SoC uses a v2.12a DesignWare HDMI controller, with dedicated CEC and HDCP clocks added; the PHY connected is a standard DesignWare HDMI PHY. Add binding for it. Reviewed-by:
-
Jernej Skrabec authored
It turns out that H6 HDMI BSP kernel driver doesn't change TMDS rate at all. At this point it is not clear whether it is just not necessary or it would cause some kind of issues. Add a quirk for it. Acked-by:
-
Jernej Skrabec authored
Since it is not possible to access sun8i-dw-hdmi driver private data inside mode_valid function, make it configurable. That way different versions of HDMI controllers can set different function, depending on it's limitations. Reviewed-by:
-
Jernej Skrabec authored
Currently supported Allwinner SoCs with DW HDMI controller have scrambled addresses and read lock. However, that is not true in general. For example, A80 and H6 have normal addresses and normal read access. Move code for unscrambling addresses and unlocking read access to it's own function and call it from init function. Reviewed-by:
-
Jernej Skrabec authored
It turns out that even new DW HDMI controllers exhibits same magenta line issues as older versions. Enable workaround for v2.12a. Reviewed-by:
-
Jernej Skrabec authored
Mixer 0 has 1 VI and 3 UI planes, scaler on all planes and can output 4K image @60Hz. It also support 10 bit colors, which are not yet implemented. Reviewed-by:
-
Jernej Skrabec authored
Display Engine 3 is an upgrade of DE2 with new features like support for 10 bit color formats and support for AFBC. Most of DE2 code works with DE3, except some small details. Implement basic support for DE3. Support for 10 bit colort formats and AFBC, among others missing features, will be added later. Signed-off-by:
-
Jernej Skrabec authored
Some sub-engines are unused. Disable them explicitly. Signed-off-by:
-
Jernej Skrabec authored
DE2 mixer is always 0x6000 bytes in size on all known SoCs. While at it, introduce a macro for that. Signed-off-by:
-
Jernej Skrabec authored
Most, if not all, registers found in DE2 still exists in DE3. However, units are on different base addresses. To prepare for addition of DE3 support, registers macros are reworked so they take base address as parameter. Signed-off-by:
-
Jernej Skrabec authored
This commit adds compatibles used in H6 display pipeline, namely for display engine, mixer and TV TCON. H6 display engine is somewhat similar to R40, just less TCONs and mixer support more features. Reviewed-by:
-
Icenowy Zheng authored
The Allwinner H6 DE3 bus is similar to the A64 DE2 one. Add its compatible string with the A64 string as fallback to the binding. Some description of the binding is modified to make it more generic. Reviewed-by:
-
- 02 Nov, 2018 2 commits
-
-
Daniel Vetter authored
Leases are entirely implemented within drm.ko, no need to even tempt drivers into doing nasty things. And if there's really a need, we can always re-export these again. Cc: Keith Packard <keithp@keithp.com> Cc: Dave Airlie <airlied@gmail.com> Acked-by:
-
Alexandru-Cosmin Gheorghe authored
It seems for some random configuration drm_device is bigger than 2048 bytes. The fix is to make the mock objects static variables. Bug reported by 0-DAY Kernel test infrastructure here: https://lists.01.org/pipermail/kbuild-all/2018-November/054431.html Fixes: 6ff3d9ff ("drm/selftests: Add tests for drm_internal_framebuffer_create") Signed-off-by:
Alexandru-Cosmin Gheorghe <alexandru-cosmin.gheorghe@arm.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181102130103.7753-1-alexandru-cosmin.gheorghe@arm.com
-
