No dev->struct_mutex anywhere to be seen.
Cc: Tomi Valkeinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 709bc903524d..30
Since my last struct_mutex crusade someone escaped!
This already has the advantage that for the common case when someone
else holds a ref the unref won't even acquire dev->struct_mutex. And
I'm working on code to allow drivers to completely opt-out of any and
all dev->struct_mutex usage, but that
With Benjanim's patch to remove the dev->struct_mutex cargo cult the
sti driver is now also entirely legacy locking free. Let's convert it
too.
Cc: Benjamin Gaignard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sti/sti_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
No dev->struct_mutex anywhere to be seen.
Cc: seanpaul at chromium.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index d61a547fa3c9..1228b4
No dev->struct_mutex anywhere to be seen.
Cc: Gerd Hoffmann
Cc: David Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
in
No dev->struct_mutex anywhere to be seen.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index b7d2ff0e6e1f..13f704de39e1 100644
---
From: Benjamin Gaignard
No need to protect debugfs functions with dev->struct_mutex
Signed-off-by: Benjamin Gaignard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sti/sti_cursor.c | 7 ---
drivers/gpu/drm/sti/sti_drv.c| 6 --
drivers/gpu/drm/sti/sti_dvo.c| 7 ---
dri
No need to reinvent this little wheel.
Cc: Mark Yao
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
i
On Tue, Apr 26, 2016 at 07:20:49PM +0200, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 07:26:21PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 26, 2016 at 04:36:36PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 26, 2016 at 11:14:22AM -0300, Gustavo Padovan wrote:
> > > > 2016-04-26 Ville Syrjä
From: Steve Longerbeam
Add support for reading EDID over Display Data Channel. If no DDC
adapter is available, falls back to hardcoded EDID or display-timings
node as before.
Signed-off-by: Steve Longerbeam
Signed-off-by: Akshay Bhat
Acked-by: Philipp Zabel
---
Hi Philipp,
I found this patc
From: Robert Foss
As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
update is requested and there is an earlier update pending".
This patch is based on the rockchip patch below:
http://article.gmane.org/gmane.comp.video.dri.devel/151678
Signed-off-by: Robert Foss
---
On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 26, 2016 at 07:20:49PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 26, 2016 at 07:26:21PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 26, 2016 at 04:36:36PM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 26, 2016 at
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #21 from Jason Vas Dias ---
Aha! It was :
Section "Device"
Identifier "Intel"
Driver "intel"
Option "Monitor-eDP-1" "eDP-1"
Option "Monitor-DisplayPort-0" "eDP-1"
EndSection
and also :
Section "ServerLayout"
Ident
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #22 from Jason Vas Dias ---
It looks like the Intel driver is actually internally using the Radeon driver?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #23 from Jason Vas Dias ---
Xorg server log of successful session
[ 173.214]
X.Org X Server 1.18.3
Release Date: 2016-04-04
[ 173.214] X Protocol Version 11, Revision 0
[ 173.214] Build Operating System: Linux 4.5.0 x86_64
[
On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 26, 2016 at 07:20:49PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 26, 2016 at 07:26:21PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Apr 26, 2016 at
art --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160426/b107fe48/attachment.html>
On Tue, Apr 26, 2016 at 07:29:42PM +0200, Daniel Vetter wrote:
> Finally all the core gem and a lot of drivers are entirely free of
> dev->struct_mutex depencies, and we can start to have an entirely
> lockless unref path.
>
> To make sure that no one who touches the core code accidentally breaks
On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 26, 2016 at 07:20:49PM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 26, 2016 at
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: Yishai
On Tue, Apr 26, 2016 at 08:47:32PM +0100, Chris Wilson wrote:
> On Tue, Apr 26, 2016 at 07:29:42PM +0200, Daniel Vetter wrote:
> > Finally all the core gem and a lot of drivers are entirely free of
> > dev->struct_mutex depencies, and we can start to have an entirely
> > lockless unref path.
> >
>
On Tue, Apr 26, 2016 at 10:10:14PM +0200, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 08:47:32PM +0100, Chris Wilson wrote:
> > On Tue, Apr 26, 2016 at 07:29:42PM +0200, Daniel Vetter wrote:
> > > Finally all the core gem and a lot of drivers are entirely free of
> > > dev->struct_mutex depencie
The only multi-planar format supported by the driver is NV12, there will
thus never be more than two planes per framebuffer.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_
Hello,
Here's my current stack of pending patches for the omapdrm driver.
The most notable change is the rework of the IRQ handling code (patches 07/23
to 19/23) that, beside simplifying the code, ensures that the vblank count and
timestamp get updated properly in order to be reported to userspac
The number of bits per pixel is identical for all planes, don't store
multiple copies.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_fb.c | 53 ++-
1 file changed, 25 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_
This replaces calls to drm_format_num_planes() by a simple field access
every time we need the number of planes for the frame buffer.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_fb.c | 55 +--
1 file changed, 29 insertions(+), 26 deletions
Merge the single-user objects_lookup inline function into its caller,
allowing reuse of the error code path.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 25 -
drivers/gpu/drm/omapdrm/omap_fb.c | 30 +++---
2 files chan
Checks can be simplified based on the requirement that pitches must be
identical for all planes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_fb.c | 51 ---
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/oma
Don't print userspace parameters validation failures as error messages
to avoid giving userspace the ability to flood the kernel log.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_fb.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu
Instead of going through a complicated registration mechanism, just
call the OCP error IRQ handler directly from the main IRQ handler.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
drivers/gpu/drm/omapdrm/omap_irq.c | 29 +++--
2 files cha
Instead of going through a complicated private IRQ registration
mechanism, handle the vblank interrupt activation with the standard
drm_crtc_vblank_get() and drm_crtc_vblank_put() mechanism. This will let
the DRM core keep the vblank interrupt enabled as long as needed to
update the frame counter.
The IRQ wait functions are called from the DSS enable and disable
operations only, where the DISPC is guaranteed to be enabled. There's no
need for manual DISPC power management there.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_irq.c | 4
1 file changed, 4 deletions(-)
The function is only used in omap_irq.c, move it there and make it
static.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ---
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
drivers/gpu/drm/omapdrm/omap_irq.c | 7 ++-
3 files changed, 6 insertions(+), 9 deletion
As the FIFO underflow IRQ handler just prints an error message to the
kernel log, simplify the code by not registering one IRQ handler per
plane but print the messages directly from the main IRQ handler.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 2 +-
drivers/gp
The omapdrm DSS manager enable/disable operations check the DSS manager
state to avoid double enabling/disabling. Move that code to the DSS
manager to decrease the dependency of the DRM layer to the DSS layer.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 1 -
driver
Instead of going through a complicated registration mechanism, just
expose the CRTC error IRQ function and call it directly from the main
IRQ handler.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 12 ++--
drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
drivers/gp
Instead of conditioning planes update based on the hardware device
state, use the CRTC state stored in the atomic state. This reduces the
dependency from the DRM layer to the DSS layer.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 23 ++-
1 file c
The vblank interrupt is disabled after one occurrence, preventing the
atomic update event from being processed twice. However, this also
prevents the software frame counter from being updated correctly that
would require vblank interrupts to be kept enabled while the CRTC is
active.
In preparation
The flag will need to be accessed atomically in the vblank interrupt
handler, memory barriers won't be enough.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm
The functions are not used outside of their compilation unit, make them
static.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 6 +-
drivers/gpu/drm/omapdrm/omap_irq.c | 27 +++
2 files changed, 8 insertions(+), 25 deletions(-)
diff --git a
Now that the IRQ list is used for IRQ wait only we can merge
omap_drm_irq and omap_irq_wait and simplify the implementation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 17 +--
drivers/gpu/drm/omapdrm/omap_irq.c | 94 ++
2 file
Move the list of pending IRQ wait instances to the omap_drm_private
structure and the wait queue head to the IRQ wait structure.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++-
drivers/gpu/drm/omapdrm/omap_irq.c | 38 --
2 file
The backlight GPIO was supported with platform data only. Now that the
driver only supports DT, the backlight GPIO is never initialized. Remove
it.
Signed-off-by: Laurent Pinchart
---
.../drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 19 ---
1 file changed, 19 deletions(-)
The function is never used, remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
drivers/gpu/drm/omapdrm/omap_fb.c | 10 --
2 files changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index
The function is never used, remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
drivers/gpu/drm/omapdrm/omap_gem.c | 12
2 files changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
inde
The omapdrm driver uses a custom API to synchronize with the SGX GPU.
This is unusable as such in the mainline kernel as the API is only
partially implemented and requires additional out-of-tree patches.
Furthermore, as no SGX driver is available in the mainline kernel, the
API can't be considered
On 04/26/2016 01:05 PM, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote:
>> On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote:
>>> On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote:
>>> But really the reason for per-plane is hw compos
On Tue, Apr 26, 2016 at 07:29:41PM +0200, Daniel Vetter wrote:
> amdgpu gained dev->struct_mutex usage, and that's because it's walking
> the dev->filelist list. Protect that list with it's own lock to take
> one more step towards getting rid of struct_mutex usage in drivers
> once and for all.
>
On Tue, Apr 26, 2016 at 07:29:38PM +0200, Daniel Vetter wrote:
> Only two drivers implement this hook. vmwgfx (which doesn't need it
> really) and legacy radeon (which since v1 has been nuked, yay).
>
> v1: Rebase over radeon ums removal.
>
> Cc: Thomas Hellstrom
> Cc: Alex Deucher
> Signed-off
On Tue, Apr 26, 2016 at 07:29:34PM +0200, Daniel Vetter wrote:
> It has a DRIVER_MODESET check to sure make it's not creating havoc
> for drm drivers. Make that clear in the name too.
The pattern is that any extern that starts
if (drm_core_check_feature(MODESET)) return
becomes drm_lega
On Tue, Apr 26, 2016 at 07:29:39PM +0200, Daniel Vetter wrote:
> And again make sure it's a no-op for modern drivers, again with the
> exception of nouveau. Another case of dev->struct_mutex gone for
> modern drivers!
>
> v2: Also add a DRIVER_* check like for all other maps functions to
> really
On Tue, Apr 26, 2016 at 07:29:36PM +0200, Daniel Vetter wrote:
> It belongs right next to the addmap and rmmap functions really. And
> for OCD consistency name it drm_legacy_getmap_ioctl.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Techn
On Tue, Apr 26, 2016 at 07:29:37PM +0200, Daniel Vetter wrote:
> Like in
>
> commit 0e975980d435d58df2d430d688b8c18778b42218
> Author: Peter Antoine
> Date: Tue Jun 23 08:18:49 2015 +0100
>
> drm: Turn off Legacy Context Functions
>
> we need to again make an exception for nouveau, but ev
On Tue, Apr 26, 2016 at 1:29 PM, Daniel Vetter
wrote:
> Except for the ->lasclose driver callback evrything in drm_lastclose()
> is all legacy cruft and can be hidden. Which means another
> dev->struct_mutex site disappears entirely for modern drivers!
>
> Also while at it change the return value
On Tue, Apr 26, 2016 at 1:29 PM, Daniel Vetter
wrote:
> It belongs right next to the addmap and rmmap functions really. And
> for OCD consistency name it drm_legacy_getmap_ioctl.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_bufs.c | 52
On Tue, Apr 26, 2016 at 1:29 PM, Daniel Vetter
wrote:
> Like in
>
> commit 0e975980d435d58df2d430d688b8c18778b42218
> Author: Peter Antoine
> Date: Tue Jun 23 08:18:49 2015 +0100
>
> drm: Turn off Legacy Context Functions
>
> we need to again make an exception for nouveau, but everyone els
On Tue, Apr 26, 2016 at 1:29 PM, Daniel Vetter
wrote:
> Only two drivers implement this hook. vmwgfx (which doesn't need it
> really) and legacy radeon (which since v1 has been nuked, yay).
>
> v1: Rebase over radeon ums removal.
>
> Cc: Thomas Hellstrom
> Cc: Alex Deucher
> Signed-off-by: Dani
On Tue, Apr 26, 2016 at 1:29 PM, Daniel Vetter
wrote:
> And again make sure it's a no-op for modern drivers, again with the
> exception of nouveau. Another case of dev->struct_mutex gone for
> modern drivers!
>
> v2: Also add a DRIVER_* check like for all other maps functions to
> really short-ci
On Tue, Apr 26, 2016 at 1:29 PM, Daniel Vetter
wrote:
> It's only used for legacy mmaping support now.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_internal.h | 2 --
> drivers/gpu/drm/drm_vm.c | 16
> 2 files changed, 4 inser
On Tue, Apr 26, 2016 at 4:52 PM, Chris Wilson
wrote:
> On Tue, Apr 26, 2016 at 07:29:41PM +0200, Daniel Vetter wrote:
>> amdgpu gained dev->struct_mutex usage, and that's because it's walking
>> the dev->filelist list. Protect that list with it's own lock to take
>> one more step towards getting
On Tue, Apr 26, 2016 at 1:29 PM, Daniel Vetter
wrote:
> Finally all the core gem and a lot of drivers are entirely free of
> dev->struct_mutex depencies, and we can start to have an entirely
> lockless unref path.
>
> To make sure that no one who touches the core code accidentally breaks
> existi
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #24 from Alex Deucher ---
(In reply to Jason Vas Dias from comment #20)
> When I look at linux 4.5.0 boot dmesg log messages like :
>
> [3.115380] vga_switcheroo: enabled
> [3.115463] ATPX version 1, functions 0x0033
> [
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #25 from Alex Deucher ---
Please attach you logs rather than pasting them in the comments, it's much
harder to follow with them inline.
Also, as per comment 11, please try removing your xorg config file completely.
The drivers are a
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #26 from Alex Deucher ---
(In reply to Jason Vas Dias from comment #22)
> It looks like the Intel driver is actually internally using the Radeon
> driver?
No. The drivers are independent. vga_switcheroo provides the intermediary for
2016-04-26 Ville Syrjälä :
> On Mon, Apr 25, 2016 at 07:33:25PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > There is now a new property called FENCE_FD attached to every plane
> > state that receives the sync_file fd from userspace via the atomic commit
> > IOCTL.
>
> I st
2016-04-26 Ville Syrjälä :
> On Mon, Apr 25, 2016 at 07:33:27PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Create one timeline context for each CRTC to be able to handle out-fences
> > and signal them. It adds a few members to struct drm_crtc: fence_context,
> > where we s
2016-04-26 Daniel Vetter :
> On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > struct fence_collection inherits from struct fence and carries a
> > collection of fences that needs to be waited together.
> >
> > It is useful to translate a sync_fi
2016-04-26 Lucas Stach :
> Am Donnerstag, den 21.04.2016, 12:38 -0300 schrieb Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > This function had copies in 3 different files. Unify them in kernel.h.
> >
> > Cc: Joe Perches
> > Cc: Andrew Morton
> > Cc: David Airlie
> > Cc: Daniel Vetter
>
Hi Dave,
This is DRM driver for ARC PGU - simple bitstreamer used on
Synopsys ARC SDP boards (both AXS101 and AXS103).
Those sources are from v6 series floated to mailing list here
https://lists.freedesktop.org/archives/dri-devel/2016-April/105156.html
and based on top of today's drm-next branch
Hi,
with the drm-intel-nightly I am currently running, I am also seeing some
quite noticable stuttering in Xv playback. It's particularly obvious in
stuff like rolling credits. It's not directly a performance problem, as the
effect can be seen even in "stop motion" (i.e., frame by frame) playback:
101 - 170 of 170 matches
Mail list logo
