OSDN Git Service
Christian König [Mon, 28 May 2018 09:47:52 +0000 (11:47 +0200)]
dma_buf: remove device parameter from attach callback v2
The device parameter is completely unused because it is available in the
attachment structure as well.
v2: fix kerneldoc as well
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/226643/
Daniel Vetter [Thu, 5 Apr 2018 15:44:48 +0000 (17:44 +0200)]
drm/vc4: Always obey implicit sync
Same justification as for drm_gem_fb_prepare_fb.
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-9-daniel.vetter@ffwll.ch
Link: https://patchwork.freedesktop.org/patch/msgid/20180409085134.27321-1-daniel.vetter@ffwll.ch
Daniel Vetter [Thu, 5 Apr 2018 15:44:47 +0000 (17:44 +0200)]
drm/gem-fb-helper: Always do implicit sync
I've done a lot of history digging. The first signs of this
optimization was introduced in i915:
commit
25067bfc060d1a481584dcb51ef4b5680176ecb6
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date: Wed Sep 10 12:03:17 2014 -0300
drm/i915: pin sprite fb only if it changed
without much justification. Pinning already pinned stuff is real cheap
(it's just obj->pin_count++ really), and the missing implicit sync was
entirely forgotten about it seems. It's at least not mentioned
anywhere it the commit message.
It was also promptly removed shortly afterwards in
commit
ea2c67bb4affa84080c616920f3899f123786e56
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Dec 23 10:41:52 2014 -0800
drm/i915: Move to atomic plane helpers (v9)
again without really mentioning the side-effect that plane updates
with the same fb now again obey implicit syncing.
Note that this only ever applied to the plane_update hook, all other
legacy entry points (set_base, page_flip) always obeyed implicit sync
in the drm/i915 driver.
The real source of this code here seems to be msm, copied to vc4, then
copied to tinydrm. I've also tried to dig around in all available msm
sources, but the corresponding check for fb != old_fb is present ever
since the initial merge in
commit
cf3a7e4ce08e6876cdcb80390876647f28a7cf8f
Author: Rob Clark <robdclark@gmail.com>
Date: Sat Nov 8 13:21:06 2014 -0500
drm/msm: atomic core bits
The only older version I've found of msm atomic code predates the
atomic helpers, and so didn't even use any of this. It also does not
have a corresponding check (because it simply did no implicit sync at
all).
I've chatted with Rob on irc, and he didn't remember the reason for
this either.
Note we had epic amounts of fun with too much syncing against
_vblank_, especially around cursor updates. But I don't ever
discussing a need for less syncing against implicit fences.
Also note that explicit fencing allows you to sidetrack all of this,
at least for all the drivers correctly implemented using
drm_atomic_set_fence_for_plane().
Given that it seems to be an accident of history, and that big drivers
like i915 (and also nouveau it seems, I didn't follow the
amdgpu/radeon sync code to figure this out properly there) never have
done it, let's remove this.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-8-daniel.vetter@ffwll.ch
Sandy Huang [Tue, 12 Jun 2018 13:20:28 +0000 (15:20 +0200)]
drm/rockchip: vop: fix irq disabled after vop driver probed
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
For this we can simply check the power-domain state of the vop,
similar to how the iommu driver does it.
So remove the enable/disable handling and add appropriate condition
to the irq handler.
changes in v2:
- move to just check the power-domain state
- add clock handling
changes in v3:
- clarify comment to speak of runtime-pm not power-domain
changes in v4:
- address Marc's comments (clk-enable WARN_ON and style improvement)
Fixes:
d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc: stable@vger.kernel.org
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-3-heiko@sntech.de
Heiko Stuebner [Tue, 12 Jun 2018 13:20:27 +0000 (15:20 +0200)]
drm/rockchip: vop: split out core clock enablement into separate functions
Judging from the iommu code, both the hclk and aclk are necessary for
register access. Split them off into separate functions from the regular
vop enablement, so that we can use them elsewhere as well.
Fixes:
d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
[prerequisite change for the actual fix]
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-2-heiko@sntech.de
Haneen Mohammed [Fri, 25 May 2018 01:25:55 +0000 (04:25 +0300)]
drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers
This patch add checks for atomic_[duplicate/destroy]_state of
drm_[connector/crtc/plane]_funcs for atomic drivers in the relevant
drm_*_init functions since these callback are mandatory for atomic drivers.
Update the kerneldoc comments for those callbacks.
Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525012555.GA8448@haneen-vb
Lin Huang [Tue, 22 May 2018 08:53:41 +0000 (16:53 +0800)]
drm/rockchip: cnd-dp: adjust spdif register setting
We use jitter bypass mode for spdif, so do not need to set jitter mode
related bit in SPDIF_CTRL_ADDR register. But of course we need to keep
the SPDIF_ENABLE bit.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1526979222-32478-1-git-send-email-hl@rock-chips.com
Julia Lawall [Wed, 23 May 2018 19:07:16 +0000 (21:07 +0200)]
drm/rockchip: lvds: add missing of_node_put
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
// </smpl>
Fixes:
34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Cc: stable@vger.kernel.org
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1527102436-13447-6-git-send-email-Julia.Lawall@lip6.fr
Alexandru Gheorghe [Wed, 30 May 2018 17:30:52 +0000 (18:30 +0100)]
drm/atomic: Set current atomic state in drm_private_state
drm_private_state has a back pointer to the drm_atomic_state,
however that was not initialized in drm_atomic_get_private_obj_state
after duplication, as it is the case for other drm atomic getters
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527701452-1934-1-git-send-email-alexandru-cosmin.gheorghe@arm.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Ville Syrjälä [Mon, 11 Jun 2018 19:34:02 +0000 (22:34 +0300)]
drm: Print bad user modes
Print out the modeline when we reject a bad user mode. Avoids having to
guess why it was rejected.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-2-ville.syrjala@linux.intel.com
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Ville Syrjälä [Mon, 11 Jun 2018 19:34:01 +0000 (22:34 +0300)]
drm/atomic: Improve debug messages
Print the id/name of the object we're dealing with. Makes it easier to
figure out what's going on. Also toss in a few extra debug prints that
might be useful.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-1-ville.syrjala@linux.intel.com
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Inki Dae [Thu, 24 May 2018 09:32:59 +0000 (18:32 +0900)]
drm/bridge: sil_sii8620: do not have a dependency of RC_CORE
This patch makes RC_CORE to be selected with this driver.
sil_sii8620 driver calls remote controller interfaces directly
so RC_CORE should be enabled mandatorily.
And some boards not using remote controller device don't really
need to know that RC_CORE config should be enabled to use sil_sii8620
driver only for HDMI.
Changelog v2:
- select INPUT because compiling will fail without INPUT.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527154379-31886-1-git-send-email-inki.dae@samsung.com
Ville Syrjälä [Fri, 25 May 2018 18:50:45 +0000 (21:50 +0300)]
drm: Stop updating plane->crtc/fb/old_fb on atomic drivers
Stop playing around with plane->crtc/fb/old_fb with atomic
drivers. Make life a lot simpler when we don't have to do the
magic old_fb vs. fb dance around plane updates. That way we
can't risk plane->fb getting out of sync with plane->state->fb
and we're less likely to leak any refcounts as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-14-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:44 +0000 (21:50 +0300)]
drm/vc4: Stop updating plane->fb/crtc
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-13-ville.syrjala@linux.intel.com
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:43 +0000 (21:50 +0300)]
drm/virtio: Stop updating plane->crtc
We want to get rid of plane->crtc on atomic drivers. Stop setting it.
v2: s/fb/crtc/ in the commit message (Gerd)
Cc: David Airlie <airlied@linux.ie>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-12-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:42 +0000 (21:50 +0300)]
drm/msm: Stop updating plane->fb/crtc
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
v2: Catch a few more cases
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-11-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:41 +0000 (21:50 +0300)]
drm/exynos: Stop updating plane->crtc
We want to get rid of plane->crtc on atomic drivers. Stop setting it.
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-10-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:40 +0000 (21:50 +0300)]
drm/i915: Stop updating plane->fb/crtc
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
v2: Fix up the comment in intel_crtc_active() and
nuke the rest of the stale comments (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-9-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:39 +0000 (21:50 +0300)]
drm/amdgpu/dc: Stop updating plane->fb
We want to get rid of plane->fb on atomic drivers. Stop setting it.
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-8-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:38 +0000 (21:50 +0300)]
drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc
plane->fb/old_fb/crtc should no longer be used by atomic
drivers. Stop messing about with them.
Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-7-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:37 +0000 (21:50 +0300)]
drm/vmwgfx: Stop using plane->fb in atomic_enable()
Instead of looking at the (soon to be deprecated) plane->fb we'll
examing plane->state->fb instead. We can do this because
vmw_du_crtc_atomic_check() prevents us from enabling a crtc
without the primary plane also being enabled.
Due to that same reason, I'm actually not sure what the checks here are
for NULL fb. If we can't enable the crtc without an enabled plane
we should always have an fb. But I'll leave that for someone else
to figure out.
Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-6-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:36 +0000 (21:50 +0300)]
drm/vmwgfx: Stop updating plane->fb
We want to get rid of plane->fb on atomic drivers. Stop setting it.
Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-5-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:35 +0000 (21:50 +0300)]
drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()
The only caller of vmw_kms_update_implicit_fb() is the page_flip
hook which itself gets called with the plane mutex already held.
Hence we can look at plane->state safely.
v2: Drop the bogus lockdep assert
Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-4-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:34 +0000 (21:50 +0300)]
drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_update()
all pass in the crtc which means we'll never end up in this branch
of the function. All other callers use drm_modeset_lock_all() somewhere
higher up, which means accessing plane->state is safe.
v2: Drop the comment and make the code do what it did before (Thomas)
v3: Drop the bogus lockdep assert
Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-3-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:33 +0000 (21:50 +0300)]
drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()
Instead of looking at plane->fb let's look at the proper new
plane state.
Not that the code makes a ton of sense. It's only going through the
crtcs in the atomic state, so assuming not all of them are included
we're not even calculating the total bandwidth here. Also we're
not considering whether each crtc is actually enabled or not.
Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-2-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Lubosz Sarnecki [Tue, 29 May 2018 11:52:15 +0000 (13:52 +0200)]
drm/edid: Quirk Vive Pro VR headset non-desktop.
This adds the Vive Pro's EDID information and
sets EDID_QUIRK_NON_DESKTOP.
Signed-off-by: Lubosz Sarnecki <lubosz.sarnecki@collabora.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: <stable@vger.kernel.org> # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20180529115215.4526-1-lubosz.sarnecki@collabora.com
Gerd Hoffmann [Tue, 29 May 2018 13:59:18 +0000 (15:59 +0200)]
dma-buf: make map_atomic and map function pointers optional
So drivers don't need dummy functions just returning NULL.
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180529135918.19729-1-kraxel@redhat.com
Dave Stevenson [Fri, 16 Mar 2018 22:04:35 +0000 (15:04 -0700)]
drm/vc4: Add support for SAND modifier.
This is the format generated by VC4's H.264 engine, and preferred by
the ISP as well. By displaying SAND buffers directly, we can avoid
needing to use the ISP to rewrite the SAND H.264 output to linear
before display.
This is a joint effort by Dave Stevenson (who wrote the initial patch
and DRM demo) and Eric Anholt (drm_fourcc.h generalization, safety
checks, RGBA support).
v2: Make the parameter macro give all of the middle 48 bits (suggested
by Daniels). Fix fourcc_mod_broadcom_mod()'s bits/shift being
swapped. Mark NV12/21 as supported, not YUV420.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Daniel Stone <daniels@collabora.com> (v1)
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-3-eric@anholt.net
Eric Anholt [Fri, 16 Mar 2018 22:04:34 +0000 (15:04 -0700)]
drm/vc4: Add missing formats to vc4_format_mod_supported().
Daniel's format_mod_supported() patch predated Dave's for NV21/61, and
I didn't catch that when rebasing. This is a problem since the
formats are now getting validated before being passed to the driver's
atomic hooks.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.org>
Fixes:
423ad7b3cbd1 ("drm/vc4: Advertise supported modifiers for planes")
Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-2-eric@anholt.net
Eric Anholt [Fri, 16 Mar 2018 22:04:33 +0000 (15:04 -0700)]
drm: Trust format_mod_supported() when it OKs a plane modifier.
For parameterized modifiers (Broadcom's SAND and UIF), we need to
allow the parameter fields to be filled in, while exposing only the
variant of the modifier with the parameter unfilled in the internal
arrays and the format blob.
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-1-eric@anholt.net
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Ville Syrjälä [Fri, 18 May 2018 16:21:59 +0000 (19:21 +0300)]
drm/i915: Promote .format_mod_supported() to the lead role
Up to now we've used the plane's modifier list as the primary
source of information for which modifiers are supported by a
given plane. In order to allow auxiliary metadata to be embedded
within the bits of the modifier we need to stop doing that.
Thus we have to make .format_mod_supported() aware of the plane's
capabilities and gracefully deal with any modifier being passed
in directly from userspace.
v2: Rebase after NV12
Simplify
Cc: Eric Anholt <eric@anholt.net>
References: https://lists.freedesktop.org/archives/dri-devel/2018-March/169782.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518162159.30305-1-ville.syrjala@linux.intel.com
Reviewed-by: Eric Anholt <eric@anholt.net>
Lukasz Majewski [Mon, 14 May 2018 19:08:49 +0000 (21:08 +0200)]
display: panel: Add AUO g070vvn01 display support (800x480)
This commit adds support for AUO's 7.0" display.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180514190849.18723-1-lukma@denx.de
Souptick Joarder [Thu, 10 May 2018 13:42:04 +0000 (19:12 +0530)]
gpu: drm: drm_vm: Adding new typedef vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
commit
1c8f422059ae ("mm: change return type to vm_fault_t")
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180510134203.GA25166@jordon-HP-15-Notebook-PC
Daniel Vetter [Thu, 24 May 2018 09:01:05 +0000 (11:01 +0200)]
drm/fb-helper: Fix typo on kerneldoc
Copypasta mistake.
Fixes:
742547b73d27 ("drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs")
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524090105.21196-1-daniel.vetter@ffwll.ch
Arnd Bergmann [Fri, 25 May 2018 15:50:08 +0000 (17:50 +0200)]
drm/sun4i: mark PM functions as __maybe_unused
Disabling CONFIG_PM produces a compile time warning when these
functions are not referenced:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function]
static int sun6i_dsi_runtime_suspend(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1043:12: error: 'sun6i_dsi_runtime_resume' defined but not used [-Werror=unused-function]
static int sun6i_dsi_runtime_resume(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~
Fixes:
133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525155030.3667352-1-arnd@arndb.de
Ville Syrjälä [Thu, 5 Apr 2018 15:13:57 +0000 (18:13 +0300)]
drm/atmel-hlcdc: Stop using plane->fb
We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Daniel pointed out that the drm_framebuffer_put() in the plane cleanup
indicates that the driver doesn't shut things down cleanly. To do
that we should be able to just call drm_atomic_helper_shutdown(). Not
really sure the current cleanup sequence is actually sane, but whatever.
v2: Replace the drm_framebuffer_put() with
drm_atomic_helper_shutdown() (Daniel)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-10-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Apr 2018 15:13:58 +0000 (18:13 +0300)]
drm/omapdrm: Nuke omap_framebuffer_get_next_connector()
omap_framebuffer_get_next_connector() uses plane->fb which we want to
deprecate for atomic drivers. As omap_framebuffer_get_next_connector()
is unused just nuke the entire function.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-11-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Ville Syrjälä [Thu, 5 Apr 2018 15:14:00 +0000 (18:14 +0300)]
drm: Add local 'plane' variable for tmp->primary
Clean up the ugly tmp->primary-> stuff in
__drm_mode_set_config_internal() with a local plane variable.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-13-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Apr 2018 15:13:50 +0000 (18:13 +0300)]
drm/atmel-hlcdc: Stop consulting plane->crtc
We want to get rid of plane->crtc on atomic drivers. Stop looking at it.
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-3-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Apr 2018 15:13:49 +0000 (18:13 +0300)]
drm/sti: Stop consulting plane->crtc
We want to get rid of plane->crtc on atomic drivers. Stop looking at it.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Apr 2018 15:13:48 +0000 (18:13 +0300)]
drm/msm: Stop consulting plane->fb/crtc
We want to get rid of plane->fb/crtc on atomic drivers. Stop
looking at them.
v2: Catch the plane->crtc case too
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 5 Apr 2018 19:50:29 +0000 (22:50 +0300)]
drm/arc: Stop consulting plane->fb
We want to stop using plane->fb with atomic driver, so stop looking at
it.
I have no idea what this code is trying to achieve. There is no
corresponding check in the enable path. Also since
arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going
to assuming that I can just remove the check entirely. There seems
to be a general shortage of .atomic_check() in this driver...
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405195035.24722-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alexey Brodkin <abrodkin@synopys.com>
Ville Syrjälä [Thu, 24 May 2018 19:20:35 +0000 (22:20 +0300)]
drm/edid: Fix up edid_cea_modes[] formatting
Fix up a bunch of bad indentation and insconsistent comments
in edid_cea_modes[].
v2: Instead of stripping the aspect ratio comments let's
add them to all modes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524192035.9776-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Oleksandr Andrushchenko [Wed, 23 May 2018 11:36:30 +0000 (14:36 +0300)]
drm/xen-front: fix pointer casts
Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t first.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180523113630.29811-1-andr2000@gmail.com
Chris Wilson [Mon, 21 May 2018 08:21:31 +0000 (09:21 +0100)]
drm/i915: Pin the ring high
If we can use an unmappable ring, try to pin it out of the mappable
aperture. This simple layout preference is to try and keep the mappable
aperture reserved and available to handle GGTT mmapping requests from
userspace without causing evictions and GPU stalls.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-4-chris@chris-wilson.co.uk
Chris Wilson [Mon, 21 May 2018 08:21:30 +0000 (09:21 +0100)]
drm/i915: Limit searching for PIN_HIGH
To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
times), doing a search by address over a pathologically fragmented
address space is exceeding slow. To protect ourselves from nearly
unbounded latency (think searching a million holes while under
struct_mutex), limit the search for the highest available hole and
fallback to best-fit if it fails.
In the pathologically fragmented case, such as igt/gem_ctx_thrash, the
effect is dramatic, bringing the runtime down from hours to seconds
(depending on how many other slow searches you hit, e.g. alloc_iova()
and alloc_vmap_area() both degrade to a slow rbtree walk after their
small cache is exhausted). For the real world, the number of search
steps is unlikely to be significant as we should only need to search
once per new context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-3-chris@chris-wilson.co.uk
Chris Wilson [Mon, 21 May 2018 08:21:29 +0000 (09:21 +0100)]
drm/mm: Add a search-by-address variant to only inspect a single hole
Searching for an available hole by address is slow, as there no
guarantee that a hole will be available and so we must walk over all
nodes in the rbtree before we determine the search was futile. In many
cases, the caller doesn't strictly care for the highest available hole
and was just opportunistically laying out the address space in a
preferred order. In such cases, the caller can accept any address and
would rather do so then do a slow walk.
To be able to mix search strategies, the caller wants to tell the drm_mm
how long to spend on the search. Without a good guide for what should be
the best split, start with a request to try once at most. That is return
the top-most (or lowest) hole if it fulfils the alignment and size
requirements.
v2: Documentation, by why of example (selftests) and kerneldoc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 21 May 2018 08:21:28 +0000 (09:21 +0100)]
drm/mm: Reject over-sized allocation requests early
As we keep an rbtree of available holes sorted by their size, we can
very easily determine if there is any hole large enough that might
satisfy the allocation request. This helps when dealing with a highly
fragmented address space and a request for a search by address.
To cache the largest size, we convert into the cached rbtree variant
which tracks the leftmost node for us. However, currently we sorted into
ascending size order so the leftmost node is the smallest, and so to
make it the largest hole we need to invert our sorting.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-1-chris@chris-wilson.co.uk
Souptick Joarder [Mon, 16 Apr 2018 15:02:32 +0000 (20:32 +0530)]
gpu: drm: vgem: Change return type to vm_fault_t
Use new return type vm_fault_t for fault handler.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180416150232.GA26745@jordon-HP-15-Notebook-PC
Souptick Joarder [Wed, 25 Apr 2018 04:59:22 +0000 (10:29 +0530)]
gpu: drm: udl: Adding new typedef vm_fault_t
Use new return type vm_fault_t for fault and huge_fault
handler. For now, this is just documenting that the
function returns a VM_FAULT value rather than an errno.
Once all instances are converted, vm_fault_t will become
a distinct type.
Commit
1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_page() returns err which driver
mapped into VM_FAULT_* type. The new function vmf_
insert_page() will replace this inefficiency by
returning VM_FAULT_* type.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425045922.GA21590@jordon-HP-15-Notebook-PC
Laura Abbott [Wed, 11 Apr 2018 01:03:30 +0000 (18:03 -0700)]
drm/i2c: tda998x: Remove VLA usage
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to this upper bound.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411010330.17866-1-labbott@redhat.com
Laura Abbott [Mon, 9 Apr 2018 21:06:47 +0000 (14:06 -0700)]
drm/gma500: Remove VLA
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a reasonable upper bound for the VLAs in
the gma500 driver.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409210647.3718-1-labbott@redhat.com
Daniel Stone [Mon, 21 May 2018 14:24:49 +0000 (15:24 +0100)]
drm/gma500: Fix Medfield for drm_framebuffer move
Commit
bc61c97502e2 ("drm/gma500: Move GEM BO to drm_framebuffer") moved
the gtt_range structure, from being in psb_framebuffer and embedding the
GEM object, to being placed in the drm_framebuffer with the gtt_range
being derived from the GEM object.
The conversion missed out the Medfield subdriver, which was not being
built in the default drm-misc config. Do the trivial fixup here.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Fixes:
bc61c97502e2 ("drm/gma500: Move GEM BO to drm_framebuffer")
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521142449.20800-1-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:21 +0000 (15:11 +0100)]
drm/omap: Move buffer pitch/offset to drm_framebuffer
drm_framebuffer already holds per-plane pitch and offsets, which is
filled out for us when we create the framebuffer. Nuke our local copy in
the plane struct.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-7-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:20 +0000 (15:11 +0100)]
drm/omap: Move GEM BO to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-6-daniels@collabora.com
Dan Carpenter [Fri, 18 May 2018 08:10:41 +0000 (11:10 +0300)]
drm/v3d: Checking for NULL vs IS_ERR()
The v3d_fence_create() only returns error pointers on error. It never
returns NULL.
Fixes:
57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518081041.GC28335@mwanda
Peter Rosin [Wed, 2 May 2018 07:40:24 +0000 (09:40 +0200)]
drm/rockchip: lvds: avoid duplicating drm_bridge_attach
drm_bridge_attach takes care of these assignments, so there is no need
to open-code them a second time.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502074025.12421-3-peda@axentia.se
Daniel Stone [Fri, 30 Mar 2018 14:11:19 +0000 (15:11 +0100)]
drm/rockchip: rockchip_drm_fb -> drm_framebuffer
Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
can remove it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Heiko Stübner <heiko@sntech.de>
Tested-by: Heiko Stübner <heiko@sntech.de>
Cc: Sandy Huang <hjc@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-5-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:18 +0000 (15:11 +0100)]
drm/rockchip: Place GEM BOs in drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Heiko Stübner <heiko@sntech.de>
Tested-by: Heiko Stübner <heiko@sntech.de>
Cc: Sandy Huang <hjc@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-4-daniels@collabora.com
Daniel Stone [Fri, 18 May 2018 13:47:05 +0000 (14:47 +0100)]
drm/mtk: mtk_drm_fb -> drm_framebuffer
Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
just delete it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-3-daniels@collabora.com
Daniel Stone [Fri, 18 May 2018 13:47:04 +0000 (14:47 +0100)]
drm/mtk: Move GEM BO to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-2-daniels@collabora.com
Daniel Stone [Fri, 18 May 2018 13:47:03 +0000 (14:47 +0100)]
drm/mtk: Remove impossible internal error
We cannot create a framebuffer with no objects, so there's no point
testing for it.
v2: Remove the error entirely. (Sean, CK, Thierry)
Signed-off-by: Daniel Stone <daniels@collabora.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-1-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:35 +0000 (15:11 +0100)]
drm/msm: Move GEM BOs to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-21-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:34 +0000 (15:11 +0100)]
drm/gma500: Move GEM BO to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-20-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:33 +0000 (15:11 +0100)]
drm/armada: Move GEM BO to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Russell King <linux@armlinux.org.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-19-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:17 +0000 (15:11 +0100)]
drm/virtio: Place GEM BOs in drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-3-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:16 +0000 (15:11 +0100)]
drm/cirrus: cirrus_framebuffer -> drm_framebuffer
Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer,
we can drop it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-2-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:15 +0000 (15:11 +0100)]
drm/cirrus: Place GEM BOs in drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-1-daniels@collabora.com
Stefan Agner [Thu, 19 Apr 2018 21:20:03 +0000 (23:20 +0200)]
drm/panel: simple: Fix data type in KEO TX31D200VM0BAA timings
All values in a struct struct timing_entry (every entry in
struct display_timing) require an integer. Choose the closest
safe integer of 32.
This avoids a warning seen with clang:
drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit
conversion from 'double' to 'u32' (aka 'unsigned int')
changes value from 33.5 to 33 [-Wliteral-conversion]
.vfront_porch = { 6, 21, 33.5 },
~ ^~~~
drivers/gpu/drm/panel/panel-simple.c:1251:26: warning: implicit
conversion from 'double' to 'u32' (aka 'unsigned int')
changes value from 33.5 to 33 [-Wliteral-conversion]
.vback_porch = { 6, 21, 33.5 },
~ ^~~~
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419212003.8155-1-stefan@agner.ch
Lucas Stach [Wed, 11 Apr 2018 15:27:41 +0000 (17:27 +0200)]
drm/panel: simple: AUO P320HVN03 uses SPWG data ordering
The patch adding support for the AUO P320HVN03 panel was written against a
preliminary datasheet, which specified JEIDA data ordering. Testing with
real hardware has shown that the actually used data ordering is SPWG.
Fixes:
70c0d5b783f5 (drm/panel: simple: add support for AUO P320HVN03)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411152741.22483-1-l.stach@pengutronix.de
spanda@codeaurora.org [Tue, 15 May 2018 05:52:43 +0000 (11:22 +0530)]
drm/panel: simple: Add Innolux TV123WAM panel driver support
Add support for Innolux TV123WAM, which is a 12.3" eDP display panel
with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526363564-13823-4-git-send-email-spanda@codeaurora.org
spanda@codeaurora.org [Tue, 15 May 2018 05:52:44 +0000 (11:22 +0530)]
dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as done by other existing panel support changes.
Changes in v2:
- Separate driver change from dt-binding documentation (Rob Herring).
- Add the properties from simple-panel binding that are applicable to
this panel (Rob Herring).
Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526363564-13823-5-git-send-email-spanda@codeaurora.org
Thierry Reding [Thu, 26 Apr 2018 13:58:53 +0000 (15:58 +0200)]
drm/bridge: cdns: Mark runtime PM operations as maybe unused
Building the driver in a configuration with !PM currently causes a
warning about these operations being unused. Mark them as such to shut
up the compiler.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426135853.30895-1-thierry.reding@gmail.com
Philippe CORNU [Mon, 23 Apr 2018 14:10:53 +0000 (16:10 +0200)]
drm/panel: otm8009a: Use new backlight API
The backlight API provides new functions to enable and disable the
backlight and which hide the intricacies of achieving the correct
result.
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-5-philippe.cornu@st.com
Philippe CORNU [Mon, 23 Apr 2018 14:10:52 +0000 (16:10 +0200)]
drm/panel: otm8009a: No message if probe success
Remove the message in case of probe success. This comes from a
suggestion followed in the recent integration of the raydium rm68200
panel.
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-4-philippe.cornu@st.com
Philippe CORNU [Mon, 23 Apr 2018 14:10:51 +0000 (16:10 +0200)]
drm/panel: otm8009a: Fix glitches by moving backlight enable to otm8009a_enable()
The backlight 1st update was in the otm8009a_prepare() function for a
bad reason: backlight was not working in video mode and the
otm8009a_prepare() is in command mode for the init sequence. As the
backlight is now fixed (no low-power mode), it is good to put it back
in the otm8009a_enable() function, avoiding also image glitches visible
on some "slow" devices.
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-3-philippe.cornu@st.com
Philippe CORNU [Mon, 23 Apr 2018 14:10:50 +0000 (16:10 +0200)]
drm/panel: otm8009a: Fix backlight updates
Backlight updates was not working anymore since the good implementation
of the DSI low-power mode in the DSI host driver. After a longer
analysis, the backlight updates in DSI video mode require the DSI high-
speed mode.
Note: it is important to keep the DSI low-power mode for the rest of the
driver as init sequence, sleep in/out... DSI commands work in low-power
mode.
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-2-philippe.cornu@st.com
Jyri Sarha [Thu, 26 Apr 2018 08:07:00 +0000 (11:07 +0300)]
drm/panel: Add device_link from panel device to DRM device
Add device_link from panel device (supplier) to DRM device (consumer)
when drm_panel_attach() is called. This patch should protect the master
DRM driver if an attached panel driver unbinds while it is in use. The
device_link should make sure the DRM device is unbound before the panel
driver becomes unavailable.
The device_link is removed when drm_panel_detach() is called. The
drm_panel_detach() should be called by the consumer DRM driver, not the
panel driver, otherwise both drivers are racing to delete the same link.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b53584fd988d045c13de22d81825395b0ae0aad7.1524727888.git.jsarha@ti.com
Jyri Sarha [Thu, 26 Apr 2018 08:06:59 +0000 (11:06 +0300)]
drm/panel: Remove drm_panel_detach() calls from all panel drivers
Remove all drm_panel_detach() calls from all panel drivers and update
the kerneldoc for drm_panel_detach().
Setting the connector and drm to NULL when the DRM panel device is going
away hardly serves any purpose. Usually the whole memory structure is
freed right after the remove call. However, calling the detach function
from the master DRM device, and setting the connector pointer to NULL,
has the logic of marking the panel again as available for another DRM
master to attach. The usual situation would be the same DRM master
device binding again.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/464b8d330d6b4c94cfb5aad2ca9ea7eb2c52d934.1524727888.git.jsarha@ti.com
Stanislav Lisovskiy [Tue, 15 May 2018 13:59:28 +0000 (16:59 +0300)]
i915: content-type property for HDMI connector
Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.
This requires also manipulationg ITC bit, as stated in
HDMI spec.
v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.
v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.
v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.
v5:
* Moved patch revision's description to commit messages.
v6:
* Minor naming fix for the content type enumeration string.
v7:
* Fix parameter name for documentation and parameter alignment
in order not to get warning. Added Content Type description to
new HDMI connector properties section.
v8:
* Thrown away unneeded numbers from HDMI content-type property
description. Switch to strings desription instead of plain
definitions.
v9:
* Moved away hdmi specific content-type enum from
drm_connector_state. Content type property should probably not
be bound to any specific connector interface in
drm_connector_state.
Same probably should be done to hdmi_picture_aspect_ration enum
which is also contained in drm_connector_state. Added special
helper function to get derive hdmi specific relevant infoframe
fields.
v10:
* Added usage description to HDMI properties kernel doc.
v11:
* Created centralized function for filling HDMI AVI infoframe, based
on correspondent DRM property value.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-3-stanislav.lisovskiy@intel.com
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Stanislav Lisovskiy [Tue, 15 May 2018 13:59:27 +0000 (16:59 +0300)]
drm: content-type property for HDMI connector
Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.
v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.
v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.
v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.
v5:
* Moved patch revision's description to commit messages.
v6:
* Minor naming fix for the content type enumeration string.
v7:
* Fix parameter name for documentation and parameter alignment
in order not to get warning. Added Content Type description to
new HDMI connector properties section.
v8:
* Thrown away unneeded numbers from HDMI content-type property
description. Switch to strings desription instead of plain
definitions.
v9:
* Moved away hdmi specific content-type enum from
drm_connector_state. Content type property should probably not
be bound to any specific connector interface in
drm_connector_state.
Same probably should be done to hdmi_picture_aspect_ration enum
which is also contained in drm_connector_state. Added special
helper function to get derive hdmi specific relevant infoframe
fields.
v10:
* Added usage description to HDMI properties kernel doc.
v11:
* Created centralized function for filling HDMI AVI infoframe, based
on correspondent DRM property value.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Philippe Cornu [Tue, 15 May 2018 20:37:36 +0000 (22:37 +0200)]
drm/bridge: spelling and coding style minor fixes
Minor fixes detected with "scripts/checkpatch.pl --strict"
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515203736.9224-1-philippe.cornu@st.com
Maxime Ripard [Thu, 17 May 2018 13:37:59 +0000 (15:37 +0200)]
drm/vc4: plane: Expand the lower bits by repeating the higher bits
The vc4 HVS uses an internal RGB888 representation of the frames, and will
by default expand formats using a lower depth using zeros.
This causes an issue when we try to use other compositing software such as
pixman that fill the missing bits by repeating the higher significant bits.
As such, we can't check the display output in a reliable way by doing a
software composition and an hardware one and compare both.
To prevent this, force the same behaviour so that we can do such things.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517133759.25626-1-maxime.ripard@bootlin.com
Philippe Cornu [Mon, 9 Apr 2018 15:24:27 +0000 (17:24 +0200)]
drm: clarify adjusted_mode documentation for bridges
This patch clarifies the adjusted_mode documentation
for bridges.
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409152427.12449-1-philippe.cornu@st.com
Colin Ian King [Tue, 15 May 2018 08:54:33 +0000 (09:54 +0100)]
drm/xen-front: fix spelling mistake: "conector" -> "connector"
Trivial fix to spelling mistake in DRM_INFO message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515085433.8245-1-colin.king@canonical.com
Souptick Joarder [Tue, 17 Apr 2018 13:38:44 +0000 (19:08 +0530)]
gpu: drm: qxl: Adding new typedef vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Reference id ->
1c8f422059ae ("mm: change return type to
vm_fault_t")
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180417133844.GA30256@jordon-HP-15-Notebook-PC
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Dave Airlie [Thu, 3 May 2018 02:10:21 +0000 (12:10 +1000)]
drm/virtio: add define for second capset to the virgl code.
Although the kernel doesn't use this, qemu imports these headers
and it's best to keep them consistent.
This define is also something userspace may want to use.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180503021021.10694-1-airlied@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Eric Anholt [Wed, 9 May 2018 00:14:25 +0000 (17:14 -0700)]
drm: Fix render node numbering regression from control node removal.
drm_minor_alloc() does multiplication on this enum, so the removal
ended up moving render nodes down from 128 base to 64. This caused
Mesa's surfaceless backend to be unable to open the render nodes,
since it was still looking up at 128.
v2: Add a comment warning the next person.
Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes:
0d49f303e8a7 ("drm: remove all control node code")
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180509001425.12574-1-eric@anholt.net
Maarten Lankhorst [Fri, 11 May 2018 16:08:10 +0000 (18:08 +0200)]
Merge remote-tracking branch 'drm/drm-next' into drm-misc-next
drm-misc-next is still based on v4.16-rc7, and was getting a bit stale.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Shashank Sharma [Tue, 8 May 2018 11:09:45 +0000 (16:39 +0530)]
drm: Add and handle new aspect ratios in DRM layer
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.
The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org> (V2)
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V2)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-11-git-send-email-ankit.k.nautiyal@intel.com
Shashank Sharma [Tue, 8 May 2018 11:09:44 +0000 (16:39 +0530)]
drm: Add aspect ratio parsing in DRM layer
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).
Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.
link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/
9379057/
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Lin, Jia <lin.a.jia@intel.com>
Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (V2)
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
drm_fb_helper, while trying to find a common mode among connectors
for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-10-git-send-email-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Tue, 8 May 2018 11:09:43 +0000 (16:39 +0530)]
drm: Expose modes with aspect ratio, only if requested
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.
This patch:
-prunes the modes with aspect-ratio information, from the
drm_mode_get_connector modelist supplied to the user, if the
user-space has not set the aspect ratio DRM client cap. However if
such a mode is unique in the list, it is kept in the list, with
aspect-ratio flags reset.
-prepares a list of exposed modes, which is used to find unique modes
if aspect-ratio is not allowed.
-adds a new list_head 'exposed_head' in drm_mode_display, to traverse
the list of exposed modes.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: As suggested by Ville, modified the mechanism of pruning of modes
with aspect-ratio, if the aspect-ratio is not supported. Instead
of straight away pruning such a mode, the mode is retained with
aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
-used a pointer to store last valid mode.
-avoided, modifying of picture_aspect_ratio in kernel mode,
instead only flags bits of user mode are reset (if aspect-ratio
is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
logic to correctly identify and prune modes with aspect-ratio,
if aspect-ratio cap is not set.
V12: As suggested by Ville, added another list_head in
drm_mode_display to traverse the list of exposed modes and
avoided duplication of modes.
V13: Minor modifications, as suggested by Ville.
v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the
pruning logic to avoid any dependency in the order of mode with
aspect-ratio.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Tue, 8 May 2018 11:09:42 +0000 (16:39 +0530)]
drm: Handle aspect ratio info in legacy modeset path
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.
This patch:
1. rejects the modes with aspect-ratio info, during modeset, if the
user does not support aspect ratio.
2. does not load the aspect-ratio info in user-mode structure, if
aspect ratio is not supported.
3. adds helper functions for determining if aspect-ratio is expected
in user-mode and for allowing/disallowing the aspect-ratio, if its
not expected.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: Addressed review comments from Ville:
Do not corrupt the current crtc state by updating aspect-ratio on
the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
aspect ratio, if the user does not set aspect-ratio cap.
V6: Used the helper functions for determining if aspect-ratio is
expected in the user-mode.
V7: rebase
V8: rebase
V9: rebase
V10: Modified the commit-message
V11: rebase
V12: Merged the patch for adding aspect-ratio helper functions
with this patch.
V13: Minor modifications as suggested by Ville.
V14: Removed helper functions, as they were used only once in legacy
modeset path, as suggested by Daniel Vetter.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-8-git-send-email-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Tue, 8 May 2018 11:09:41 +0000 (16:39 +0530)]
drm: Add DRM client cap for aspect-ratio
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.
To avoid this, a new drm client cap is required to enable a non-atomic
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.
This patch adds the client cap for aspect-ratio.
Since no atomic-userspaces blow up on receiving aspect-ratio
information, the client cap for aspect-ratio is always enabled
for atomic clients.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio. Also,
tweaked the comment lines in the code for better understanding and
clarity, as recommended by Shashank Sharma.
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: As suggested by Daniel Vetter and Ville Syrjala,
always enable aspect-ratio client cap for atomic userspaces,
if no atomic userspace breaks on aspect-ratio bits.
V13: rebase
V14: rebase
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-7-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:40 +0000 (16:39 +0530)]
video/hdmi: Reject illegal picture aspect ratios
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: "Lin, Jia" <lin.a.jia@intel.com>
Cc: Akashdeep Sharma <akashdeep.sharma@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-6-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:39 +0000 (16:39 +0530)]
drm/edid: Don't send bogus aspect ratios in AVI infoframes
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-5-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:38 +0000 (16:39 +0530)]
drm/edid: Fix cea mode aspect ratio handling
commit
6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.
Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: "Lin, Jia" <lin.a.jia@intel.com>
Cc: Akashdeep Sharma <akashdeep.sharma@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-4-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:37 +0000 (16:39 +0530)]
drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-3-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:36 +0000 (16:39 +0530)]
drm/modes: Introduce drm_mode_match()
Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-2-git-send-email-ankit.k.nautiyal@intel.com
Andy Shevchenko [Thu, 3 May 2018 18:41:19 +0000 (21:41 +0300)]
drm: panel-orientation-quirks: Convert to use match_string() helper
The new helper returns index of the matching string in an array.
We are going to use it here.
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503184119.22355-1-andriy.shevchenko@linux.intel.com