[Intel-gfx] [PATCH 12/12] drm/i915/csr: Simplify stepping computation

No need to be overly fancy here. Cc: Animesh Manna Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_csr.c | 38 +++--- 1 file changed, 3 insertions(+), 35 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c in

Re: [Intel-gfx] [PATCH] drm/i915: fbdev_set_par reliably invalidating frontbuffer

On Thu, 2015-07-09 at 21:56 +0200, Daniel Vetter wrote: > On Thu, Jul 09, 2015 at 03:46:17PM -0300, Paulo Zanoni wrote: > > 2015-07-09 13:56 GMT-03:00 Rodrigo Vivi : > > > fbdev_set_par is called when fbcon is taking over control. > > > In the past frontbuffer was being invalidated on > > > set_to_

[Intel-gfx] [PATCH 01/18] drm/gem: rip out drm vma accounting for gem mmaps

Doesn't really add anything which can't be figured out through proc files. And more clearly separates the new gem mmap handling code from the old drm maps mmap handling code, which is surely a good thing. Cc: Martin Peres Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_gem.c | 11 +---

[Intel-gfx] [PATCH 03/18] drm/gem: Be more friendly with locking checks

BUG_ON kills the driver, WARN_ON is much friendly. And usually nothing bad happens when the locking is lightly busted. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_ge

[Intel-gfx] [PATCH 00/18] dev->struct_mutex crusade

Hi all, I wanted to take another look at struct_mutex usage in modern (gem) drivers and noticed that for a fair lot we're very to be completely struct_mutex free. This pile here is the the simple part, which mostly just removes code and mutex_lock/unlock calls. All the patches here are independen

[Intel-gfx] [PATCH 10/18] drm/rockchip: Don't grab dev->struct_mutex for in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). Aside: I stumbled over the mmap handler which direc

[Intel-gfx] [PATCH 05/18] drm/bochs: Don't grab dev->struct_mutex for in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). Signed-off-by: Daniel Vetter --- drivers/gpu/drm/

[Intel-gfx] [PATCH 07/18] drm/mga200g: Hold a proper reference for cursor_set

Looking up an obj, immediate dropping the acquired reference and then continuing to use it isn't how this is supposed to work. Fix this by holding a reference for the entire function. While at it stop grabbing dev->struct_mutex, it doesn't protect anything here. Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 11/18] drm/armada: Don't grab dev->struct_mutex for in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). While at it also fix a leak when this ioctl is call

[Intel-gfx] [PATCH 06/18] drm/mga200g: Don't grab dev->struct_mutex for in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). Signed-off-by: Daniel Vetter --- drivers/gpu/drm/

[Intel-gfx] [PATCH 08/18] drm/cirrus: Don't grab dev->struct_mutex for in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). Signed-off-by: Daniel Vetter --- drivers/gpu/drm/

[Intel-gfx] [PATCH 09/18] drm/cma-helper: Don't grab dev->struct_mutex for in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). Cc: Laurent Pinchart Cc: Rob Clark Signed-off-by:

[Intel-gfx] [PATCH 15/18] drm/radeon: Don't take dev->struct_mutex in bo_force_delete

It really doesn't protect anything which doesn't have other locks already. Also this is run from driver unload code so not much need for locks anyway. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Daniel Vetter --- drivers/gpu/drm/radeon/radeon_object.c | 4 +--- 1 file changed, 1 inse

[Intel-gfx] [PATCH 14/18] drm/qxl: Don't take dev->struct_mutex in bo_force_delete

It really doesn't protect anything which doesn't have other locks already. It also doesn't seem to be wired up into the driver unload code fwiw, but that's a different issue. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/qxl/qxl_object.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-

[Intel-gfx] [PATCH 12/18] drm/nouveau: Don't take dev->struct_mutex in fbcon init

It doesn't protect anything at all. fbdev helper state is all protected by modeset locks, and nouveau bo state is taken care of by ttm. There's also nothing else grabbing struct_mutex that might need to coordinate with this code. Also this is driver load code, no one can get at the device yet anywa

[Intel-gfx] [PATCH 13/18] drm/nouveau: Don't take dev->struct_mutex in ttm_fini

This is only called in driver load/unload paths, no need to grab any locks at all. Also, ttm takes care of itself anyway. Cc: Ben Skeggs Signed-off-by: Daniel Vetter --- drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_tt

[Intel-gfx] [PATCH 04/18] drm/ast: Don't grab dev->struct_mutex for in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). Signed-off-by: Daniel Vetter --- drivers/gpu/drm/

[Intel-gfx] [PATCH 02/18] drm/cma-helper: Fix locking in drm_fb_cma_debugfs_show

This function takes two locks, both of them the wrong ones. This wasn't an oversight from my fb locking rework since both patches landed in parallel. We really only need fb_lock when walking that list, since everything we can reach from that is refcounted properly already. Cc: Rob Clark Cc: Laure

[Intel-gfx] [PATCH 17/18] drm/amdgpu: Don't take dev->struct_mutex in bo_force_delete

It really doesn't protect anything which doesn't have other locks already. Also this is run from driver unload code so not much need for locks anyway. Same changes as for readone really. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/amdgpu/amdgpu_

[Intel-gfx] [PATCH 16/18] drm/radeon: Don't take dev->struct_mutex in pm functions

We already grab 2 device-global locks (write-sema rdev->pm.mclk_lock and rdev->ring_lock), adding another global mutex won't serialize this code more. And since there's really nothing interesting that gets protected in radeon by dev->struct mutex (we only have the global z buffer owners and it's st

[Intel-gfx] [PATCH 18/18] drm/amdgpu: don't grab dev->struct_mutex in pm functions

Similar to radeon, except that amdgpu doesn't even use struct_mutex to protect anything like the shared z buffer (sane gpu architecture, yay!). And the code already grabs the globa adev->ring_lock, so this code can't race with itself. Which makes struct_mutex completely redundnant. Remove it. Cc:

[Intel-gfx] [PATCH 05/14] drm: Check locking in drm_for_each_connector

Because of DP MST connectors can now be hotplugged and we must hold the right lock when walking the connector lists. Enforce this by checking the locking in our shiny new list walking macros. v2: Extract the locking check into a small static inline helper to help readability. This will be more im

[Intel-gfx] [PATCH 01/14] drm: Simplify drm_for_each_legacy_plane arguments

No need to pass the planelist when everyone just uses dev->mode_config.plane_list anyway. I want to add a pile more of iterators with unified (obj, dev) arguments. This is just prep. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/shmobile/shmo

[Intel-gfx] [PATCH 07/14] drm: Check locking in drm_for_each_fb

Ever since framebuffers are reference counted we have a special lock for the global fb list. Make sure users of that list do hold that lock when using the new iterators. Signed-off-by: Daniel Vetter --- include/drm/drm_crtc.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 00/14] drm_connector locking rules, v2

Hi all, So this is the second iteration of my connector locking series. This tries to clarify the cargo-culted locking rules around hotadd/removing drm_connector, which was added to support DP MST. I want to get this in first for a release or so just to document all the locking rules we have (and

[Intel-gfx] [PATCH 10/14] drm: Amend connector list locking rules

Now that dp mst hotplug takes all locks we can amend the locking rules for the iterators. This is needed before we can roll these out in the atomic code to avoid getting burried in WARNINGs. v2: Rebase onto the extracted list locking assert and add a comment to explain the rules. v3: Fixup German

[Intel-gfx] [PATCH 13/14] drm: Stop filtering according to mode_group in getresources

It's been dead code since forever since mode groups haven't ever been implemented. On top of that it's also been non-functional since we only ever filtered the getresources ioctl and not any of the others nor the mode object lookup code. Given overwhelming evidence it looks like this isn't a featu

[Intel-gfx] [PATCH 12/14] drm: Roll out drm_for_each_{plane, crtc, encoder}

Remaining manual work in the drm core&helpers. Nothing special here, no surprises. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 26 ++ drivers/gpu/drm/drm_crtc_helper.c | 2 +- drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- drivers/gpu/drm/drm_m

[Intel-gfx] [PATCH 02/14] drm: Add modeset object iterators

And roll them out across drm_* files. The point here isn't code prettification (it helps with that too) but that some of these lists aren't static any more. And having macros will gives us a convenient place to put locking checks into. I didn't add an iterator for props since that's only used by a

[Intel-gfx] [PATCH 11/14] drm: Roll out drm_for_each_connector more

Now that we also grab the connection_mutex and so fixed the race with atomic modeset we can use the iterator there too. The other special case is drm_connector_unplug_all which would have a locking inversion with the sysfs store/show functions if we'd grab the mode_config.mutex around the unplug.

[Intel-gfx] [PATCH 03/14] drm/probe-helper: Grab mode_config.mutex in poll_init/enable

So on first looks this seems superflous since drivers should ensure correct ordering to not make this a problem. Otoh ordering constraints between hdp, fbdev load and enabling polling are already tricky on some hardware and it helps to be more robust. But the real goal is to just shut up a locking

[Intel-gfx] [PATCH 04/14] drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors

This is now truly only duct-tape to keep locking checks happy since calling this function when hpd or polling are already enabled is a bug. The fbdev helper can't cope with hotplug changes yet at this point, only after that. Otoh a bit more robustness in this function can't hurt, and with this fbd

[Intel-gfx] [PATCH 08/14] drm/i915: Take all modeset locks for DP MST hotplug

While auditing various users of the connector/encoder lists I realized that the atomic code is a very prolific user of them. And it only ever grabs the mode_config->connection_mutex, but not the mode_config->mutex like all the other code walking encoder/connector lists. The problem is that we can'

[Intel-gfx] [PATCH 06/14] drm/i915: Use drm_for_each_fb in i915_debugfs.c

Just so I have a user for this macro. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 053adbb97037..60eebf5f6da8 100644 ---

[Intel-gfx] [PATCH 09/14] drm/radeon: Take all modeset locks for DP MST hotplug

Similar with the i915 take all modeset locks for mst hotplug. This is needed to make sure radeon holds both mode_config.mutex and mode_config.connection_mutex when updating the connector_list, which is the new (interim) locking regime we want for that. Signed-off-by: Daniel Vetter --- drivers/gp

[Intel-gfx] [PATCH 14/14] drm: gc now dead mode_group code

Two nice things here: - drm_dev_register will truly register everything in the right order if the driver doesn't have a ->load callback. Before this we had to init the primary mode_group after the device nodes where already registered. - Less things to keep track of when reworking the connec

Re: [Intel-gfx] [PATCH 1/6] drm/i915/skl: Retrieve the Rpe value from Pcode

I don't have the spec so I can just assume it was like previous platforms. For me this 50MHz x 16.6MHz is still confusing (like clamp in 50 than convert to 16.6)... but nevermind... apparently we are not mixing stuff in the sense we compare values in different scales... Reviewed-by: Rodrigo Vivi

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Added BXT check in HAS_CORE_RING_FREQ macro

Reviewed-by: Rodrigo Vivi On Mon, Jun 29, 2015 at 1:28 PM wrote: > Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: > shuang...@intel.com) > Task id: 6658 > > -Summary- > Platform Delta

Re: [Intel-gfx] [PATCH 18/18] drm/amdgpu: don't grab dev->struct_mutex in pm functions

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6765 -Summary- Platform Delta drm-intel-nightly Series Applied ILK

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/i915_drv.h between commit: 8146ba1637a7 ("drm/i915: Store device pointer in contexts for late tracepoint usafe") from the drm-intel-fixes tree and commit: b1b38278e12b ("drm/i915: add a conte

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/intel_ringbuffer.h between commit: ee412ecc74c4 ("drm/i915: Snapshot seqno of most recently submitted request.") from the drm-intel-fixes tree and commit: bccca494f75c ("drm/i915: Remove the n

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid

On 7/9/2015 10:57 PM, Daniel Vetter wrote: On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote: Adding this for SKL onwards. Signed-off-by: Sonika Jindal I think this is the critical piece really, and I'd like to roll it out for all platforms. git has the code for all the old one

[Intel-gfx] [PATCH] drm/i915: storm detection documentation update

From: "Thulasimani,Sivakumar" Update the hotplug documentation to explain that hotplug storm is not expected for Display port panels and hence is not handled in current code. v2: update the statements as recommended by Daniel Signed-off-by: Sivakumar Thulasimani --- drivers/gpu/drm/i915/intel

<    1   2