On Wed, Apr 27, 2016 at 08:46:31AM +0200, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 05:35:42PM -0400, Alex Deucher wrote:
> > On Tue, Apr 26, 2016 at 1:29 PM, Daniel Vetter
> > wrote:
> > > Like in
> > >
> > > commit 0e975980d435d58df2d430d688b8c18778b42218
> > > Author: Peter Antoine
> > >
== Series Details ==
Series: Moar struct_mutex nuking
URL : https://patchwork.freedesktop.org/series/6358/
State : failure
== Summary ==
Series 6358v1 Moar struct_mutex nuking
http://patchwork.freedesktop.org/api/1.0/series/6358/revisions/1/mbox/
Test drv_getparams_basic:
Subgroup bas
On Tue, Apr 26, 2016 at 05:35:42PM -0400, Alex Deucher wrote:
> 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 F
On Tue, Apr 26, 2016 at 10:09:16PM +0100, Chris Wilson wrote:
> 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 start
== Series Details ==
Series: drm/i915: Cdclk related fixes and polish
URL : https://patchwork.freedesktop.org/series/6354/
State : warning
== Summary ==
Series 6354v1 drm/i915: Cdclk related fixes and polish
http://patchwork.freedesktop.org/api/1.0/series/6354/revisions/1/mbox/
Test drv_modul
Hi Len,
Could you please share if you have any following plan to fix the hard-hang on
SandyBridge? Will you modify patch 540cc882de7d1da2e71591e215f0e04cb89883fa and
update your public repo? Thanks.
BR,
Han Lu
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_dp.c
between commit:
86ee27b5aa75 ("drm/i915: Read eDP Display control capability registers")
from the drm-intel tree and commit:
9f085ebb1a50 ("rm/i915: Get rid of intel_dp_dpcd_read_wak
From: Dave Airlie
This just takes a reference on the connector when we set a mode
in the non-atomic paths.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_he
From: Dave Airlie
This uses the previous changes to add reference counts
to drm connector objects.
v2: move fbdev changes to their own patch.
add some kerneldoc
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_atomic.c | 19 +--
drivers/gpu/drm/drm_crtc.c | 28 +
From: Dave Airlie
Don't just free the connector when we get the destroy callback.
Drop a reference to it, and set it's mst_port to NULL so
no more mst work is done on it.
v2: core mst accepts NULLs fine. Cleanup EDID code properly.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_dp
From: Dave Airlie
This takes a reference count when fbdev adds the connector,
and drops it when it removes the connector.
It also drops the now unneeded code to find connectors
and remove the from the modeset as they are reference counted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb
From: Dave Airlie
Take a reference when setting a crtc on a connecter,
also take one when duplicating if a crtc is set,
and drop one on destroy if a crtc is set.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_atomic.c| 11 ++-
drivers/gpu/drm/drm_atomic_helper.c | 4
On Tue, Apr 26, 2016 at 02:53:41PM +0200, Daniel Vetter wrote:
> On Mon, Apr 25, 2016 at 02:42:50AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Apr 04, 2016 at 02:18:10PM +0100, Chris Wilson wrote:
> > > From: Akash Goel
> > >
> > > This provides support for the drivers or shmem file owners to r
Hello,
These errors are unrelated to the major_minor version change.
Thanks,
Tom
>-Original Message-
>From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
>Sent: Monday, April 25, 2016 10:18 PM
>To: O'Rourke, Tom
>Cc: intel-gfx@lists.freedesktop.org
>Subject: ✗ Fi.CI.BAT: failure for
On Tue, Apr 26, 2016 at 11:59 PM, Rodrigo Vivi wrote:
> Version 1.01.
>
> This firmware is made for Kabylake platform so it doesn't
> need the stepping workaround that we had before.
>
> v2: Rebased on top of latest nightly with min version
> required change.
> v3: With right CSR_VERSION (Patr
Version 1.01.
This firmware is made for Kabylake platform so it doesn't
need the stepping workaround that we had before.
v2: Rebased on top of latest nightly with min version
required change.
v3: With right CSR_VERSION (Patrik).
Cc: Christophe Prigent
Cc: Patrik Jakobsson
Reviewed-by: Ben
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
> existin
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 r
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 insert
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-cir
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: Danie
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 else
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:
> 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 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 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: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: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
As I cannot reinstall the entire machine from scratch I tried first to
verify the issue using a Fedora 23 - Live USB Stick (which still runs
on Kernel 4.2.3) = > It practically show exactly the same
results/errors.
I've also cleaned my machine very thoroughly from any packages
installed or updat
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: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 6:44 PM, Rodrigo Vivi wrote:
> Version 1.01.
>
> This firmware is made for Kabylake platform so it doesn't
> need the stepping workaround that we had before.
>
> v2: Rebased on top of latest nightly with min version
> required change.
>
> Cc: Christophe Prigent
> Cc: P
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
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:
From: Robert Foss
ref_crc is never assigned or read, and can be safely
removed.
Signed-off-by: Robert Foss
Reviewed-by: Tomeu Vizoso
---
tests/kms_panel_fitting.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c
index 7bfd980..099816b 10
Move the i915_gem_l3_remap function such that it next to the context
switching, which is where we perform the L3 remap.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 31 ---
drivers/gpu/drm/i
The hardware tracks contexts and expects all live contexts (those active
on the hardware) to have a unique identifier. This is used by the
hardware to assign pagefaults and the like to a particular context.
v2: Reorder to make sure ctx->link is not left dangling if the
assignment of a hw_id fails
Similarly to i915_gem_object_pin_map on LLC platforms, we can
use the new VMA based io mapping on !LLC to amoritize the cost
of ringbuffer pinning and unpinning.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/
The code to switch_mm() is already handled by i915_switch_context(), the
only difference required to setup the aliasing ppgtt is that we need to
emit te switch_mm() on the first context, i.e. when transitioning from
engine->last_context == NULL. This allows us to defer the
initialisation of the GPU
In order to force a reload of the context image upon resume, we first
need to mark its absence on suspend. Currently we are failing to restore
the golden context state and any context w/a to the default context
after resume.
One oversight corrected, is that we had forgotten to reapply the L3
remap
From: Robert Foss
Remove devid from data_t since it is never read.
Also remove one assignment to devid.
Signed-off-by: Robert Foss
Reviewed-by: Tomeu Vizoso
---
tests/kms_panel_fitting.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c
From: Robert Foss
Changed the DRM format to LOCAL_DRM_FORMAT_MOD_NONE since it
is hardware agnostic.
Also fixed formatting/tabs.
Signed-off-by: Robert Foss
Reviewed-by: Tomeu Vizoso
---
tests/kms_panel_fitting.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t
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.
> >
>
From: Robert Foss
Enable testing on all connectors that have the "scaling mode"
property set.
Signed-off-by: Robert Foss
---
tests/kms_panel_fitting.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c
i
From: Robert Foss
Switched from DRIVER_INTEL to DRIVER_ANY to enable test
on all hardware.
Signed-off-by: Robert Foss
Reviewed-by: Tomeu Vizoso
---
tests/kms_panel_fitting.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting
From: Robert Foss
Changes since v2:
- Added reviewed-by tomeu to patch 1-5.
- kms_panel_fitting.c: Replaced connector type checking with "scaling mode"
property check.
Changes since v1:
- Squash patches
- Based patch on
https://lists.freedesktop.org/archives/intel-gfx/2016-March/090617.html
R
From: Robert Foss
pipe_crc in data_t is assigned an allocated memory space and
then later free'd. But it is never used for any comparisons.
It should therefore be safe to remove pipe_crc and the crc
requirement.
Signed-off-by: Robert Foss
Reviewed-by: Tomeu Vizoso
---
tests/kms_panel_fitting.
From: Tvrtko Ursulin
With the previous patch having extended the pinned lifetime of
contexts by referencing the previous context from the current
request until the latter is retired (completed by the GPU),
we can now remove usage of execlist retired queue entirely.
This is because the above now
From: Tvrtko Ursulin
This way in the following patch we can disconnect requests
from contexts.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
2 files changed, 4 inserti
Both execlists and legacy need to reset the context (and mode) of the
GPU before we lose control of the system. By resetting the GPU, we
revert back to default settings. This simplifies the life of any
subsequent driver (in particular for virtualized setups) as it does not
then have to try and reco
Refactor pinning and unpinning of contexts, such that the default
context for an engine is pinned during initialisation and unpinned
during teardown (pinning of the context handles the reference counting).
Thus we can eliminate the special case handling of the default context
that was required to m
If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unreference of
the GEM requ
As the contexts are accessed by the hardware until the switch is completed
to a new context, the hardware may still be writing to the context object
after the breadcrumb is visible. We must not unpin/unbind/prune that
object whilst still active and so we keep the previous context pinned until
the f
We can hide more details of execlists from higher level code by removing
the explicit call to create an execlist context from execbuffer and
into its first use by execlists.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8
dri
Now that we share intel_ring_begin(), reserving space for the tail of
the request is identical between legacy/execlists and so the tautology
can be removed. In the process, we move the reserved space tracking
from the ringbuffer on to the request. This is to enable us to reorder
the reserved space
Rather than reuse the current location of the context in the global GTT
for its hardware identifier, use the context's unique ID assigned to it
for its whole lifetime.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
drivers/gpu/
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).
Note that by moving the iounnma
When releasing the intel_fbdev, we should unpin the framebuffer that we
pinned during construction.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbdev.c | 7 ++-
3 files changed, 8 insert
The comments describing the Context Descriptor Format are off by a bit
for the size of the context ID.
Signed-off-by: Chris Wilson
Cc: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu
Since we do the l3-remap on context switch, we can remove the redundant
early call to set the mapping prior to performing the first context
switch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i91
Combine the near identical implementations of intel_logical_ring_begin()
and intel_ring_begin() - the only difference is that the logical wait
has to check for a matching ring (which is assumed by legacy).
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i
In the next patches, we want to move the work out of freeing the request
and into its retirement (so that we can free the request without
requiring the struct_mutex). This means that we cannot rely on
unreferencing the request to completely teardown the request any more
and so we need to manually u
Now we have the context leak sorted, everything should be in place to
satisfy BAT, or so I hope. A few new patches need reviewing, and the rest
could do with eyeballing - though I have tried to keep them the same, the
code around them has changed slightly, and I hope I have introduced subtle
bugs i
Rather than being interrupted when we run out of space halfway through
the request, and having to restart from the beginning (and returning to
userspace), flush a little more free space when we prepare the request.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lr
We can use a single MI_LOAD_REGISTER_IMM command packet to write all the
L3 remapping registers, shrinking the number of bytes required to emit
the context switch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 16 ++
When setting up the overlay page, we pin it into the GGTT (when using
virtual addresses) and store the offset as overlay->flip_addr. Rather
than doing a lookup of the GGTT address everytime, we can use the known
address instead.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko
In a couple of places, we have an i915_address_space that we know is
really an i915_ggtt that we want to use. Create an inline helper to
convert from the i915_address_space subclass into its container.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Reviewed-by: Joonas Lahtin
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 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
Hi Matthew:
Thanks for spending efforts on rebase! :) I'm sorry that we will drop this
2 patches in the next round patch review.
In the previous discussion, there were two options:
Option A. Unify GVT-g PPGTT shadow with i915 PPGTT routines, which needs these
2 patches, then LRC submission
On Tue, Apr 26, 2016 at 01:27:40PM +0300, Jani Nikula wrote:
> Add support for CHV gpio programming in DSI gpio elements.
>
> v2: Overhaul macros according to Ville's review.
>
> v3: Address Ville's review:
> - swap E and SE gpio ranges
> - add a note about max SE index
> - use GPO, not HIZ
>
On Tue, Apr 26, 2016 at 01:27:39PM +0300, Jani Nikula wrote:
> Only support NC GPIOs for now, and assume the vlv gpio table only has NC
> GPIOs for now.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
On Tue, Apr 26, 2016 at 01:27:41PM +0300, Jani Nikula wrote:
> Request the GPIO by index through the consumer API. For now, use a quick
> hack to store the already requested ones, simply because I have no idea
> whether this actually works or not, and I have no way to test it.
>
> Signed-off-by: J
On Tue, Apr 26, 2016 at 04:30:05PM +0200, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 05:26:43PM +0300, Eero Tamminen wrote:
> > Hi,
> >
> > On 26.04.2016 16:23, Chris Wilson wrote:
> > >On Tue, Apr 26, 2016 at 04:17:55PM +0300, Imre Deak wrote:
> > >>On ti, 2016-04-26 at 13:57 +0100, Chris Wil
== Series Details ==
Series: series starting with [1/2] drm/i915: Support per-PPGTT address space
mode
URL : https://patchwork.freedesktop.org/series/6347/
State : failure
== Summary ==
Series 6347v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6347/revisions/1/
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
existing drivers which still require dev->struct_mutex I've made the
migh
No dev->struct_mutex anywhere to be seen.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index
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
---
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
No dev->struct_mutex anywhere to be seen.
Cc: Thierry Reding
Cc: Terje Bergström
Cc: linux-te...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/
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
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 dev->struct_mutex anywhere to be seen.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index ebb470ff7200.
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: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index fb9242d2
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
No dev->struct_mutex anywhere to be seen.
Cc: Mark Yao
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
inde
No dev->struct_mutex anywhere to be seen.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index dc83f69da6f1..b05f7
No dev->struct_mutex anywhere to be seen.
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index db5c7d0cc25c..
No dev->struct_mutex anywhere to be seen.
Cc: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 5d44ed0d104a..b9f7
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: Inki Dae
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 5344940c8a
No dev->struct_mutex anywhere to be seen.
Cc: seanp...@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..1228b4069
No dev->struct_mutex anywhere to be seen.
Cc: Sascha Hauer
Cc: Philipp Zabel
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index e2
No dev->struct_mutex anywhere to be seen.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index dc9df5fe50ba..460bbceae297 100644
---
No dev->struct_mutex anywhere to be seen.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index fcd9c0714836..f54afd2113a9 100644
---
No dev->struct_mutex anywhere to be seen.
Cc: Gerd Hoffmann
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index b332b4
No dev->struct_mutex anywhere to be seen.
Cc: Christian Gmeiner
Cc: Russell King
Cc: Lucas Stach
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/
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.
While doing the conversion I noticed that 2 debugfs files in i915
complet
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-circuit the code. And give drm_legacy_rmmap used by the
dev unregiste
1 - 100 of 257 matches
Mail list logo
