[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Dave Airlie]

On 30 July 2015 at 15:18, Linus Torvalds  
wrote:
> On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o  wrote:
>>
>> It's here:  https://goo.gl/photos/xHjn2Z97JQEw6k2C9
>
> You didn't catch enough of the code line to decode the code, but it's
> early enough in drm_crtc_index() (just five bytes in) that it's almost
> certainly the very first dereference, so it's almost guaranteed to be
> that
>
>crtc->dev
>
> access as part of list_for_each_entry(), with crtc being NULL. And
> yes, "->dev" is the very first field, so the offset is zero too (while
> the "->mode_config" list access would not be at offset zero).
>
> And it looks like it is called from drm_atomic_helper_check_modeset():
> the reason it has a question mark in the backtrace is because the
> fault happens before the stack frame has even been set up.
>
> There are multiple calls to "drm_crtc_index()" from that function, I
> can't tell which one it is. Looking at the code generation I get, I
> think it's because update_connector_routing() gets inlined, and that
> one does several calls. Most of them look like this:
>
> if (connector->state->crtc) {
> idx = drm_crtc_index(connector->state->crtc);
>
> ie they check that the crtc is non-NULL, but that last one does not:
>
> connector_state->best_encoder = new_encoder;
> idx = drm_crtc_index(connector_state->crtc);
>
> crtc_state = state->crtc_states[idx];
> crtc_state->mode_changed = true;
>
> and I suspect the fix might be something like the attached. Totally
> untested. Ted?
>
> This whole "atomic modeset" series has been one royal fuck-up, guys.
> We've had too many of these kinds of crap issues.

It hasn't been that bad, on a scale of 1 to MD eats my raid array, I'd
say we are barely at a 5.

There have been a lot of small and seemingly easily fixed teething
problems, essentially rewriting the DRM API to provide a new userspace
API and internal interface, porting some drivers partly to the new
interface, while trying to maintain the old ABI/API on top seamlessly
was always going to be an impossible task. It was never going to
magically all just work in -next and land in your tree fully formed
smelling of lavender and elderberries. This is a massive undertaking,
and doing it over a few kernels was the only possible way it could
ever land.

I think the biggest problem we've had is the QA team at Intel got
reorganised or something right when they really needed to be doing
testing on this stuff, so what was sitting in -next never got as much
testing as it had previously, and you can see that in the types of
cases that are getting through. I think the other thing we can learn
is that when Android forks the kernel we should just say this shit is
too hard, let Google go and create a new API and a complete set of
graphics drivers and deal with it in 10 years, because that was
seriously the only other option.

So yes it's a pity other kernel developers are seeing our fallout, but
I've experienced lots of other kernel developers fall out over the
years, and generally the idea is to get this stuff fixed to a
reasonable state before you release a final kernel.

Note I'm not personally involved in the development for atomic
modesetting at all, I'm running the kernels with it where and when I
can, and I trust the developers who work on it are doing as much as
they can to make it work.

That said hopefully Daniel can find a bag of fucks to debug and write
a proper patch, instead of rage quitting the universe, and just git
reset --hard v4.0 drivers/gpu/drm/i915..

Dave.

[RFC PATCH v2 00/21] Add DSI display support for Exynos based boards

[vvn praveen kumar]

Hi,

From where I can get these patches?
And why there is no support for dsi display in the exynos5250 in the
latest kernels.?
Can you please clarify my doubts.?
Thanks for your valuable time


Winning Regard

VVN Praveen Kumar
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/08a76dbb/attachment-0001.html>

[PATCH 1/3] drm/atomic-helper: Add option to update planes only on active crtc

[Maarten Lankhorst]

Op 29-07-15 om 14:01 schreef Daniel Vetter:
> With drivers supporting runtime pm it's generally not a good idea to
> touch the hardware when it's off. Add an option to the commit_planes
> helper to support this case.
>
> Note that the helpers already add all planes on a crtc when a modeset
> happens, hence plane updates will not be lost if drivers set this to
> true.
>
> v2: Check for NULL state->crtc before chasing the pointer. Also check
> both old and new crtc if there's a switch. Finally just outright
> disallow switching crtcs for a plane if the plane is in active use, on
> most hardware that doesn't make sense.
>
> v3: Since commit_planes(active_only = true) is for enabling things
> only after all the crtc are on we should only look at the new crtc to
> decide whether to call the plane hooks - if the current CRTC isn't on
> then skip. If the old crtc (when moving a plane) went down then the
> plane should have been disabled as part of the pipe shutdown work
> already. For which there's currently no helper really unfortunately.
> Also move the check for wether a plane gets a new CRTC assigned while
> still in active use out of this patch.
>
> Cc: Maarten Lankhorst 
> Cc: Thierry Reding 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c| 20 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fb.c |  2 +-
>  drivers/gpu/drm/msm/msm_atomic.c   |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  2 +-
>  drivers/gpu/drm/sti/sti_drm_drv.c  |  2 +-
>  drivers/gpu/drm/tegra/drm.c|  2 +-
>  include/drm/drm_atomic_helper.h|  3 ++-
>  8 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0b475fae067d..6be0adb5a0e9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1029,7 +1029,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>  
>   drm_atomic_helper_commit_modeset_disables(dev, state);
>  
> - drm_atomic_helper_commit_planes(dev, state);
> + drm_atomic_helper_commit_planes(dev, state, false);
>  
>   drm_atomic_helper_commit_modeset_enables(dev, state);
>  
> @@ -1144,10 +1144,16 @@ fail:
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);
>  
> +bool plane_crtc_active(struct drm_plane_state *state)
> +{
> + return state->crtc && state->crtc->state->active;
> +}
> +
>  /**
>   * drm_atomic_helper_commit_planes - commit plane state
>   * @dev: DRM device
>   * @old_state: atomic state object with old state structures
> + * @active_only: Only commit on active CRTC if set
>   *
>   * This function commits the new plane state using the plane and atomic 
> helper
>   * functions for planes and crtcs. It assumes that the atomic state has 
> already
> @@ -1162,7 +1168,8 @@ EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);
>   * drm_atomic_helper_commit_planes_on_crtc() instead.
>   */
>  void drm_atomic_helper_commit_planes(struct drm_device *dev,
> -  struct drm_atomic_state *old_state)
> +  struct drm_atomic_state *old_state,
> +  bool active_only)
>  {
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *old_crtc_state;
> @@ -1178,6 +1185,9 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>   if (!funcs || !funcs->atomic_begin)
>   continue;
>  
> + if (active_only && !crtc->state->active)
> + continue;
> +
>   funcs->atomic_begin(crtc, old_crtc_state);
>   }
>  
> @@ -1189,6 +1199,9 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>   if (!funcs)
>   continue;
>  
> + if (active_only && !plane_crtc_active(plane->state))
> + continue;
> +
>   /*
>* Special-case disabling the plane if drivers support it.
>*/
>
This would leave a plane active if it was moved from a active crtc to a 
inactive crtc, you would still need to call the atomic_disable(plane) callback 
for that one. ;-)

~Maarten

[PATCH 7/7] drm/cirrus: add DRIVER_ATOMIC to .driver_features

[John Hunter]

From: Zhao Junwang 

Since  driver is now fully atomic, we should add DRIVER_ATOMIC to
.driver_features

Signed-off-by: Zhao Junwang 
---
 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 80f1cd2..742647b 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -130,7 +130,7 @@ static const struct file_operations cirrus_driver_fops = {
 #endif
 };
 static struct drm_driver driver = {
-   .driver_features = DRIVER_MODESET | DRIVER_GEM,
+   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
.load = cirrus_driver_load,
.unload = cirrus_driver_unload,
.set_busid = drm_pci_set_busid,
-- 
1.7.10.4

[PATCH 6/7] drm/cirrus: atomic dpms support

[John Hunter]

From: Zhao Junwang 

Run dpms operations through the atomic interfaces. This basically
removes the .dpms() callback from encoders and crtcs and use .disable
and .enable to turn the crtc on and off.

use drm_atomic_helper_connector_dpms for connector

Signed-off-by: Zhao Junwang 
---
 drivers/gpu/drm/cirrus/cirrus_mode.c |   68 +++---
 1 file changed, 39 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 1775864..e807cf0 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -55,37 +55,40 @@ static void cirrus_crtc_load_lut(struct drm_crtc *crtc)
}
 }

-/*
- * The DRM core requires DPMS functions, but they make little sense in our
- * case and so are just stubs
- */
+static void cirrus_crtc_enable(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct cirrus_device *cdev = dev->dev_private;
+   u8 sr01, gr0e;
+
+   if (crtc->enabled)
+   return;

-static void cirrus_crtc_dpms(struct drm_crtc *crtc, int mode)
+   sr01 = 0x00;
+   gr0e = 0x00;
+
+   WREG8(SEQ_INDEX, 0x1);
+   sr01 |= RREG8(SEQ_DATA) & ~0x20;
+   WREG_SEQ(0x1, sr01);
+
+   WREG8(GFX_INDEX, 0xe);
+   gr0e |= RREG8(GFX_DATA) & ~0x06;
+   WREG_GFX(0xe, gr0e);
+
+   crtc->enabled = true;
+}
+
+static void cirrus_crtc_disable(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct cirrus_device *cdev = dev->dev_private;
u8 sr01, gr0e;

-   switch (mode) {
-   case DRM_MODE_DPMS_ON:
-   sr01 = 0x00;
-   gr0e = 0x00;
-   break;
-   case DRM_MODE_DPMS_STANDBY:
-   sr01 = 0x20;
-   gr0e = 0x02;
-   break;
-   case DRM_MODE_DPMS_SUSPEND:
-   sr01 = 0x20;
-   gr0e = 0x04;
-   break;
-   case DRM_MODE_DPMS_OFF:
-   sr01 = 0x20;
-   gr0e = 0x06;
-   break;
-   default:
+   if (!crtc->enabled)
return;
-   }
+
+   sr01 = 0x20;
+   gr0e = 0x06;

WREG8(SEQ_INDEX, 0x1);
sr01 |= RREG8(SEQ_DATA) & ~0x20;
@@ -94,6 +97,8 @@ static void cirrus_crtc_dpms(struct drm_crtc *crtc, int mode)
WREG8(GFX_INDEX, 0xe);
gr0e |= RREG8(GFX_DATA) & ~0x06;
WREG_GFX(0xe, gr0e);
+
+   crtc->enabled = false;
 }

 /*
@@ -303,7 +308,8 @@ static const struct drm_crtc_funcs cirrus_crtc_funcs = {
 };

 static const struct drm_crtc_helper_funcs cirrus_helper_funcs = {
-   .dpms = cirrus_crtc_dpms,
+   .disable = cirrus_crtc_disable,
+   .enable = cirrus_crtc_enable,
.mode_fixup = cirrus_crtc_mode_fixup,
.mode_set_nofb = cirrus_crtc_mode_set_nofb,
.commit = cirrus_crtc_commit,
@@ -490,9 +496,12 @@ static void cirrus_encoder_mode_set(struct drm_encoder 
*encoder,
 {
 }

-static void cirrus_encoder_dpms(struct drm_encoder *encoder, int state)
+static void cirrus_encoder_enable(struct drm_encoder *encoder)
+{
+}
+
+static void cirrus_encoder_disable(struct drm_encoder *encoder)
 {
-   return;
 }

 static void cirrus_encoder_commit(struct drm_encoder *encoder)
@@ -507,7 +516,8 @@ static void cirrus_encoder_destroy(struct drm_encoder 
*encoder)
 }

 static const struct drm_encoder_helper_funcs cirrus_encoder_helper_funcs = {
-   .dpms = cirrus_encoder_dpms,
+   .enable = cirrus_encoder_enable,
+   .disable = cirrus_encoder_disable,
.mode_fixup = cirrus_encoder_mode_fixup,
.mode_set = cirrus_encoder_mode_set,
.commit = cirrus_encoder_commit,
@@ -580,7 +590,7 @@ struct drm_connector_helper_funcs 
cirrus_vga_connector_helper_funcs = {
 };

 struct drm_connector_funcs cirrus_vga_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.detect = cirrus_vga_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = cirrus_connector_destroy,
-- 
1.7.10.4

[PATCH 5/7] drm/cirrus: phase 3: use atomic .set_config helper

[John Hunter]

From: Zhao Junwang 

Now that phase 1 and phase 2 are completed, switch .set_config
helper to use the atomic one.

-stop looking legacy crtc->primary->fb, instead we should use
crtc->primary->state->fb

.prepare() calls are no more needed, remove them
.mode_set() and .mode_set_base are no longer needed, remove

Signed-off-by: Zhao Junwang 
---
 drivers/gpu/drm/cirrus/cirrus_mode.c |   28 ++--
 1 file changed, 6 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index e8f038b..1775864 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -208,7 +208,8 @@ static void cirrus_crtc_mode_set_nofb(struct drm_crtc *crtc)
sr07 = RREG8(SEQ_DATA);
sr07 &= 0xe0;
hdr = 0;
-   switch (crtc->primary->fb->bits_per_pixel) {
+
+   switch (crtc->primary->state->fb->bits_per_pixel) {
case 8:
sr07 |= 0x11;
break;
@@ -231,13 +232,13 @@ static void cirrus_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
WREG_SEQ(0x7, sr07);

/* Program the pitch */
-   tmp = crtc->primary->fb->pitches[0] / 8;
+   tmp = crtc->primary->state->fb->pitches[0] / 8;
WREG_CRT(VGA_CRTC_OFFSET, tmp);

/* Enable extended blanking and pitch bits, and enable full memory */
tmp = 0x22;
-   tmp |= (crtc->primary->fb->pitches[0] >> 7) & 0x10;
-   tmp |= (crtc->primary->fb->pitches[0] >> 6) & 0x40;
+   tmp |= (crtc->primary->state->fb->pitches[0] >> 7) & 0x10;
+   tmp |= (crtc->primary->state->fb->pitches[0] >> 6) & 0x40;
WREG_CRT(0x1b, tmp);

/* Enable high-colour modes */
@@ -253,15 +254,6 @@ static void cirrus_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 }

 /*
- * This is called before a mode is programmed. A typical use might be to
- * enable DPMS during the programming to avoid seeing intermediate stages,
- * but that's not relevant to us
- */
-static void cirrus_crtc_prepare(struct drm_crtc *crtc)
-{
-}
-
-/*
  * This is called after a mode is programmed. It should reverse anything done
  * by the prepare function
  */
@@ -303,7 +295,7 @@ static void cirrus_crtc_destroy(struct drm_crtc *crtc)
 /* These provide the minimum set of functions required to handle a CRTC */
 static const struct drm_crtc_funcs cirrus_crtc_funcs = {
.gamma_set = cirrus_crtc_gamma_set,
-   .set_config = drm_crtc_helper_set_config,
+   .set_config = drm_atomic_helper_set_config,
.destroy = cirrus_crtc_destroy,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
@@ -313,10 +305,7 @@ static const struct drm_crtc_funcs cirrus_crtc_funcs = {
 static const struct drm_crtc_helper_funcs cirrus_helper_funcs = {
.dpms = cirrus_crtc_dpms,
.mode_fixup = cirrus_crtc_mode_fixup,
-   .mode_set = drm_helper_crtc_mode_set,
-   .mode_set_base = drm_helper_crtc_mode_set_base,
.mode_set_nofb = cirrus_crtc_mode_set_nofb,
-   .prepare = cirrus_crtc_prepare,
.commit = cirrus_crtc_commit,
.load_lut = cirrus_crtc_load_lut,
 };
@@ -506,10 +495,6 @@ static void cirrus_encoder_dpms(struct drm_encoder 
*encoder, int state)
return;
 }

-static void cirrus_encoder_prepare(struct drm_encoder *encoder)
-{
-}
-
 static void cirrus_encoder_commit(struct drm_encoder *encoder)
 {
 }
@@ -525,7 +510,6 @@ static const struct drm_encoder_helper_funcs 
cirrus_encoder_helper_funcs = {
.dpms = cirrus_encoder_dpms,
.mode_fixup = cirrus_encoder_mode_fixup,
.mode_set = cirrus_encoder_mode_set,
-   .prepare = cirrus_encoder_prepare,
.commit = cirrus_encoder_commit,
 };

-- 
1.7.10.4

[PATCH 4/7] drm/cirrus: add return 0 to make sure if (bo->pin_count) early_exit

[John Hunter]

From: Zhao Junwang 

when the first modeset calls prepare_fb, bo->pin_count change from
0 to 1, then the second modeset with the same fb, that should set
bo->pin_count to 2, and then when cleanup_fb was called, bo->pin_count
should be 2 to 1.

But in the cirrus_bo_pin, it will set bo->pin_count = 1 at the end
of the function, this results that bo->bin_count will never be larger
than 1 no matter how many times cirrus_bo_pin was called.

So we need to add a condition before bo->pin_count = 1

V2: if (bo->pin_count) early_exit; do_the_real_pinning work

Signed-off-by: Zhao Junwang 
---
 drivers/gpu/drm/cirrus/cirrus_ttm.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index dfffd52..756b6d0 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -364,6 +364,8 @@ int cirrus_bo_pin(struct cirrus_bo *bo, u32 pl_flag, u64 
*gpu_addr)
bo->pin_count++;
if (gpu_addr)
*gpu_addr = cirrus_bo_gpu_offset(bo);
+
+   return 0;
}

cirrus_ttm_placement(bo, pl_flag);
-- 
1.7.10.4

[PATCH 3/7] drm/cirrus: phase 3: atomic updates of planes

[John Hunter]

From: Zhao Junwang 

Now that phase 1 and 2 are complete we can switch the
update/disable_plane callbacks to their atomic version

Signed-off-by: Zhao Junwang 
---
 drivers/gpu/drm/cirrus/cirrus_main.c |3 +++
 drivers/gpu/drm/cirrus/cirrus_mode.c |4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index d95de34..cfa92bc 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -10,6 +10,7 @@
  */
 #include 
 #include 
+#include 

 #include "cirrus_drv.h"

@@ -82,6 +83,8 @@ cirrus_user_framebuffer_create(struct drm_device *dev,

 static const struct drm_mode_config_funcs cirrus_mode_funcs = {
.fb_create = cirrus_user_framebuffer_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
 };

 /* Unmap the framebuffer from the core and release the memory */
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 42a4d86..e8f038b 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -431,8 +431,8 @@ static void cirrus_plane_atomic_disable(struct drm_plane 
*plane,
 }

 static const struct drm_plane_funcs cirrus_plane_funcs = {
-   .update_plane = drm_plane_helper_update,
-   .disable_plane = drm_plane_helper_disable,
+   .update_plane = drm_atomic_helper_update_plane,
+   .disable_plane = drm_atomic_helper_disable_plane,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
-- 
1.7.10.4

[PATCH 2/7] drm/cirrus: phase 2: wire up state reset, duplicate and destroy

[John Hunter]

From: Zhao Junwang 

Set CRTC, planes and connectors to use the default implementations
from the atomic helper library.

Signed-off-by: Zhao Junwang 
---
 drivers/gpu/drm/cirrus/cirrus_mode.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 7a7c874..42a4d86 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -304,6 +305,9 @@ static const struct drm_crtc_funcs cirrus_crtc_funcs = {
.gamma_set = cirrus_crtc_gamma_set,
.set_config = drm_crtc_helper_set_config,
.destroy = cirrus_crtc_destroy,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };

 static const struct drm_crtc_helper_funcs cirrus_helper_funcs = {
@@ -429,6 +433,9 @@ static void cirrus_plane_atomic_disable(struct drm_plane 
*plane,
 static const struct drm_plane_funcs cirrus_plane_funcs = {
.update_plane = drm_plane_helper_update,
.disable_plane = drm_plane_helper_disable,
+   .reset = drm_atomic_helper_plane_reset,
+   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
 };

 static const struct drm_plane_helper_funcs cirrus_plane_helper_funcs = {
@@ -593,6 +600,9 @@ struct drm_connector_funcs cirrus_vga_connector_funcs = {
.detect = cirrus_vga_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = cirrus_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static struct drm_connector *cirrus_vga_init(struct drm_device *dev)
@@ -648,6 +658,8 @@ int cirrus_modeset_init(struct cirrus_device *cdev)
return -1;
}

+   drm_mode_config_reset(cdev->dev);
+
drm_mode_connector_attach_encoder(connector, encoder);

ret = cirrus_fbdev_init(cdev);
-- 
1.7.10.4

[PATCH 1/7] drm/cirrus: phase 1 - use the transitional helpers

[John Hunter]

From: Zhao Junwang 

-register driver's own primary plane
-use drm_crtc_init_with_planes instead drm_crtc_init

-the new atomic_infrastructure needs ->mode_set_nofb callback

Signed-off-by: Zhao Junwang 
---
 drivers/gpu/drm/cirrus/cirrus_drv.c  |1 -
 drivers/gpu/drm/cirrus/cirrus_drv.h  |3 +-
 drivers/gpu/drm/cirrus/cirrus_main.c |2 +-
 drivers/gpu/drm/cirrus/cirrus_mode.c |  201 +-
 4 files changed, 129 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 08bd176..80f1cd2 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -40,7 +40,6 @@ static const struct pci_device_id pciidlist[] = {
{0,}
 };

-
 static int cirrus_kick_out_firmware_fb(struct pci_dev *pdev)
 {
struct apertures_struct *ap;
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 7050615..bd1ff51 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -135,8 +135,9 @@ struct cirrus_device {
resource_size_t rmmio_size;
void __iomem*rmmio;

-   struct cirrus_mcmc;
+   struct cirrus_mcmc;
struct cirrus_mode_info mode_info;
+   struct drm_planeprimary;

int num_crtc;
int fb_mtrr;
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index e4b9766..d95de34 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -308,10 +308,10 @@ cirrus_dumb_mmap_offset(struct drm_file *file,

drm_gem_object_unreference(obj);
ret = 0;
+
 out_unlock:
mutex_unlock(&dev->struct_mutex);
return ret;
-
 }

 bool cirrus_check_framebuffer(struct cirrus_device *cdev, int width, int 
height,
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 61385f2..7a7c874 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -27,6 +27,10 @@
 #define PALETTE_INDEX 0x8
 #define PALETTE_DATA 0x9

+static const uint32_t cirrus_primary_formats[] = {
+   DRM_FORMAT_RGB888,
+};
+
 /*
  * This file contains setup code for the CRTC.
  */
@@ -126,77 +130,11 @@ static void cirrus_set_start_address(struct drm_crtc 
*crtc, unsigned offset)
WREG_CRT(0x1d, tmp);
 }

-/* cirrus is different - we will force move buffers out of VRAM */
-static int cirrus_crtc_do_set_base(struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   int x, int y, int atomic)
-{
-   struct cirrus_device *cdev = crtc->dev->dev_private;
-   struct drm_gem_object *obj;
-   struct cirrus_framebuffer *cirrus_fb;
-   struct cirrus_bo *bo;
-   int ret;
-   u64 gpu_addr;
-
-   /* push the previous fb to system ram */
-   if (!atomic && fb) {
-   cirrus_fb = to_cirrus_framebuffer(fb);
-   obj = cirrus_fb->obj;
-   bo = gem_to_cirrus_bo(obj);
-   ret = cirrus_bo_reserve(bo, false);
-   if (ret)
-   return ret;
-   cirrus_bo_push_sysram(bo);
-   cirrus_bo_unreserve(bo);
-   }
-
-   cirrus_fb = to_cirrus_framebuffer(crtc->primary->fb);
-   obj = cirrus_fb->obj;
-   bo = gem_to_cirrus_bo(obj);
-
-   ret = cirrus_bo_reserve(bo, false);
-   if (ret)
-   return ret;
-
-   ret = cirrus_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr);
-   if (ret) {
-   cirrus_bo_unreserve(bo);
-   return ret;
-   }
-
-   if (&cdev->mode_info.gfbdev->gfb == cirrus_fb) {
-   /* if pushing console in kmap it */
-   ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
-   if (ret)
-   DRM_ERROR("failed to kmap fbcon\n");
-   }
-   cirrus_bo_unreserve(bo);
-
-   cirrus_set_start_address(crtc, (u32)gpu_addr);
-   return 0;
-}
-
-static int cirrus_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
-struct drm_framebuffer *old_fb)
-{
-   return cirrus_crtc_do_set_base(crtc, old_fb, x, y, 0);
-}
-
-/*
- * The meat of this driver. The core passes us a mode and we have to program
- * it. The modesetting here is the bare minimum required to satisfy the qemu
- * emulation of this hardware, and running this against a real device is
- * likely to result in an inadequately programmed mode. We've already had
- * the opportunity to modify the mode, so whatever we receive here should
- * be something that can be correctly programmed and displayed
- */
-static int cirrus_crtc_mode_set(struct drm_crtc *crtc,
-   struct drm_display_mode *mode,
-   

[PATCH 0/7] drm/cirrus: convert cirrus to atomic mode-setting

[John Hunter]

From: Zhao Junwang 

This patch series aim to convert DRM_CIRRUS to atomic mode-setting.
This mostly reference my previous patch series on DRM_BOCHS and
Gustavo Padovan;s patch series on drm/exynos.

Zhao Junwang (7):
  drm/cirrus: phase 1 - use the transitional helpers
  drm/cirrus: phase 2: wire up state reset, duplicate and destroy
  drm/cirrus: phase 3: atomic updates of planes
  drm/cirrus: add return 0 to make sure if (bo->pin_count) early_exit
  drm/cirrus: phase 3: use atomic .set_config helper
  drm/cirrus: atomic dpms support
  drm/cirrus: add DRIVER_ATOMIC to .driver_features

 drivers/gpu/drm/cirrus/cirrus_drv.c  |3 +-
 drivers/gpu/drm/cirrus/cirrus_drv.h  |3 +-
 drivers/gpu/drm/cirrus/cirrus_main.c |5 +-
 drivers/gpu/drm/cirrus/cirrus_mode.c |  299 --
 drivers/gpu/drm/cirrus/cirrus_ttm.c  |2 +
 5 files changed, 187 insertions(+), 125 deletions(-)

-- 
1.7.10.4

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Daniel Vetter]

On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> > but I couldn't test them yet since no dp mst here and I didn't find
> > anything that would ship faster than 1-2 weeks yet. I'll try to get some
> > other people here to test it meanwhile too.
> 
> I've tried pulling in your patches from fixes-stuff, onto Linus's tree
> (without Linus's fix), and the good news is that I'm no longer
> crashing on boot.

Ok so I'm not completely clueless yet, the encoder confusion indeed
resulted in the follow-up crash. But obviously I don't understand yet
exactly what's going on if this breaks the display.

> The *bad* news is that (a) it breaks the external monitor attached to
> the docking station completely (this was working with Linus's patch),
> and (b) it's triggering a LOCKDEP failure.

The lockdep splat is all in the driver load before we do any modeset at
all, so shouldn't have changed between these patches. Are you sure it's a
regression due to mine and wasn't there before?

> So even though Linus's patch wasn't supposed to work, I think I'm
> going to back to it

Well I found some dp mst hubs meanwhile so hopefully tomorrow I can test
myself what's going wrong here.
-Daniel

> 
>   - Ted
> 
> 
> Jul 30 11:46:49 closure kernel: [4.221951] 
> Jul 30 11:46:49 closure kernel: [4.221954] 
> ==
> Jul 30 11:46:49 closure kernel: [4.221957] [ INFO: possible circular 
> locking dependency detected ]
> Jul 30 11:46:49 closure kernel: [4.221960] 4.2.0-rc4-13906-g5f1b75cd #16 
> Not tainted
> Jul 30 11:46:49 closure kernel: [4.221963] 
> ---
> Jul 30 11:46:49 closure kernel: [4.221966] modprobe/503 is trying to 
> acquire lock:
> Jul 30 11:46:49 closure kernel: [4.221968]  (init_mutex){+.+.+.}, at: 
> [] acpi_video_get_backlight_type+0x17/0x164
> Jul 30 11:46:49 closure kernel: [4.221977] 
> Jul 30 11:46:49 closure kernel: [4.221977] but task is already holding 
> lock:
> Jul 30 11:46:49 closure kernel: [4.221979]  
> (&(&backlight_notifier)->rwsem){..}, at: [] 
> __blocking_notifier_call_chain+0x37/0x69
> Jul 30 11:46:49 closure kernel: [4.221987] 
> Jul 30 11:46:49 closure kernel: [4.221987] which lock already depends on 
> the new lock.
> Jul 30 11:46:49 closure kernel: [4.221987] 
> Jul 30 11:46:49 closure kernel: [4.221990] 
> Jul 30 11:46:49 closure kernel: [4.221990] the existing dependency chain 
> (in reverse order) is:
> Jul 30 11:46:49 closure kernel: [4.221995] 
> Jul 30 11:46:49 closure kernel: [4.221995] -> #1 
> (&(&backlight_notifier)->rwsem){..}:
> Jul 30 11:46:49 closure kernel: [4.222001][] 
> lock_acquire+0x104/0x18b
> Jul 30 11:46:49 closure kernel: [4.222007][] 
> down_write+0x46/0x8a
> Jul 30 11:46:49 closure kernel: [4.222012][] 
> blocking_notifier_chain_register+0x36/0x57
> Jul 30 11:46:49 closure kernel: [4.222017][] 
> backlight_register_notifier+0x18/0x1a
> Jul 30 11:46:49 closure kernel: [4.222022][] 
> acpi_video_get_backlight_type+0xfa/0x164
> Jul 30 11:46:49 closure kernel: [4.222028][] 
> 0xc03a1e45
> Jul 30 11:46:49 closure audispd: No plugins found, exiting
> Jul 30 11:46:49 closure kernel: [4.222032][] 
> 0xc03a28a8
> Jul 30 11:46:49 closure kernel: [4.222036][] 
> do_one_initcall+0x19a/0x1af
> Jul 30 11:46:49 closure kernel: [4.222042][] 
> do_init_module+0x60/0x1e3
> Jul 30 11:46:49 closure kernel: [4.222047][] 
> load_module+0x1c42/0x2059
> Jul 30 11:46:49 closure kernel: [4.222052][] 
> SyS_finit_module+0x85/0x92
> Jul 30 11:46:49 closure kernel: [4.222056][] 
> entry_SYSCALL_64_fastpath+0x16/0x73
> Jul 30 11:46:49 closure kernel: [4.222060] 
> Jul 30 11:46:49 closure kernel: [4.222060] -> #0 (init_mutex){+.+.+.}:
> Jul 30 11:46:49 closure kernel: [4.222065][] 
> __lock_acquire+0xc55/0xf54
> Jul 30 11:46:49 closure kernel: [4.222070][] 
> lock_acquire+0x104/0x18b
> Jul 30 11:46:49 closure kernel: [4.222074][] 
> mutex_lock_nested+0x70/0x391
> Jul 30 11:46:49 closure kernel: [4.222078][] 
> acpi_video_get_backlight_type+0x17/0x164
> Jul 30 11:46:49 closure kernel: [4.222083][] 
> acpi_video_backlight_notify+0x19/0x2f
> Jul 30 11:46:49 closure kernel: [4.222088][] 
> notifier_call_chain+0x4c/0x71
> Jul 30 11:46:49 closure kernel: [4.222092][] 
> __blocking_notifier_call_chain+0x50/0x69
> Jul 30 11:46:49 closure kernel: [4.222098][] 
> blocking_notifier_call_chain+0x14/0x16
> Jul 30 11:46:49 closure kernel: [4.222103][] 
> backlight_device_regist

[Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Takashi Iwai]

On Thu, 30 Jul 2015 17:32:28 +0200,
Theodore Ts'o wrote:
> 
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> > >  drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> > >  1 file changed, 5 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 5b59d5ad7d1c..aac212297b49 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state 
> > > *state, int conn_idx)
> > >   }
> > >  
> > >   connector_state->best_encoder = new_encoder;
> > > - idx = drm_crtc_index(connector_state->crtc);
> > > + if (connector_state->crtc) {
> > > + idx = drm_crtc_index(connector_state->crtc);
> > >  
> > > - crtc_state = state->crtc_states[idx];
> > > - crtc_state->mode_changed = true;
> > > + crtc_state = state->crtc_states[idx];
> > > + crtc_state->mode_changed = true;
> > > + }
> > 
> > This shouldn't happen since if it does we ended up stealing the encoder
> > from the connector itself (we do check for connector_state->crtc earlier)
> > and that would be a bug. I haven't figured out a precise theory but my
> > guess is on the best_encoder selection, and indeed dp mst encoder
> > selection seems to have gone belly up in 4.2 with the bisected commit.
> 
> Well, I just tested Linus's patch and it works.
> 
> BTW, is there any chance that I can suspend my laptop, and then move
> it from my docking station at home (where I have a Dell 30" display)
> to my docking station at work (where I have a Dell 24" display), and
> actually have the new monitor be detected?  For at least the past
> year, I have to reboot in order to be able to use the external
> monitor?  This used to work, but it's been a very long-standing
> regression.  I undrstand that Multi-stream DP is a evil horrible hack,
> and supporting it is painful, but this used to work, and it hasn't in
> a long time.  :-(

Relevant with this?
   https://bugs.freedesktop.org/show_bug.cgi?id=89589

I wanted to check this by myself, too, as the same bug was reported to
openSUSE bugzilla, but I had no hardware showing it.


Takashi

[Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Daniel Vetter]

On Thu, Jul 30, 2015 at 5:32 PM, Theodore Ts'o  wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
>> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
>> >  drivers/gpu/drm/drm_atomic_helper.c | 8 +---
>> >  1 file changed, 5 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> > b/drivers/gpu/drm/drm_atomic_helper.c
>> > index 5b59d5ad7d1c..aac212297b49 100644
>> > --- a/drivers/gpu/drm/drm_atomic_helper.c
>> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> > @@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state 
>> > *state, int conn_idx)
>> > }
>> >
>> > connector_state->best_encoder = new_encoder;
>> > -   idx = drm_crtc_index(connector_state->crtc);
>> > +   if (connector_state->crtc) {
>> > +   idx = drm_crtc_index(connector_state->crtc);
>> >
>> > -   crtc_state = state->crtc_states[idx];
>> > -   crtc_state->mode_changed = true;
>> > +   crtc_state = state->crtc_states[idx];
>> > +   crtc_state->mode_changed = true;
>> > +   }
>>
>> This shouldn't happen since if it does we ended up stealing the encoder
>> from the connector itself (we do check for connector_state->crtc earlier)
>> and that would be a bug. I haven't figured out a precise theory but my
>> guess is on the best_encoder selection, and indeed dp mst encoder
>> selection seems to have gone belly up in 4.2 with the bisected commit.
>
> Well, I just tested Linus's patch and it works.

That's sersiously surprising if you mean display and everything actually
works. Is dpms on/off and suspend and all that also still working? Can you
please changed the check into a

if (!connector_state->crtc)
return 0;

so that we don't blow up on the debug line below and then grab dmesg with
drm.debug=0x1e when this happens? Note there will be lots of noise you
might need to dig out full dmesg from logs.

> BTW, is there any chance that I can suspend my laptop, and then move
> it from my docking station at home (where I have a Dell 30" display)
> to my docking station at work (where I have a Dell 24" display), and
> actually have the new monitor be detected?  For at least the past
> year, I have to reboot in order to be able to use the external
> monitor?  This used to work, but it's been a very long-standing
> regression.  I undrstand that Multi-stream DP is a evil horrible hack,
> and supporting it is painful, but this used to work, and it hasn't in
> a long time.  :-(

Hm we seem to not reprobe mst state on resume. The quick hack below should
help (but totally untested since still no dp mst hub here).
-Daniel

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 884b4f9b81c4..c0677c83a0e9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -775,6 +775,9 @@ static int i915_drm_resume(struct drm_device *dev)
/* Config may have changed between suspend and resume */
drm_helper_hpd_irq_event(dev);

+   dev_priv->short_hpd_port_mask = ~0;
+   queue_work(dev_priv->dp_wq, &dev_priv->dig_port_work);
+
intel_opregion_init(dev);

intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Peter Hurley]

[ +cc Debian maintainer ]

On 07/30/2015 11:26 AM, Emil Velikov wrote:
> On 30 July 2015 at 16:02, Ilia Mirkin  wrote:
>> On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
>>  wrote:
>>> On 30/07/15 15:52, Bryan O'Donoghue wrote:

 On 30/07/15 15:49, Peter Hurley wrote:
>
> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>>
>> Is this happening with libdrm 2.4.60? If so, that's a known
>> (user-side) issue and should be fixed by using any version but that
>> one.
>
>
> What's the freedesktop bugzilla # for reference?
>
> Regards,
> Peter Hurley


 I believe it's this one

 https://bugs.freedesktop.org/show_bug.cgi?id=89842#c19

>>>
>>> Not really a world of choice on ubuntu to fix it though...
>>>
>>> deckard at aineko:~/Development/projectara$ apt-show-versions libdrm2
>>> libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
>>> libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
>>>
>>> :(
>>
>> That's unfortunate. I know next to nothing about debian/ubuntu or how
>> they do versions or how to even build packages for them. But they're
>> big distros, presumably they have support teams of some sort, perhaps
>> they can help you.
>>
>> Assuming that switching away does resolve the issue for you, perhaps
>> you can also recommend that they avoid shipping that version, or
>> include this nouveau fix in it:
>>
>> http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c788c61f546294
>>
> Fwiw debian has been tracking this as #789759, and they are shipping
> 2.4.62 which includes the fix.

Unfortunately the LTS version of Ubuntu (trusty) was updated to 2.4.60
several days ago without this fix.

I repackaged libdrm 2.4.60 with only the bug fix above and confirm the
patch above fixes the observed behavior in freedesktop bug# 89842/
debian bug# 789759.

I pushed the repackage to Launchpad PPA @ ppa:phurley/libdrm

Hopefully the Debian maintainer grabs this fix and updates the official
distribution version soon.

Regards,
Peter Hurley

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73528

--- Comment #41 from MWATTT  ---
I'm able to reproduce the bug (with commit
97ec2c694fe568e375ec7a2b85c1acb1e4666b54 reverted) with a small program after
viewing a minecraft apitrace.

Apparently, if 2 textures are attached to a fbo (as GL_COLOR_ATTACHMENT0,
GL_COLOR_ATTACHMENT1), GL_COLOR_ATTACHMENT1 is cleared and after that
glDrawBuffers(2, {GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1}) is called, but
the shader of the following drawing command doesn't write anything in the
second buffer (GL_COLOR_ATTACHMENT1), then it will hang.

I've attached a small code which reproduce the hang.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/f3c1e889/attachment-0001.html>

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Daniel Vetter]

On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
>  drivers/gpu/drm/drm_atomic_helper.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5b59d5ad7d1c..aac212297b49 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state 
> *state, int conn_idx)
>   }
>  
>   connector_state->best_encoder = new_encoder;
> - idx = drm_crtc_index(connector_state->crtc);
> + if (connector_state->crtc) {
> + idx = drm_crtc_index(connector_state->crtc);
>  
> - crtc_state = state->crtc_states[idx];
> - crtc_state->mode_changed = true;
> + crtc_state = state->crtc_states[idx];
> + crtc_state->mode_changed = true;
> + }

This shouldn't happen since if it does we ended up stealing the encoder
from the connector itself (we do check for connector_state->crtc earlier)
and that would be a bug. I haven't figured out a precise theory but my
guess is on the best_encoder selection, and indeed dp mst encoder
selection seems to have gone belly up in 4.2 with the bisected commit.

I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
but I couldn't test them yet since no dp mst here and I didn't find
anything that would ship faster than 1-2 weeks yet. I'll try to get some
other people here to test it meanwhile too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73528

--- Comment #40 from MWATTT  ---
Created attachment 117466
  --> https://bugs.freedesktop.org/attachment.cgi?id=117466&action=edit
fast color clear hang code

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/01355738/attachment.html>

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Emil Velikov]

On 30 July 2015 at 16:02, Ilia Mirkin  wrote:
> On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
>  wrote:
>> On 30/07/15 15:52, Bryan O'Donoghue wrote:
>>>
>>> On 30/07/15 15:49, Peter Hurley wrote:

 On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.


 What's the freedesktop bugzilla # for reference?

 Regards,
 Peter Hurley
>>>
>>>
>>> I believe it's this one
>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=89842#c19
>>>
>>
>> Not really a world of choice on ubuntu to fix it though...
>>
>> deckard at aineko:~/Development/projectara$ apt-show-versions libdrm2
>> libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
>> libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
>>
>> :(
>
> That's unfortunate. I know next to nothing about debian/ubuntu or how
> they do versions or how to even build packages for them. But they're
> big distros, presumably they have support teams of some sort, perhaps
> they can help you.
>
> Assuming that switching away does resolve the issue for you, perhaps
> you can also recommend that they avoid shipping that version, or
> include this nouveau fix in it:
>
> http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c788c61f546294
>
Fwiw debian has been tracking this as #789759, and they are shipping
2.4.62 which includes the fix.

> This whole libdrm thing is a bit of a cluster%@#$ unfortunately --
> 2.4.60 is broken for nouveau, building even the latest released
> xf86-video-intel against 2.4.61+ causes it to not start ("fixed" in
> xf86-video-intel git), and newer mesa requires libdrm 2.4.60+.
>
I'm wondering if xf86-video-intel cannot, use libdrm's "features"
rather than having a local copy of every drm change for the last 2
years. If bumping the requirement is not an option, then having a few
build/compile time checks should do just fine.

Either way I'm glad that it wasn't me how broke that one :-P

-Emil

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Bryan O'Donoghue]

On 30/07/15 16:02, Ilia Mirkin wrote:
>
> That's unfortunate. I know next to nothing about debian/ubuntu or how
> they do versions or how to even build packages for them. But they're
> big distros, presumably they have support teams of some sort, perhaps
> they can help you.
>
> Assuming that switching away does resolve the issue for you, perhaps
> you can also recommend that they avoid shipping that version, or
> include this nouveau fix in it:
>
> http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c788c61f546294
>
> This whole libdrm thing is a bit of a cluster%@#$ unfortunately --
> 2.4.60 is broken for nouveau, building even the latest released
> xf86-video-intel against 2.4.61+ causes it to not start ("fixed" in
> xf86-video-intel git), and newer mesa requires libdrm 2.4.60+.
>
>-ilia
>

Matter of fact

apt-cache show libdrm2
sudo apt-get install libdrm2=2.4.56-1~ubuntu2
#sudo echo “package libdrm2” | sudo dpkg –set-selections

I'll give it a go at the end of the working day - should give enough 
time to recover if it all goes spectacularly wrong :)

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Bryan O'Donoghue]

On 30/07/15 15:52, Bryan O'Donoghue wrote:
> On 30/07/15 15:49, Peter Hurley wrote:
>> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>>> Is this happening with libdrm 2.4.60? If so, that's a known
>>> (user-side) issue and should be fixed by using any version but that
>>> one.
>>
>> What's the freedesktop bugzilla # for reference?
>>
>> Regards,
>> Peter Hurley
>
> I believe it's this one
>
> https://bugs.freedesktop.org/show_bug.cgi?id=89842#c19
>

Not really a world of choice on ubuntu to fix it though...

deckard at aineko:~/Development/projectara$ apt-show-versions libdrm2
libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate

:(

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Bryan O'Donoghue]

On 30/07/15 15:49, Peter Hurley wrote:
> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>> Is this happening with libdrm 2.4.60? If so, that's a known
>> (user-side) issue and should be fixed by using any version but that
>> one.
>
> What's the freedesktop bugzilla # for reference?
>
> Regards,
> Peter Hurley

I believe it's this one

https://bugs.freedesktop.org/show_bug.cgi?id=89842#c19

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Bryan O'Donoghue]

On 30/07/15 15:12, Ilia Mirkin wrote:
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.
>

Yes that's my version 2.4.60.

[Nouveau] [PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

[Hans de Goede]

Hi,

On 27-07-15 17:52, Hans de Goede wrote:

> Slightly offtopic:
>
> I decided to be bold and try gnome-shell on the nv46 with msi disabled,
> which sofar was a guaranteed way to freeze the system, and it now works
> somewhat (latest kernel, ddx and mesa). I see something which shows
> horizontal lines which are small parts from my desktop background, and
> things change significantly when I switch to the overview mode.
>
> But other then that the display is completely wrong, it looks a bit
> like a framebuffer pitch problem, but then different. I think it
> is likely some tiling problem or some such.
>
> Note that metacity + glxgears works, this only shows with
> gnome-shell, any hints where to start looking wrt debugging this?
>
> Or should I first try to run piglet and see if some tests there
> point out the culprit?

I've been working on this today, I decided to first make sure
that the latest ddx + mesa did not have a regression on nv4x in
general, so I plugged in my nv43 card which used to run gnome-shell
fine and that shows the same problem.

Some debugging with that card shows that things break with this
ddx commit:

http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e7289f25a342a457952b9b0e539c2f0b81d99

"enable dri3 support without glamor"

Using an older ddx + latest mesa master gnome-shell runs fine
on my nv43 card.

And adding my patch to disable msi interrupts on nv46 makes
gnome-shell run fine on my nv46 card too :)

So unless someone has a good idea to fix msi interrupts on
nv46, I suggest we merge my patch to disable them
(with a Cc: stable at vger.kernel.org), which should fix most
problems nv46 users have been seeing.

Regards,

Hans

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91253

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 91041 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/56152a34/attachment.html>

[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91041

Alex Deucher  changed:

   What|Removed |Added

 CC||andreas.tunek at gmail.com

--- Comment #17 from Alex Deucher  ---
*** Bug 91253 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/1ed4ce64/attachment.html>

[PATCH v2 21/22 EXPERIMENTAL] drm/nouveau/i2c: Use vga_switcheroo active client as proxy when reading DDC/AUX

[Lukas Wunner]

The retina MacBook Pro uses an eDP panel and a gmux controller to switch
the panel between its two GPUs. Unfortunately it seems that it cannot
switch the AUX channel separately from the main link.

But we can emulate switching of DDC/AUX in software by using the active
client as a proxy to talk to the panel.

Proxying of the AUX channel is facilitated by way of Thierry Reding's
awesome struct drm_dp_aux abstraction (cf. c197db75ff5c, "drm/dp: Add
AUX channel infrastructure"). However, as regards usage of struct
drm_dp_aux, nouveau is the odd man out: A struct drm_dp_aux is defined
as part of struct nouveau_connector but never used. Instead, the AUX
channel is accessed directly with nv_rdaux() and nv_wraux(), even in
the DRM part of the driver.

To enable proxying in nouveau, inject a pointer to the struct drm_dp_aux
from the DRM part of the driver into the struct nvkm_i2c_port. Modify
nv_rdaux() to try drm_dp_dpcd_read() first. If that fails, fall back to
accessing the AUX channel directly. Enclose in #if IS_ENABLED(CONFIG_DRM
_KMS_HELPER) to keep the NVKM part of the driver portable and free of
DRM symbols.

Obviously this is a bit of a kludge but it seems there's no elegant way
short of factoring all the AUX communication in dport.c / outpdp.c out
and into the DRM part of the driver (plus the AUX initialization in
VBIOS).

When the driver first initializes the output with nvkm_output_dp_init(),
the pointer to the struct drm_dp_aux is not yet injected into the struct
nvkm_i2c_port. Thus, if the panel is not switched to the Nvidia GPU,
the dpcd attribute of struct nvkm_output_dp can't be filled and the link
doesn't get trained. Make up for this by checking the link training
status in nouveau_dp_detect() and calling nvkm_output_dp_detect()
if the link hasn't been trained yet.

Modify link training itself so that it does not fail when writing to
DPCD if the value to be written is identical with what's already
configured in DPCD. (Proxying is currently read only for safety
reasons.)

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko 
[MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
Tested-by: William Brown 
[MBP  8,2 2011  intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner 
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
Tested-by: Bruno Bierbaumer 
[MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h |  1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c   |  4 ++--
 drivers/gpu/drm/nouveau/nouveau_dp.c  | 20 +++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/dport.c  |  6 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/outpdp.c |  2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/outpdp.h |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 24 +++
 7 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
index a2e3373..9fa95fb 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
@@ -37,6 +37,7 @@ struct nvkm_i2c_port {
struct list_head head;
u8  index;
int aux;
+   void *drm_dp_aux;

const struct nvkm_i2c_func *func;
 };
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 1e5224f..159df7f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -144,8 +144,8 @@ nouveau_connector_ddc_detect(struct drm_connector 
*connector)
nv_encoder = nouveau_encoder(encoder);

if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
-   int ret = nouveau_dp_detect(nv_encoder);
-   if (ret == 0)
+   nv_encoder->i2c->drm_dp_aux = &nv_connector->aux;
+   if (nouveau_dp_detect(nv_encoder) == 0)
break;
} else
if (nv_encoder->i2c) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index c3ef30b..317d6b1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -30,6 +30,25 @@
 #include "nouveau_encoder.h"
 #include "nouveau_crtc.h"

+#include 
+#include 
+
+static void
+nouveau_dp_check_link_training(struct nouveau_encoder *nv_encoder)
+{
+   struct nvkm_disp *disp = nvkm_disp(nv_encoder->i2c);
+   struct nvkm_output *outp;
+   struct nvkm_output_dp *outpdp;
+
+   list_for_each_entry(outp, &disp->outp, head)
+   if (outp->info.index == nv_encoder->dcb->index)
+   break;
+
+   outpdp = (struct nvkm_output_dp *)outp;
+   if (!atomic_read

[PATCH v3 1/9] drm/exynos: pass the correct pipe number

[Inki Dae]

Hi Gustavo,


On 2015년 07월 30일 05:11, Gustavo Padovan wrote:
> Hi Inki,
> 
> Any comments about this series?

Will review all of them. Now we are reviewing fix-up and clean-up patches.

Thanks,
Inki Dae

> 
> Thanks,
>   
>   Gustavo
> 
> 2015-07-16 Gustavo Padovan :
> 
>> From: Gustavo Padovan 
>>
>> Instead of giving -1 to as arg to  drm_send_vblank_event() pass the
>> correct pipe number to it.
>>
>> Signed-off-by: Gustavo Padovan 
>> Reviewed-by: Joonyoung Shim 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 644b4b7..22b9ca0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -203,7 +203,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
>> *dev, int pipe)
>>  spin_lock_irqsave(&dev->event_lock, flags);
>>  if (exynos_crtc->event) {
>>  
>> -drm_send_vblank_event(dev, -1, exynos_crtc->event);
>> +drm_send_vblank_event(dev, pipe, exynos_crtc->event);
>>  drm_vblank_put(dev, pipe);
>>  wake_up(&exynos_crtc->pending_flip_queue);
>>  
>> -- 
>> 2.1.0
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[Bug 91509] Depth render buffer corruption

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #2 from Stefan Dösinger  ---
It seems that the corruption has something to do with FBO sizes where the width
is a multiple of 16. width = 112 to 128 works OK. 129 to 143 is broken. 144 to
160 works, 161 to 175 is broken and so on.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/4ae50a58/attachment.html>

[Bug 91509] Depth render buffer corruption

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #1 from Stefan Dösinger  ---
Created attachment 117463
  --> https://bugs.freedesktop.org/attachment.cgi?id=117463&action=edit
Screenshot without FBOs

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/b700d7c9/attachment-0001.html>

[Bug 91509] Depth render buffer corruption

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

Bug ID: 91509
   Summary: Depth render buffer corruption
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: stefandoesinger at gmx.at
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 117462
  --> https://bugs.freedesktop.org/attachment.cgi?id=117462&action=edit
Screenshot

Since my patches from a few months ago Wine can now use depth renderbuffers
instead of textures for FBOs if GL_ARB_depth_texture is not supported. This
makes FBOs work on r200, but it appears that there is some render corruption.
The best way to describe it is that some parts of the depth buffer seem to be
read or written to the wrong place inside the buffer.

The attached screenshots show the issue. The application I've run here is the
StencilMirror.exe sample from the DirectX 8 SDK. in fbo.png you see incorrect
draws at the edges of the window. nofbo.png uses the GLX drawable (GL_BACK)
instead of rendering to an FBO, which doesn't show the corruption.

The corruption seems to be resolution dependent. I don't see it when I am
running the application at 1400x1050 for example.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/80b64b8a/attachment.html>

linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/drm_crtc.c

between commit:

  5677d67ae394 ("drm: Stop resetting connector state to unknown")

from Linus' tree and commit:

  1c473be11958 ("drm: Fixup locking WARNINGs in drm_mode_config_reset")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/drm_crtc.c
index c91c18b2b1d4,7d02e32b4e94..
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@@ -5273,9 -5273,14 +5273,11 @@@ void drm_mode_config_reset(struct drm_d
if (encoder->funcs->reset)
encoder->funcs->reset(encoder);

+   mutex_lock(&dev->mode_config.mutex);
 -  drm_for_each_connector(connector, dev) {
 -  connector->status = connector_status_unknown;
 -
 +  drm_for_each_connector(connector, dev)
if (connector->funcs->reset)
connector->funcs->reset(connector);
 -  }
+   mutex_unlock(&dev->mode_config.mutex);
  }
  EXPORT_SYMBOL(drm_mode_config_reset);

[PATCH v3 09/24] i915: switch from acpi_os_ioremap to memremap

[Dan Williams]

i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx at lists.freedesktop.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |2 -
 drivers/gpu/drm/i915/i915_drv.h   |   12 ++---
 drivers/gpu/drm/i915/intel_bios.c |7 +--
 drivers/gpu/drm/i915/intel_opregion.c |   87 -
 drivers/gpu/drm/i915/intel_panel.c|2 -
 5 files changed, 52 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 82bbe3f2a7e1..9228d6048bde 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1831,7 +1831,7 @@ static int i915_opregion(struct seq_file *m, void *unused)
goto out;

if (opregion->header) {
-   memcpy_fromio(data, opregion->header, OPREGION_SIZE);
+   memcpy(data, opregion->header, OPREGION_SIZE);
seq_write(m, data, OPREGION_SIZE);
}

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5f27290201e0..2efbfd53be51 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -403,14 +403,14 @@ struct opregion_swsci;
 struct opregion_asle;

 struct intel_opregion {
-   struct opregion_header __iomem *header;
-   struct opregion_acpi __iomem *acpi;
-   struct opregion_swsci __iomem *swsci;
+   struct opregion_header *header;
+   struct opregion_acpi *acpi;
+   struct opregion_swsci *swsci;
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
-   struct opregion_asle __iomem *asle;
-   void __iomem *vbt;
-   u32 __iomem *lid_state;
+   struct opregion_asle *asle;
+   void *vbt;
+   u32 *lid_state;
struct work_struct asle_work;
 };
 #define OPREGION_SIZE(8*1024)
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 198fc3c3291b..3e2dca4f5e6e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1206,11 +1206,10 @@ static const struct bdb_header *validate_vbt(const void 
__iomem *_base,
 {
/*
 * This is the one place where we explicitly discard the address space
-* (__iomem) of the BIOS/VBT. (And this will cause a sparse complaint.)
-* From now on everything is based on 'base', and treated as regular
-* memory.
+* (__iomem) of the BIOS/VBT. From now on everything is based on
+* 'base', and treated as regular memory.
 */
-   const void *base = (const void *) _base;
+   const void *base = (const void __force *) _base;
size_t offset = _vbt - _base;
const struct vbt_header *vbt = base + offset;
const struct bdb_header *bdb;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 481337436f72..7deed1062871 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -232,7 +232,7 @@ struct opregion_asle {
 static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci;
+   struct opregion_swsci *swsci = dev_priv->opregion.swsci;
u32 main_function, sub_function, scic;
u16 pci_swsci;
u32 dslp;
@@ -257,7 +257,7 @@ static int swsci(struct drm_device *dev, u32 function, u32 
parm, u32 *parm_out)
}

/* Driver sleep timeout in ms. */
-   dslp = ioread32(&swsci->dslp);
+   dslp = swsci->dslp;
if (!dslp) {
/* The spec says 2ms should be the default, but it's too small
 * for some machines. */
@@ -270,7 +270,7 @@ static int swsci(struct drm_device *dev, u32 function, u32 
parm, u32 *parm_out)
}

/* The spec tells us to do this, but we are the only user... */
-   scic = ioread32(&swsci->scic);
+   scic = swsci->scic;
if (scic & SWSCI_SCIC_INDICATOR) {
DRM_DEBUG_DRIVER("SWSCI request already in progress\n");
return -EBUSY;
@@ -278,8 +278,8 @@ static int swsci(struct drm_device *dev, u32 function, u32 
parm, u32 *parm_out)

scic = function | SWSCI_SCIC_INDICATOR;

-   iowrite32(parm, &swsci->parm);
-   iowrite32(scic, &swsci->scic);
+   swsci->parm = parm;
+   swsci->scic = scic;

/* Ensure SCI event is selected and event trigger is cleared. */
pci_read_config_word(dev->pdev, PCI_SWSCI, &pci_swsci);
@@ -294,7 +294,7 @@ static int swsci(struct drm_device *dev, u32 function, u32 
parm, u32 *parm_out)
pci_write_config_word(dev->pdev, PCI_SWSCI, pci_s

[PATCH v3 08/24] gma500: switch from acpi_os_ioremap to memremap

[Dan Williams]

gma500 expects the OpRegion to be cached (i.e. not __iomem), so
explicitly map it with memremap rather than the implied cache setting of
acpi_os_ioremap().

Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams 
---
 drivers/gpu/drm/gma500/opregion.c |8 
 drivers/gpu/drm/gma500/psb_drv.h  |2 +-
 drivers/gpu/drm/gma500/psb_lid.c  |8 
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/gma500/opregion.c 
b/drivers/gpu/drm/gma500/opregion.c
index ab696ca7eeec..7672ac4d4217 100644
--- a/drivers/gpu/drm/gma500/opregion.c
+++ b/drivers/gpu/drm/gma500/opregion.c
@@ -297,7 +297,7 @@ void psb_intel_opregion_fini(struct drm_device *dev)
cancel_work_sync(&opregion->asle_work);

/* just clear all opregion memory pointers now */
-   iounmap(opregion->header);
+   memunmap(opregion->header);
opregion->header = NULL;
opregion->acpi = NULL;
opregion->swsci = NULL;
@@ -310,8 +310,8 @@ int psb_intel_opregion_setup(struct drm_device *dev)
struct drm_psb_private *dev_priv = dev->dev_private;
struct psb_intel_opregion *opregion = &dev_priv->opregion;
u32 opregion_phy, mboxes;
-   void __iomem *base;
int err = 0;
+   void *base;

pci_read_config_dword(dev->pdev, PCI_ASLS, &opregion_phy);
if (opregion_phy == 0) {
@@ -322,7 +322,7 @@ int psb_intel_opregion_setup(struct drm_device *dev)
INIT_WORK(&opregion->asle_work, psb_intel_opregion_asle_work);

DRM_DEBUG("OpRegion detected at 0x%8x\n", opregion_phy);
-   base = acpi_os_ioremap(opregion_phy, 8*1024);
+   base = memremap(opregion_phy, 8*1024, MEMREMAP_WB);
if (!base)
return -ENOMEM;

@@ -351,7 +351,7 @@ int psb_intel_opregion_setup(struct drm_device *dev)
return 0;

 err_out:
-   iounmap(base);
+   memunmap(base);
return err;
 }

diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index e38057b91865..189f57135d47 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -253,7 +253,7 @@ struct psb_intel_opregion {
struct opregion_swsci *swsci;
struct opregion_asle *asle;
void *vbt;
-   u32 __iomem *lid_state;
+   u32 *lid_state;
struct work_struct asle_work;
 };

diff --git a/drivers/gpu/drm/gma500/psb_lid.c b/drivers/gpu/drm/gma500/psb_lid.c
index 1d2ebb5e530f..6b1b9d0741df 100644
--- a/drivers/gpu/drm/gma500/psb_lid.c
+++ b/drivers/gpu/drm/gma500/psb_lid.c
@@ -28,14 +28,14 @@ static void psb_lid_timer_func(unsigned long data)
struct drm_psb_private * dev_priv = (struct drm_psb_private *)data;
struct drm_device *dev = (struct drm_device *)dev_priv->dev;
struct timer_list *lid_timer = &dev_priv->lid_timer;
+   u32 *lid_state = dev_priv->opregion.lid_state;
unsigned long irq_flags;
-   u32 __iomem *lid_state = dev_priv->opregion.lid_state;
u32 pp_status;

-   if (readl(lid_state) == dev_priv->lid_last_state)
+   if (*lid_state == dev_priv->lid_last_state)
goto lid_timer_schedule;

-   if ((readl(lid_state)) & 0x01) {
+   if ((*lid_state) & 0x01) {
/*lid state is open*/
REG_WRITE(PP_CONTROL, REG_READ(PP_CONTROL) | POWER_TARGET_ON);
do {
@@ -58,7 +58,7 @@ static void psb_lid_timer_func(unsigned long data)
pp_status = REG_READ(PP_STATUS);
} while ((pp_status & PP_ON) == 0);
}
-   dev_priv->lid_last_state =  readl(lid_state);
+   dev_priv->lid_last_state =  *lid_state;

 lid_timer_schedule:
spin_lock_irqsave(&dev_priv->lid_lock, irq_flags);

[PATCH v3 00/24] replace ioremap_{cache|wt} with memremap

[Dan Williams]

Changes since v2 [1]:

1/ Move arch_memremap() and arch_memunmap() out of line (Christoph)

2/ Convert region_is_ram() to region_intersects() and define an enum for
   its 3 return values. (Luis)

3/ Fix gma500 and i915 to explicitly use cached mappings and clean up
   the __iomem usage. (Daniel)

4/ Kill unused ioremap aliases (ioremap_cached() and
   ioremap_fullcache()) (Christoph)

5/ Clarify some change logs and documentation (Luis, Christoph, and
   Ross)

6/ Add a unified CONFIG_MMU=n implementation with __weak symbols. (Luis)

---
While developing the pmem driver we noticed that the __iomem annotation
on the return value from ioremap_cache() was being mishandled by several
callers.  We also observed that all of the call sites expected to be
able to treat the return value from ioremap_cache() as normal
(non-__iomem) pointer to memory.

This patchset takes the opportunity to clean up the above confusion as
well as a few issues with the ioremap_{cache|wt} interface, including:

1/ Eliminating the possibility of function prototypes differing between
   architectures by defining a central memremap() prototype that takes
   flags to determine the mapping type.

2/ Returning NULL rather than falling back silently to a different
   mapping-type.  This allows drivers to be stricter about the
   mapping-type fallbacks that are permissible.

[1]: http://marc.info/?l=linux-arch&m=14377917405&w=2

---

Dan Williams (24):
  mm: enhance region_is_ram() to region_intersects()
  arch, drivers: don't include  directly, use  instead
  cleanup IORESOURCE_CACHEABLE vs ioremap()
  intel_iommu: fix leaked ioremap mapping
  arch: introduce memremap()
  arm: switch from ioremap_cache to memremap
  x86: switch from ioremap_cache to memremap
  gma500: switch from acpi_os_ioremap to memremap
  i915: switch from acpi_os_ioremap to memremap
  acpi: switch from ioremap_cache to memremap
  toshiba laptop: replace ioremap_cache with ioremap
  memconsole: fix __iomem mishandling, switch to memremap
  visorbus: switch from ioremap_cache to memremap
  intel-iommu: switch from ioremap_cache to memremap
  libnvdimm, pmem: push call to ioremap_cache out of line
  pxa2xx-flash: switch from ioremap_cache to memremap
  sfi: switch from ioremap_cache to memremap
  fbdev: switch from ioremap_wt to memremap
  pmem: switch from ioremap_wt to memremap
  arch: kill ioremap_cached()
  arch: kill ioremap_fullcache()
  arch: remove ioremap_cache, replace with arch_memremap
  arch: remove ioremap_wt, optionally replace with arch_memremap
  pmem: convert to generic memremap


 Documentation/x86/pat.txt  |6 +
 arch/arc/include/asm/io.h  |1 
 arch/arm/Kconfig   |1 
 arch/arm/include/asm/io.h  |7 --
 arch/arm/include/asm/xen/page.h|4 -
 arch/arm/mach-clps711x/board-cdb89712.c|2 
 arch/arm/mach-shmobile/pm-rcar.c   |2 
 arch/arm/mm/ioremap.c  |   18 +++-
 arch/arm/mm/mmu.c  |2 
 arch/arm/mm/nommu.c|   11 ++
 arch/arm64/Kconfig |1 
 arch/arm64/include/asm/acpi.h  |   11 --
 arch/arm64/include/asm/dmi.h   |8 +-
 arch/arm64/include/asm/io.h|2 
 arch/arm64/kernel/efi.c|9 +-
 arch/arm64/kernel/smp_spin_table.c |   19 ++--
 arch/arm64/mm/ioremap.c|   20 ++--
 arch/avr32/include/asm/io.h|1 
 arch/frv/include/asm/io.h  |   12 ---
 arch/ia64/Kconfig  |1 
 arch/ia64/include/asm/io.h |5 -
 arch/ia64/kernel/cyclone.c |2 
 arch/ia64/mm/ioremap.c |   16 +++
 arch/m32r/include/asm/io.h |1 
 arch/m68k/Kconfig  |1 
 arch/m68k/include/asm/io_mm.h  |   12 ---
 arch/m68k/include/asm/io_no.h  |   11 --
 arch/m68k/include/asm/raw_io.h |1 
 arch/m68k/mm/kmap.c|   17 +++-
 arch/m68k/mm/sun3kmap.c|6 +
 arch/metag/include/asm/io.h|6 -
 arch/microblaze/include/asm/io.h   |2 
 arch/mn10300/include/asm/io.h  |1 
 arch/nios2/include/asm/io.h|1 
 arch/powerpc/kernel/pci_of_scan.c  |2 
 arch/s390/include/asm/io.h |1 
 arch/sh/Kconfig|1 
 arch/sh/include/asm/io.h   |6 -
 arch/sh/mm/ioremap.c   |   15 +++
 arch/sparc/include/asm/io_32.h |1 
 arch/sparc/include/asm/io_64.h

drm properties, ABI and compositors

[Dave Airlie]

> I've discussed drm props and ABI requirements a bit with Dave on irc.
> In the past we've been pretty lax with properties since connector
> properties are mostly meant for end-users to set manually, so not
> really much point in standardizing and treating them like ABI. But now
> we have props for plane/CRTC and atomic and those are really meant to
> be used by compositors, so all the problems with ABI start to kick in.
> And we had them already, e.g. early i915 patches for rotation where cw
> while existing omap supports was ccw. I also just spotted msm patches
> which reinvent the mirror flags of the rotation prop with their own
> flip prop. And there's a lot of things in-progress already like
> zpos/alpha/blending props, color manager/per-plane gamma, ...
>
> To avoid future ABI disaster I think we should treat these props like
> any other drm ABI and require full-blown userspace, so here that would
> be a real implementation in something like weston, -modesetting, the
> new cros thing or maybe even hwc if that ever happens as an
> open-source project. And test tools like modetest don't cut it since
> upside down desktop is obvious, upside down test pattern meh. And
> modetest doesn't bother with all the TEST_ONLY and failure recory
> stuff like e.g. weston atomic needs to.
>
> Internally I think we should also try to standarize prop handling by
> pushing them into drm_*_state structs and adding decoding in core and
> good helpers. And hopefully soon we have markdown for kerneldoc so can
> transform that horrible docbook table into something sane. But that's
> just internals which we can always fix. ABI's forever.
>
> Anyway this is all kinda just clarification at least for i915. props
> for compositors are ABI like anything else, same rules still apply.

Yes totally, no adding props for closed compositors as well if we
can't use it with weston/mutter/open source stuff we can't test it.

(are there any closed source compositors?)

Dave.

[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg&fb buffers

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=83998

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Andy Furniss  ---
I did try older kernels, but after thinking one was OK which turned out to also
have the issue I decided bisecting was not really going to work.

I don't have the 270X anymore so marking as a dup of another report.

As noted in that report, it seems easier to provoke this with current kernels.

It's possible the mesa commit just changed some timing that exposed the issue
more.

Currently on Tonga I can provoke a similar issue (not oops - just ring stall)
and reverting the mesa commit in this bug doesn't help, but playing around with
cpufreq can change how easy it is to provoke.

*** This bug has been marked as a duplicate of bug 91009 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/a3450bf1/attachment.html>

[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91009

Andy Furniss  changed:

   What|Removed |Added

 CC||adf.lists at gmail.com

--- Comment #9 from Andy Furniss  ---
*** Bug 83998 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/7fa5fb0c/attachment.html>

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Theodore Ts'o]

On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> I've tried pulling in your patches from fixes-stuff, onto Linus's tree
> (without Linus's fix), and the good news is that I'm no longer
> crashing on boot.
> 
> The *bad* news is that (a) it breaks the external monitor attached to
> the docking station completely (this was working with Linus's patch),
> and (b) it's triggering a LOCKDEP failure.

Well, that's not fair.  Even with Linus's fix, there is still a
LOCKDEP failure.  And a few more i915 WARNINGS.  But at least the
external monitor works, so this is what I'm using.  Enclosed please
find a dmesg with the lockdep and i915 warnings and my .config.  The
kernel that I used can be found at:

https://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/log/?h=i915-test-4.2.0-rc4

- Ted
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/gzip
Size: 25784 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/5b475051/attachment-0002.bin>
-- next part --
A non-text attachment was scrubbed...
Name: config.gz
Type: application/gzip
Size: 31022 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/5b475051/attachment-0003.bin>

[Bug 60254] [r600g] kernel Oops when provoking GPU lock.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=60254

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andy Furniss  ---
Old - no h/w to test so closing.

Johannes if you can still produce this with current kernels etc please re-open.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/d0e5484d/attachment.html>

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Theodore Ts'o]

On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> but I couldn't test them yet since no dp mst here and I didn't find
> anything that would ship faster than 1-2 weeks yet. I'll try to get some
> other people here to test it meanwhile too.

I've tried pulling in your patches from fixes-stuff, onto Linus's tree
(without Linus's fix), and the good news is that I'm no longer
crashing on boot.

The *bad* news is that (a) it breaks the external monitor attached to
the docking station completely (this was working with Linus's patch),
and (b) it's triggering a LOCKDEP failure.

So even though Linus's patch wasn't supposed to work, I think I'm
going to back to it

- Ted


Jul 30 11:46:49 closure kernel: [4.221951] 
Jul 30 11:46:49 closure kernel: [4.221954] 
==
Jul 30 11:46:49 closure kernel: [4.221957] [ INFO: possible circular 
locking dependency detected ]
Jul 30 11:46:49 closure kernel: [4.221960] 4.2.0-rc4-13906-g5f1b75cd #16 
Not tainted
Jul 30 11:46:49 closure kernel: [4.221963] 
---
Jul 30 11:46:49 closure kernel: [4.221966] modprobe/503 is trying to 
acquire lock:
Jul 30 11:46:49 closure kernel: [4.221968]  (init_mutex){+.+.+.}, at: 
[] acpi_video_get_backlight_type+0x17/0x164
Jul 30 11:46:49 closure kernel: [4.221977] 
Jul 30 11:46:49 closure kernel: [4.221977] but task is already holding lock:
Jul 30 11:46:49 closure kernel: [4.221979]  
(&(&backlight_notifier)->rwsem){..}, at: [] 
__blocking_notifier_call_chain+0x37/0x69
Jul 30 11:46:49 closure kernel: [4.221987] 
Jul 30 11:46:49 closure kernel: [4.221987] which lock already depends on 
the new lock.
Jul 30 11:46:49 closure kernel: [4.221987] 
Jul 30 11:46:49 closure kernel: [4.221990] 
Jul 30 11:46:49 closure kernel: [4.221990] the existing dependency chain 
(in reverse order) is:
Jul 30 11:46:49 closure kernel: [4.221995] 
Jul 30 11:46:49 closure kernel: [4.221995] -> #1 
(&(&backlight_notifier)->rwsem){..}:
Jul 30 11:46:49 closure kernel: [4.222001][] 
lock_acquire+0x104/0x18b
Jul 30 11:46:49 closure kernel: [4.222007][] 
down_write+0x46/0x8a
Jul 30 11:46:49 closure kernel: [4.222012][] 
blocking_notifier_chain_register+0x36/0x57
Jul 30 11:46:49 closure kernel: [4.222017][] 
backlight_register_notifier+0x18/0x1a
Jul 30 11:46:49 closure kernel: [4.222022][] 
acpi_video_get_backlight_type+0xfa/0x164
Jul 30 11:46:49 closure kernel: [4.222028][] 
0xc03a1e45
Jul 30 11:46:49 closure audispd: No plugins found, exiting
Jul 30 11:46:49 closure kernel: [4.222032][] 
0xc03a28a8
Jul 30 11:46:49 closure kernel: [4.222036][] 
do_one_initcall+0x19a/0x1af
Jul 30 11:46:49 closure kernel: [4.222042][] 
do_init_module+0x60/0x1e3
Jul 30 11:46:49 closure kernel: [4.222047][] 
load_module+0x1c42/0x2059
Jul 30 11:46:49 closure kernel: [4.222052][] 
SyS_finit_module+0x85/0x92
Jul 30 11:46:49 closure kernel: [4.222056][] 
entry_SYSCALL_64_fastpath+0x16/0x73
Jul 30 11:46:49 closure kernel: [4.222060] 
Jul 30 11:46:49 closure kernel: [4.222060] -> #0 (init_mutex){+.+.+.}:
Jul 30 11:46:49 closure kernel: [4.222065][] 
__lock_acquire+0xc55/0xf54
Jul 30 11:46:49 closure kernel: [4.222070][] 
lock_acquire+0x104/0x18b
Jul 30 11:46:49 closure kernel: [4.222074][] 
mutex_lock_nested+0x70/0x391
Jul 30 11:46:49 closure kernel: [4.222078][] 
acpi_video_get_backlight_type+0x17/0x164
Jul 30 11:46:49 closure kernel: [4.222083][] 
acpi_video_backlight_notify+0x19/0x2f
Jul 30 11:46:49 closure kernel: [4.222088][] 
notifier_call_chain+0x4c/0x71
Jul 30 11:46:49 closure kernel: [4.222092][] 
__blocking_notifier_call_chain+0x50/0x69
Jul 30 11:46:49 closure kernel: [4.222098][] 
blocking_notifier_call_chain+0x14/0x16
Jul 30 11:46:49 closure kernel: [4.222103][] 
backlight_device_register+0x1df/0x1f1
Jul 30 11:46:49 closure kernel: [4.222108][] 
intel_backlight_register+0xf0/0x157 [i915]
Jul 30 11:46:49 closure kernel: [4.222146][] 
intel_modeset_gem_init+0x158/0x164 [i915]
Jul 30 11:46:49 closure kernel: [4.222176][] 
i915_driver_load+0xf1c/0x1139 [i915]
Jul 30 11:46:49 closure kernel: [4.05][] 
drm_dev_register+0x84/0xfd [drm]
Jul 30 11:46:49 closure kernel: [4.17][] 
drm_get_pci_dev+0x102/0x1bc [drm]
Jul 30 11:46:49 closure kernel: [4.28][] 
i915_pci_probe+0x4f/0x51 [i915]
Jul 30 11:46:49 closure kernel: [4.47][] 
pci_device_probe+0x74/0xd6
Jul 30 11:46:49 closure kernel: [4.53][] 
driver_probe_device+

[Bug 85207] agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85207

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Andy Furniss  ---
Should have been closed some time ago

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/ef8c4818/attachment-0001.html>

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=88493

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Andy Furniss  ---
I don't have the h/w to test this anymore.

Since drm/radeon: rework audio detect (v4)

Similar bug reports seem to be fixed now so closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/edd7fc3f/attachment.html>

[Bug 91507] Only 4K on 5K Retina iMac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91507

--- Comment #1 from Andreas Tunek  ---
Here is Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1184204

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/950ac901/attachment.html>

[Bug 91507] Only 4K on 5K Retina iMac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91507

Bug ID: 91507
   Summary: Only 4K on 5K Retina iMac
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: andreas.tunek at gmail.com

The Retina 5K iMac has a 5K screen but it is only possible to go up to 4K with
Linux. Tested with 4.2 rc4 on Fedora.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/eb0c57aa/attachment.html>

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Theodore Ts'o]

On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> >  drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 5b59d5ad7d1c..aac212297b49 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state 
> > *state, int conn_idx)
> > }
> >  
> > connector_state->best_encoder = new_encoder;
> > -   idx = drm_crtc_index(connector_state->crtc);
> > +   if (connector_state->crtc) {
> > +   idx = drm_crtc_index(connector_state->crtc);
> >  
> > -   crtc_state = state->crtc_states[idx];
> > -   crtc_state->mode_changed = true;
> > +   crtc_state = state->crtc_states[idx];
> > +   crtc_state->mode_changed = true;
> > +   }
> 
> This shouldn't happen since if it does we ended up stealing the encoder
> from the connector itself (we do check for connector_state->crtc earlier)
> and that would be a bug. I haven't figured out a precise theory but my
> guess is on the best_encoder selection, and indeed dp mst encoder
> selection seems to have gone belly up in 4.2 with the bisected commit.

Well, I just tested Linus's patch and it works.

BTW, is there any chance that I can suspend my laptop, and then move
it from my docking station at home (where I have a Dell 30" display)
to my docking station at work (where I have a Dell 24" display), and
actually have the new monitor be detected?  For at least the past
year, I have to reboot in order to be able to use the external
monitor?  This used to work, but it's been a very long-standing
regression.  I undrstand that Multi-stream DP is a evil horrible hack,
and supporting it is painful, but this used to work, and it hasn't in
a long time.  :-(

- Ted

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Bryan O'Donoghue]

Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version
of the browser and current tip-of-tree 86ea07ca846a I get the following
error message followed by a lock-up of X.

nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list
nouveau E[chrome[2737]] validate_init
nouveau E[chrome[2737]] validate: -22
nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list
nouveau E[chrome[2737]] validate_init
 nouveau E[chrome[2737]] validate: -22
nouveau E[   PFIFO][:01:00.0] PFIFO: read fault at
0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum
0x)/GPC0/(unknown enum 0x000f) on channel 0x007f80c000
[unknown]

This patch suggests a fix for this with the kernel simply tolerating an
application such as chrome requesting the same buffer more than once.

With the version of chrome given above, you can elicit this behaviour by
clicking on the bookmarks drop down. This will open another window on-top
of the current window. Minus the fix included here, this will lead to hard
lockup of all windows on the desktop.

Chrome Version 44.0.2403.125 (64-bit)
Linux 4.2.0-rc4+ 86ea07ca846a

People are suggesting running chrome with -disable-gpu however it is
possible to run Chrome in it's default mode, so long as we tolerate the
above behaviour.

http://tinyurl.com/orvbzf3

Signed-off-by: Bryan O'Donoghue 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index af1ee51..a9694faad 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -401,9 +401,7 @@ retry:
if (nvbo->reserved_by && nvbo->reserved_by == file_priv) {
NV_PRINTK(error, cli, "multiple instances of buffer %d 
on "
  "validation list\n", b->handle);
-   drm_gem_object_unreference_unlocked(gem);
-   ret = -EINVAL;
-   break;
+   continue;
}

ret = ttm_bo_reserve(&nvbo->bo, true, false, true, &op->ticket);
-- 
1.9.1

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91253

--- Comment #8 from Andreas Tunek  ---
The linked patch works as well. Should I change the status of this bug?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/fdb7b92e/attachment.html>

[Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Linus Torvalds]

On Thu, Jul 30, 2015 at 8:57 AM, Takashi Iwai  wrote:
> On Thu, 30 Jul 2015 17:32:28 +0200,
> Theodore Ts'o wrote:
>>
>> BTW, is there any chance that I can suspend my laptop, and then move
>> it from my docking station at home (where I have a Dell 30" display)
>> to my docking station at work (where I have a Dell 24" display), and
>> actually have the new monitor be detected?  For at least the past
>> year, I have to reboot in order to be able to use the external
>> monitor?  This used to work, but it's been a very long-standing
>> regression.  I undrstand that Multi-stream DP is a evil horrible hack,
>> and supporting it is painful, but this used to work, and it hasn't in
>> a long time.  :-(
>
> Relevant with this?
>https://bugs.freedesktop.org/show_bug.cgi?id=89589
>
> I wanted to check this by myself, too, as the same bug was reported to
> openSUSE bugzilla, but I had no hardware showing it.

Hmm. That commit e7d6f7d70829 looks like it should still revert fairly
cleanly (just move the call to intel_dp_mst_resume() to before the
intel_modeset_setup_hw_state() call and locking).

Ted, worth checking out, even if that presumably ends up
re-introducing some WARN_ON's..

Linus

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Ilia Mirkin]

On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
 wrote:
> On 30/07/15 15:52, Bryan O'Donoghue wrote:
>>
>> On 30/07/15 15:49, Peter Hurley wrote:
>>>
>>> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:

 Is this happening with libdrm 2.4.60? If so, that's a known
 (user-side) issue and should be fixed by using any version but that
 one.
>>>
>>>
>>> What's the freedesktop bugzilla # for reference?
>>>
>>> Regards,
>>> Peter Hurley
>>
>>
>> I believe it's this one
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=89842#c19
>>
>
> Not really a world of choice on ubuntu to fix it though...
>
> deckard at aineko:~/Development/projectara$ apt-show-versions libdrm2
> libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
> libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
>
> :(

That's unfortunate. I know next to nothing about debian/ubuntu or how
they do versions or how to even build packages for them. But they're
big distros, presumably they have support teams of some sort, perhaps
they can help you.

Assuming that switching away does resolve the issue for you, perhaps
you can also recommend that they avoid shipping that version, or
include this nouveau fix in it:

http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c788c61f546294

This whole libdrm thing is a bit of a cluster%@#$ unfortunately --
2.4.60 is broken for nouveau, building even the latest released
xf86-video-intel against 2.4.61+ causes it to not start ("fixed" in
xf86-video-intel git), and newer mesa requires libdrm 2.4.60+.

  -ilia

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Ilia Mirkin]

On Thu, Jul 30, 2015 at 10:46 AM, Peter Hurley  
wrote:
> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>> Is this happening with libdrm 2.4.60? If so, that's a known
>> (user-side) issue and should be fixed by using any version but that
>> one.
>
> What's the freedesktop bugzilla # for reference?

I believe there may have been several, and also a number of reports on
IRC as well since it took a few months to work out what was going on,
but here's one:

https://bugs.freedesktop.org/show_bug.cgi?id=89842

I've recently filed a gentoo bug to drop the ebuild for libdrm-2.4.60 here:

https://bugs.gentoo.org/show_bug.cgi?id=556270

although it's not used by default there.

  -ilia

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Peter Hurley]

On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.

What's the freedesktop bugzilla # for reference?

Regards,
Peter Hurley

> On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'Donoghue
>  wrote:
>> Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version
>> of the browser and current tip-of-tree 86ea07ca846a I get the following
>> error message followed by a lock-up of X.
>>
>> nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list
>> nouveau E[chrome[2737]] validate_init
>> nouveau E[chrome[2737]] validate: -22
>> nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list
>> nouveau E[chrome[2737]] validate_init
>>  nouveau E[chrome[2737]] validate: -22
>> nouveau E[   PFIFO][:01:00.0] PFIFO: read fault at
>> 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum
>> 0x)/GPC0/(unknown enum 0x000f) on channel 0x007f80c000
>> [unknown]
>>
>> This patch suggests a fix for this with the kernel simply tolerating an
>> application such as chrome requesting the same buffer more than once.
>>
>> With the version of chrome given above, you can elicit this behaviour by
>> clicking on the bookmarks drop down. This will open another window on-top
>> of the current window. Minus the fix included here, this will lead to hard
>> lockup of all windows on the desktop.
>>
>> Chrome Version 44.0.2403.125 (64-bit)
>> Linux 4.2.0-rc4+ 86ea07ca846a
>>
>> People are suggesting running chrome with -disable-gpu however it is
>> possible to run Chrome in it's default mode, so long as we tolerate the
>> above behaviour.
>>
>> http://tinyurl.com/orvbzf3
>>
>> Signed-off-by: Bryan O'Donoghue 
>> ---
>>  drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
>> b/drivers/gpu/drm/nouveau/nouveau_gem.c
>> index af1ee51..a9694faad 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
>> @@ -401,9 +401,7 @@ retry:
>> if (nvbo->reserved_by && nvbo->reserved_by == file_priv) {
>> NV_PRINTK(error, cli, "multiple instances of buffer 
>> %d on "
>>   "validation list\n", b->handle);
>> -   drm_gem_object_unreference_unlocked(gem);
>> -   ret = -EINVAL;
>> -   break;
>> +   continue;
>> }
>>
>> ret = ttm_bo_reserve(&nvbo->bo, true, false, true, 
>> &op->ticket);
>> --
>> 1.9.1

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Peter Hurley]

On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.

What's the freedesktop bugzilla # for reference?

Regards,
Peter Hurley

> On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'Donoghue
>  wrote:
>> Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version
>> of the browser and current tip-of-tree 86ea07ca846a I get the following
>> error message followed by a lock-up of X.
>>
>> nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list
>> nouveau E[chrome[2737]] validate_init
>> nouveau E[chrome[2737]] validate: -22
>> nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list
>> nouveau E[chrome[2737]] validate_init
>>  nouveau E[chrome[2737]] validate: -22
>> nouveau E[   PFIFO][:01:00.0] PFIFO: read fault at
>> 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum
>> 0x)/GPC0/(unknown enum 0x000f) on channel 0x007f80c000
>> [unknown]
>>
>> This patch suggests a fix for this with the kernel simply tolerating an
>> application such as chrome requesting the same buffer more than once.
>>
>> With the version of chrome given above, you can elicit this behaviour by
>> clicking on the bookmarks drop down. This will open another window on-top
>> of the current window. Minus the fix included here, this will lead to hard
>> lockup of all windows on the desktop.
>>
>> Chrome Version 44.0.2403.125 (64-bit)
>> Linux 4.2.0-rc4+ 86ea07ca846a
>>
>> People are suggesting running chrome with -disable-gpu however it is
>> possible to run Chrome in it's default mode, so long as we tolerate the
>> above behaviour.
>>
>> http://tinyurl.com/orvbzf3
>>
>> Signed-off-by: Bryan O'Donoghue 
>> ---
>>  drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
>> b/drivers/gpu/drm/nouveau/nouveau_gem.c
>> index af1ee51..a9694faad 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
>> @@ -401,9 +401,7 @@ retry:
>> if (nvbo->reserved_by && nvbo->reserved_by == file_priv) {
>> NV_PRINTK(error, cli, "multiple instances of buffer 
>> %d on "
>>   "validation list\n", b->handle);
>> -   drm_gem_object_unreference_unlocked(gem);
>> -   ret = -EINVAL;
>> -   break;
>> +   continue;
>> }
>>
>> ret = ttm_bo_reserve(&nvbo->bo, true, false, true, 
>> &op->ticket);
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Ilia Mirkin]

Is this happening with libdrm 2.4.60? If so, that's a known
(user-side) issue and should be fixed by using any version but that
one.

On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'Donoghue
 wrote:
> Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version
> of the browser and current tip-of-tree 86ea07ca846a I get the following
> error message followed by a lock-up of X.
>
> nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list
> nouveau E[chrome[2737]] validate_init
> nouveau E[chrome[2737]] validate: -22
> nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list
> nouveau E[chrome[2737]] validate_init
>  nouveau E[chrome[2737]] validate: -22
> nouveau E[   PFIFO][:01:00.0] PFIFO: read fault at
> 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum
> 0x)/GPC0/(unknown enum 0x000f) on channel 0x007f80c000
> [unknown]
>
> This patch suggests a fix for this with the kernel simply tolerating an
> application such as chrome requesting the same buffer more than once.
>
> With the version of chrome given above, you can elicit this behaviour by
> clicking on the bookmarks drop down. This will open another window on-top
> of the current window. Minus the fix included here, this will lead to hard
> lockup of all windows on the desktop.
>
> Chrome Version 44.0.2403.125 (64-bit)
> Linux 4.2.0-rc4+ 86ea07ca846a
>
> People are suggesting running chrome with -disable-gpu however it is
> possible to run Chrome in it's default mode, so long as we tolerate the
> above behaviour.
>
> http://tinyurl.com/orvbzf3
>
> Signed-off-by: Bryan O'Donoghue 
> ---
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index af1ee51..a9694faad 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -401,9 +401,7 @@ retry:
> if (nvbo->reserved_by && nvbo->reserved_by == file_priv) {
> NV_PRINTK(error, cli, "multiple instances of buffer 
> %d on "
>   "validation list\n", b->handle);
> -   drm_gem_object_unreference_unlocked(gem);
> -   ret = -EINVAL;
> -   break;
> +   continue;
> }
>
> ret = ttm_bo_reserve(&nvbo->bo, true, false, true, 
> &op->ticket);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] enable migration of driver pages

[Gioh Kim]

2015-07-29 오후 9:46에 Daniel Vetter 이(가) 쓴 글:
> On Wed, Jul 29, 2015 at 01:16:14PM +0100, Mel Gorman wrote:
>> On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote:
>>> On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote:
 On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote:
> My ARM-based platform occured severe fragmentation problem after long-term
> (several days) test. Sometimes even order-3 page allocation failed. It has
> memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic 
> processing
> and 20~30 memory is reserved for zram.
>

 The primary motivation of this series is to reduce fragmentation by 
 allowing
 more kernel pages to be moved. Conceptually that is a worthwhile goal but
 there should be at least one major in-kernel user and while balloon
 pages were a good starting point, I think we really need to see what the
 zram changes look like at the same time.
>>>
>>> I think gpu drivers really would be the perfect candidate for compacting
>>> kernel page allocations. And this also seems the primary motivation for
>>> this patch series, so I think that's really what we should use to judge
>>> these patches.
>>>
>>> Of course then there's the seemingly eternal chicken/egg problem of
>>> upstream gpu drivers for SoCs :(
>>
>> I recognised that the driver he had modified was not an in-tree user so
>> it did not really help the review or the design. I did not think it was
>> very fair to ask that an in-tree GPU driver be converted when it would not
>> help the embedded platform of interest. Converting zram is both a useful
>> illustration of the aops requirements and is expected to be beneficial on
>> the embedded platform. Now, if a GPU driver author was willing to convert
>> theirs as an example then that would be useful!
>
> Well my concern is more with merging infrastructure to upstream for
> drivers which aren't upstream and with no plan to make that happen anytime
> soon. Seems like just offload a bit to me ... but in the end core mm isn't
> my thing so not my decision.
> -Daniel
>

I get idea from the out-tree driver but this infrastructure will be useful
for zram and balloon. That is agreed by the maintainers of each driver.

I'm currently accepting feedbacks from
balloon and zram and trying to be applicable for them.
Of course I hope there will be more application. It'll be more useful
if it has more application.

drm/atomic: Remove WARN_ON from drm_atomic_state_default_clear.

[Maarten Lankhorst]

This may cause a failure when atomic_free is called asynchronously.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3efd91c0c6cb..d719ce0b10a0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -153,8 +153,6 @@ void drm_atomic_state_default_clear(struct drm_atomic_state 
*state)
if (!connector)
continue;

-   WARN_ON(!drm_modeset_is_locked(&config->connection_mutex));
-
connector->funcs->atomic_destroy_state(connector,
   
state->connector_states[i]);
state->connectors[i] = NULL;

drm/atomic: Reject events for inactive crtc's.

[Maarten Lankhorst]

This will cause drm_atomic_helper_page_flip and drm_mode_atomic_ioctl to
fail with -EINVAL if a event is requested on a inactive crtc.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d719ce0b10a0..679577e8e02d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -476,6 +476,12 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return -EINVAL;
}

+   if (!state->active && state->event) {
+   DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not active\n",
+crtc->base.id);
+   return -EINVAL;
+   }
+
/* The state->enable vs. state->mode_blob checks can be WARN_ON,
 * as this is a kernel-internal detail that userspace should never
 * be able to trigger. */

drm properties, ABI and compositors

[Daniel Vetter]

On Thu, Jul 30, 2015 at 4:43 AM, Dave Airlie  wrote:
> (are there any closed source compositors?)

Afaik everyone's hwc driver for surface flinger is a blob and only
code-dropped for nexus devices since google requires that. So can't
really use those one-offs to develop new stuff since it's a fork of
the internal one and because it's only published way at the end of a
product development cycle. Imo there's not really any reason for this
except the usual "valuable ip, must hide" reflex, and I'm hopeful that
with atomic we might actually see a somewhat sane hwc in google's repo
and maybe could use that ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=83319

--- Comment #8 from Dieter Nützel  ---
Ping!

Any news?

Related to Bug 91503 ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/f0196543/attachment.html>

[Bug 91503] [r600g] regression: SB-related NI/Turks crash on 'gsraytrace'

[bugzilla-dae...@freedesktop.org]

0x0}, uint128 =
0x}
xmm12  {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0},
v8_int16 = {0x0, 0x0, 
0x0, 0x0, 0x0, 0xff, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0xff, 0x0},
v2_int64 = {0x0, 
0xff}, uint128 = 0x00ff}
xmm13  {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {
0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0}, v4_int32 = {0x0, 
0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x}
xmm14  {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {
0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0}, v4_int32 = {0x0, 
0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x}
xmm15  {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {
0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0}, v4_int32 = {0x0, 
0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x}
mxcsr  0x1fa0   [ PE IM DM ZM OM UM PM ]

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/39defecf/attachment-0001.html>

[PATCH] drm: Fixup locking WARNINGs in drm_mode_config_reset

[Daniel Vetter]

On Wed, Jul 29, 2015 at 11:15:23PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> Thank you for the patch.
> 
> On Wednesday 29 July 2015 08:32:43 Daniel Vetter wrote:
> > With
> > 
> > commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
> > Author: Daniel Vetter 
> > Date:   Thu Jul 9 23:44:28 2015 +0200
> > 
> > drm: Check locking in drm_for_each_connector
> > 
> > we started checking the locking in drm_for_each_connector but somehow
> > I totally missed drm_mode_config_reset. There's no problem there since
> > this function should only be called in single-threaded contexts
> > (driver load or resume), so just wrap the loop with the right lock.
> > 
> > v2: Drink coffee and all that ...
> > 
> > Cc: Laurent Pinchart 
> > Reported-by: Laurent Pinchart 
> > Signed-off-by: Daniel Vetter 
> 
> This gets rid of the warning at driver load time with the rcar-du-drm driver.
> 
> Tested-by: Laurent Pinchart 

Thanks for testing, applied patch to drm-misc.
> 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index c91c18b2b1d4..10c1a0f6680c 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -5273,9 +5273,11 @@ void drm_mode_config_reset(struct drm_device *dev)
> > if (encoder->funcs->reset)
> > encoder->funcs->reset(encoder);
> > 
> > +   mutex_lock(&dev->mode_config.mutex);
> > drm_for_each_connector(connector, dev)
> > if (connector->funcs->reset)
> > connector->funcs->reset(connector);
> > +   mutex_unlock(&dev->mode_config.mutex);
> 
> Wouldn't it make sense to protect the whole function with the mode_config 
> mutex, given that it's documented as "protecting the KMS related lists and 
> structures" ?

Well that was correct ages ago I guess but since then we've split out tons
of other locks. It doesn't protect anything else really since those lists
are all static after driver load, and even here it's just to shut up the
WARNING (which is right for runtime in general and not harmful to grab the
lock really either).

I do have a plan to fix up kerneldoc, but I want to get the various
improvements collabora is working on in first.
-Daniel

> 
> >  }
> >  EXPORT_SYMBOL(drm_mode_config_reset);
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch