[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #12 from Tom Stellard  ---
Created attachment 105709
  --> https://bugs.freedesktop.org/attachment.cgi?id=105709=edit
Fix suggested by Vadim

Can you try this patch?

-- 
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/20140903/58317468/attachment.html>

TTM placement & caching issue/questions

[Jerome Glisse]

On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > 
> > > So in the meantime the attached patch should work, it just silently ignore
> > > the caching attribute request on non x86 instead of pretending that things
> > > are setup as expected and then latter the radeon ou nouveau hw unsetting
> > > the snoop bit.
> > > 
> > > It's not tested but i think it should work.
> > 
> > I'm still getting placements with !CACHED going from bo_memcpy in
> > ttm_io_prot() though ... I'm looking at filtering the placement
> > attributes instead.
> > 
> > Ben.
> 
> Ok so this one should do the trick.

Ok final version ... famous last word.


> 
> 
> > 
> > > > 
> > > > Cheers,
> > > > J?r?me
> > > > 
> > > > > 
> > > > > Cheers,
> > > > > Ben.
> > > > > 
> > > > > 
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-devel at lists.freedesktop.org
> > > > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 

> From def7a056d042220f91016d0a7c245ba8e96f90ba Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= 
> Date: Wed, 3 Sep 2014 22:04:34 -0400
> Subject: [PATCH] drm/ttm: force cached mapping on non x86 platform.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> People interested in providing uncached or write combined mapping
> on there architecture need to do the ground work inside there arch
> specific code to allow to break the linear kernel mapping so that
> page mapping attributes can be updated, in the meantime force cached
> mapping for non x86 architecture.
> 
> Signed-off-by: J?r?me Glisse 
> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c |  2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
>  drivers/gpu/drm/ttm/ttm_tt.c| 47 
> -
>  include/drm/ttm/ttm_bo_driver.h |  2 +-
>  4 files changed, 39 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 72afe82..4dd5060 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -304,7 +304,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
> *bo,
>   return r;
>   }
>  
> - r = ttm_tt_set_placement_caching(bo->ttm, tmp_mem.placement);
> + r = ttm_tt_set_placement_caching(bo->ttm, _mem.placement);
>   if (unlikely(r)) {
>   goto out_cleanup;
>   }
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 3da89d5..4dc21c3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -305,7 +305,7 @@ static int ttm_bo_handle_move_mem(struct 
> ttm_buffer_object *bo,
>   goto out_err;
>   }
>  
> - ret = ttm_tt_set_placement_caching(bo->ttm, mem->placement);
> + ret = ttm_tt_set_placement_caching(bo->ttm, >placement);
>   if (ret)
>   goto out_err;
>  
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index bf080ab..7cbdb48 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -89,14 +89,6 @@ static inline int ttm_tt_set_page_caching(struct page *p,
>  
>   return ret;
>  }
> -#else /* CONFIG_X86 */
> -static inline int ttm_tt_set_page_caching(struct page *p,
> -   enum ttm_caching_state c_old,
> -   enum ttm_caching_state c_new)
> -{
> - return 0;
> -}
> -#endif /* CONFIG_X86 */
>  
>  /*
>   * Change caching policy for the linear kernel map
> @@ -149,19 +141,52 @@ out_err:
>   return ret;
>  }
>  
> -int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t placement)
> +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t *placement)
>  {
>   enum ttm_caching_state state;
>  
> - if (placement & TTM_PL_FLAG_WC)
> + if (*placement & TTM_PL_FLAG_WC)
>   state = tt_wc;
> - else if (placement & TTM_PL_FLAG_UNCACHED)
> + else if (*placement & TTM_PL_FLAG_UNCACHED)
>   state = tt_uncached;
>   else
>   state = tt_cached;
>  
>   return ttm_tt_set_caching(ttm, state);
>  }
> +#else /* CONFIG_X86 */
> +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t *placement)
> +{
> + if (placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
> + ttm->caching_state = tt_cached;
> + } else {
> + if (placement & TTM_PL_FLAG_WC)
> + ttm->caching_state = tt_wc;
> + else if (placement & TTM_PL_FLAG_UNCACHED)
> + ttm->caching_state = tt_uncached;
> + else
> + ttm->caching_state = tt_cached;
> + }
> + /*
> + 

TTM placement & caching issue/questions

[Jerome Glisse]

On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > 
> > > So in the meantime the attached patch should work, it just silently ignore
> > > the caching attribute request on non x86 instead of pretending that things
> > > are setup as expected and then latter the radeon ou nouveau hw unsetting
> > > the snoop bit.
> > > 
> > > It's not tested but i think it should work.
> > 
> > I'm still getting placements with !CACHED going from bo_memcpy in
> > ttm_io_prot() though ... I'm looking at filtering the placement
> > attributes instead.
> > 
> > Ben.
> 
> Ok so this one should do the trick.

And this one should build :)

> 
> 
> > 
> > > > 
> > > > Cheers,
> > > > J?r?me
> > > > 
> > > > > 
> > > > > Cheers,
> > > > > Ben.
> > > > > 
> > > > > 
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-devel at lists.freedesktop.org
> > > > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 

> From def7a056d042220f91016d0a7c245ba8e96f90ba Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= 
> Date: Wed, 3 Sep 2014 22:04:34 -0400
> Subject: [PATCH] drm/ttm: force cached mapping on non x86 platform.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> People interested in providing uncached or write combined mapping
> on there architecture need to do the ground work inside there arch
> specific code to allow to break the linear kernel mapping so that
> page mapping attributes can be updated, in the meantime force cached
> mapping for non x86 architecture.
> 
> Signed-off-by: J?r?me Glisse 
> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c |  2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
>  drivers/gpu/drm/ttm/ttm_tt.c| 47 
> -
>  include/drm/ttm/ttm_bo_driver.h |  2 +-
>  4 files changed, 39 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 72afe82..4dd5060 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -304,7 +304,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
> *bo,
>   return r;
>   }
>  
> - r = ttm_tt_set_placement_caching(bo->ttm, tmp_mem.placement);
> + r = ttm_tt_set_placement_caching(bo->ttm, _mem.placement);
>   if (unlikely(r)) {
>   goto out_cleanup;
>   }
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 3da89d5..4dc21c3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -305,7 +305,7 @@ static int ttm_bo_handle_move_mem(struct 
> ttm_buffer_object *bo,
>   goto out_err;
>   }
>  
> - ret = ttm_tt_set_placement_caching(bo->ttm, mem->placement);
> + ret = ttm_tt_set_placement_caching(bo->ttm, >placement);
>   if (ret)
>   goto out_err;
>  
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index bf080ab..7cbdb48 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -89,14 +89,6 @@ static inline int ttm_tt_set_page_caching(struct page *p,
>  
>   return ret;
>  }
> -#else /* CONFIG_X86 */
> -static inline int ttm_tt_set_page_caching(struct page *p,
> -   enum ttm_caching_state c_old,
> -   enum ttm_caching_state c_new)
> -{
> - return 0;
> -}
> -#endif /* CONFIG_X86 */
>  
>  /*
>   * Change caching policy for the linear kernel map
> @@ -149,19 +141,52 @@ out_err:
>   return ret;
>  }
>  
> -int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t placement)
> +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t *placement)
>  {
>   enum ttm_caching_state state;
>  
> - if (placement & TTM_PL_FLAG_WC)
> + if (*placement & TTM_PL_FLAG_WC)
>   state = tt_wc;
> - else if (placement & TTM_PL_FLAG_UNCACHED)
> + else if (*placement & TTM_PL_FLAG_UNCACHED)
>   state = tt_uncached;
>   else
>   state = tt_cached;
>  
>   return ttm_tt_set_caching(ttm, state);
>  }
> +#else /* CONFIG_X86 */
> +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t *placement)
> +{
> + if (placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
> + ttm->caching_state = tt_cached;
> + } else {
> + if (placement & TTM_PL_FLAG_WC)
> + ttm->caching_state = tt_wc;
> + else if (placement & TTM_PL_FLAG_UNCACHED)
> + ttm->caching_state = tt_uncached;
> + else
> + ttm->caching_state = tt_cached;
> + }
> + /*
> +  * 

TTM placement & caching issue/questions

[Jerome Glisse]

On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> 
> > So in the meantime the attached patch should work, it just silently ignore
> > the caching attribute request on non x86 instead of pretending that things
> > are setup as expected and then latter the radeon ou nouveau hw unsetting
> > the snoop bit.
> > 
> > It's not tested but i think it should work.
> 
> I'm still getting placements with !CACHED going from bo_memcpy in
> ttm_io_prot() though ... I'm looking at filtering the placement
> attributes instead.
> 
> Ben.

Ok so this one should do the trick.


> 
> > > 
> > > Cheers,
> > > J?r?me
> > > 
> > > > 
> > > > Cheers,
> > > > Ben.
> > > > 
> > > > 
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel at lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
-- next part --
>From def7a056d042220f91016d0a7c245ba8e96f90ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= 
Date: Wed, 3 Sep 2014 22:04:34 -0400
Subject: [PATCH] drm/ttm: force cached mapping on non x86 platform.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

People interested in providing uncached or write combined mapping
on there architecture need to do the ground work inside there arch
specific code to allow to break the linear kernel mapping so that
page mapping attributes can be updated, in the meantime force cached
mapping for non x86 architecture.

Signed-off-by: J?r?me Glisse 
---
 drivers/gpu/drm/radeon/radeon_ttm.c |  2 +-
 drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
 drivers/gpu/drm/ttm/ttm_tt.c| 47 -
 include/drm/ttm/ttm_bo_driver.h |  2 +-
 4 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 72afe82..4dd5060 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -304,7 +304,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
*bo,
return r;
}

-   r = ttm_tt_set_placement_caching(bo->ttm, tmp_mem.placement);
+   r = ttm_tt_set_placement_caching(bo->ttm, _mem.placement);
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3da89d5..4dc21c3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -305,7 +305,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
goto out_err;
}

-   ret = ttm_tt_set_placement_caching(bo->ttm, mem->placement);
+   ret = ttm_tt_set_placement_caching(bo->ttm, >placement);
if (ret)
goto out_err;

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index bf080ab..7cbdb48 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -89,14 +89,6 @@ static inline int ttm_tt_set_page_caching(struct page *p,

return ret;
 }
-#else /* CONFIG_X86 */
-static inline int ttm_tt_set_page_caching(struct page *p,
- enum ttm_caching_state c_old,
- enum ttm_caching_state c_new)
-{
-   return 0;
-}
-#endif /* CONFIG_X86 */

 /*
  * Change caching policy for the linear kernel map
@@ -149,19 +141,52 @@ out_err:
return ret;
 }

-int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t placement)
+int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t *placement)
 {
enum ttm_caching_state state;

-   if (placement & TTM_PL_FLAG_WC)
+   if (*placement & TTM_PL_FLAG_WC)
state = tt_wc;
-   else if (placement & TTM_PL_FLAG_UNCACHED)
+   else if (*placement & TTM_PL_FLAG_UNCACHED)
state = tt_uncached;
else
state = tt_cached;

return ttm_tt_set_caching(ttm, state);
 }
+#else /* CONFIG_X86 */
+int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t *placement)
+{
+   if (placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
+   ttm->caching_state = tt_cached;
+   } else {
+   if (placement & TTM_PL_FLAG_WC)
+   ttm->caching_state = tt_wc;
+   else if (placement & TTM_PL_FLAG_UNCACHED)
+   ttm->caching_state = tt_uncached;
+   else
+   ttm->caching_state = tt_cached;
+   }
+   /*
+* Some architecture force cached so we need to reflect the
+* new ttm->caching_state into the mem->placement flags.
+*/
+   *placement &= ~TTM_PL_MASK_CACHING;
+   switch (bo->ttm->caching_state) {
+   case tt_wc:
+

TTM placement & caching issue/questions

[Jerome Glisse]

On Wed, Sep 03, 2014 at 09:55:53PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 10:12:27AM +1000, Benjamin Herrenschmidt wrote:
> > Hi folks !
> > 
> > I've been tracking down some problems with the recent DRI on powerpc and
> > stumbled upon something that doesn't look right, and not necessarily
> > only for us.
> > 
> > Now it's possible that I haven't fully understood the code here and I
> > also don't know to what extent some of that behaviour is necessary for
> > some platforms such as Intel GTT bits.
> > 
> > What I've observed with a simple/dumb (no DMA) driver like AST (but this
> > probably happens more generally) is that when evicting a BO from VRAM
> > into System memory, the TTM tries to preserve the existing caching
> > attributes of the VRAM object.
> > 
> > From what I can tell, we end up with going from VRAM to System memory
> > type, and we eventually call ttm_bo_select_caching() to select the
> > caching option for the target.
> > 
> > This will, from what I can tell, try to use the same caching mode as the
> > original object:
> > 
> > if ((cur_placement & caching) != 0)
> > result |= (cur_placement & caching);
> > 
> > And cur_placement comes from bo->mem.placement which as far as I can
> > tell is based on the placement array which the drivers set up.
> > 
> > Now they tend to uniformly setup the placement for System memory as
> > TTM_PL_MASK_CACHING which enables all caching modes.
> > 
> > So I end up with, for example, my System memory BOs having
> > TTM_PL_FLAG_CACHED not set (though they also don't have
> > TTM_PL_FLAG_UNCACHED) and TTM_PL_FLAG_WC.
> > 
> > We don't seem to use the man->default_caching (which will have
> > TTM_PL_FLAG_CACHED) unless there is no matching bit at all between the
> > proposed placement and the existing caching mode.
> > 
> > Now this is a problem for several reason that I can think of:
> > 
> >  - On a number of powerpc platforms, such as all our server 64-bit one
> > for example, it's actually illegal to map system memory non-cached. The
> > system is fully cache coherent for all possible DMA originators (that we
> > care about at least) and mapping memory non-cachable while it's mapped
> > cachable in the linear mapping can cause nasty cache paradox which, when
> > detected by HW, can checkstop the system.
> > 
> >  - A similar issue exists, afaik, on ARM >= v7, so anything mapped
> > non-cachable must be removed from the linear mapping explicitly since
> > otherwise it can be speculatively prefetched into the cache.
> > 
> >  - I don't know about x86, but even then, it looks quite sub-optimal to
> > map the memory backing of the BOs and access it using a WC rather than a
> > cachable mapping attribute.
> > 
> > Now, some folks on IRC mentioned that there might be reasons for the
> > current behaviour as to not change the caching attributes when going
> > in/out of the GTT on Intel, I don't know how that relates and how that
> > works, but maybe that should be enforced by having a different placement
> > mask specifically on those chipsets.
> > 
> > Dave, should we change the various PCI drivers for generally coherent
> > devices such that the System memory type doesn't allow placements
> > without CACHED attribute ? Or at least on coherent platforms ? How do
> > detect that ? Should we have a TTM helper to establish the default
> > memory placement attributes that "normal PCI" drivers call to set that
> > up so we can have all the necessary arch ifdefs in one single place, at
> > least for "classic PCI/PCIe" stuff (AGP might need additional tweaks) ?
> > 
> > Non-PCI and "special" drivers like Intel can use a different set of
> > placement attributes to represent the requirements of those specific
> > platforms (mostly thinking of embedded ARM here which under some
> > circumstances might actually require non-cached mappings).
> > Or am I missing another part of the puzzle ?
> > 
> > As it-is, things are broken for me even for dumb drivers, and I suspect
> > to a large extent with radeon and nouveau too, though in some case we
> > might get away with it most of the time ... until the machine locks up
> > for some unexplainable reason... This might cause problems on existing
> > distros such as RHEL7 with our radeon adapters even.
> > 
> > Any suggestion of what's the best approach to fix it ? I'm happy to
> > produce the patches but I'm not that familiar with the TTM so I would
> > like to make sure I'm the right track first :-)
> 
> While i agree about the issue of incoherent double map of same page, i
> think we have more issue. For instance lattely AMD have been pushing a
> lot of patches to move things to use uncached memory for radeon and as
> usual thoses patches comes with no comment to the motivations of those
> changes. I am ccing the usual suspect ;)
> 
> What i understand is that uncached mapping for some frequently use buffer
> give a significant performance boost (i am assuming this has to do with
> all the 

TTM placement & caching issue/questions

[Jerome Glisse]

On Thu, Sep 04, 2014 at 10:12:27AM +1000, Benjamin Herrenschmidt wrote:
> Hi folks !
> 
> I've been tracking down some problems with the recent DRI on powerpc and
> stumbled upon something that doesn't look right, and not necessarily
> only for us.
> 
> Now it's possible that I haven't fully understood the code here and I
> also don't know to what extent some of that behaviour is necessary for
> some platforms such as Intel GTT bits.
> 
> What I've observed with a simple/dumb (no DMA) driver like AST (but this
> probably happens more generally) is that when evicting a BO from VRAM
> into System memory, the TTM tries to preserve the existing caching
> attributes of the VRAM object.
> 
> From what I can tell, we end up with going from VRAM to System memory
> type, and we eventually call ttm_bo_select_caching() to select the
> caching option for the target.
> 
> This will, from what I can tell, try to use the same caching mode as the
> original object:
> 
>   if ((cur_placement & caching) != 0)
>   result |= (cur_placement & caching);
> 
> And cur_placement comes from bo->mem.placement which as far as I can
> tell is based on the placement array which the drivers set up.
> 
> Now they tend to uniformly setup the placement for System memory as
> TTM_PL_MASK_CACHING which enables all caching modes.
> 
> So I end up with, for example, my System memory BOs having
> TTM_PL_FLAG_CACHED not set (though they also don't have
> TTM_PL_FLAG_UNCACHED) and TTM_PL_FLAG_WC.
> 
> We don't seem to use the man->default_caching (which will have
> TTM_PL_FLAG_CACHED) unless there is no matching bit at all between the
> proposed placement and the existing caching mode.
> 
> Now this is a problem for several reason that I can think of:
> 
>  - On a number of powerpc platforms, such as all our server 64-bit one
> for example, it's actually illegal to map system memory non-cached. The
> system is fully cache coherent for all possible DMA originators (that we
> care about at least) and mapping memory non-cachable while it's mapped
> cachable in the linear mapping can cause nasty cache paradox which, when
> detected by HW, can checkstop the system.
> 
>  - A similar issue exists, afaik, on ARM >= v7, so anything mapped
> non-cachable must be removed from the linear mapping explicitly since
> otherwise it can be speculatively prefetched into the cache.
> 
>  - I don't know about x86, but even then, it looks quite sub-optimal to
> map the memory backing of the BOs and access it using a WC rather than a
> cachable mapping attribute.
> 
> Now, some folks on IRC mentioned that there might be reasons for the
> current behaviour as to not change the caching attributes when going
> in/out of the GTT on Intel, I don't know how that relates and how that
> works, but maybe that should be enforced by having a different placement
> mask specifically on those chipsets.
> 
> Dave, should we change the various PCI drivers for generally coherent
> devices such that the System memory type doesn't allow placements
> without CACHED attribute ? Or at least on coherent platforms ? How do
> detect that ? Should we have a TTM helper to establish the default
> memory placement attributes that "normal PCI" drivers call to set that
> up so we can have all the necessary arch ifdefs in one single place, at
> least for "classic PCI/PCIe" stuff (AGP might need additional tweaks) ?
> 
> Non-PCI and "special" drivers like Intel can use a different set of
> placement attributes to represent the requirements of those specific
> platforms (mostly thinking of embedded ARM here which under some
> circumstances might actually require non-cached mappings).
> Or am I missing another part of the puzzle ?
> 
> As it-is, things are broken for me even for dumb drivers, and I suspect
> to a large extent with radeon and nouveau too, though in some case we
> might get away with it most of the time ... until the machine locks up
> for some unexplainable reason... This might cause problems on existing
> distros such as RHEL7 with our radeon adapters even.
> 
> Any suggestion of what's the best approach to fix it ? I'm happy to
> produce the patches but I'm not that familiar with the TTM so I would
> like to make sure I'm the right track first :-)

While i agree about the issue of incoherent double map of same page, i
think we have more issue. For instance lattely AMD have been pushing a
lot of patches to move things to use uncached memory for radeon and as
usual thoses patches comes with no comment to the motivations of those
changes. I am ccing the usual suspect ;)

What i understand is that uncached mapping for some frequently use buffer
give a significant performance boost (i am assuming this has to do with
all the snoop pci transaction overhead).

>From my understanding this is something that is allow on other OS and
any driver wishing to compete from performance point of view will want
that.


So i think we need to get a platform flags and or 

[Bug 83460] New: [radeon regression] Backlight turned off since kernel upgrade

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

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

  Priority: medium
Bug ID: 83460
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [radeon regression] Backlight turned off since kernel
upgrade
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: spmf2004-freedesktop at yahoo.fr
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Since the upgrade to Ubuntu kernel 3.13.0-35 (from 3.13.0-34), the screen is
very dark to the point it's unusable.
Backlight seems completely turned off. Using the brightness keys doesn't help.
It was working fine with 3.13.0-34.
I found that the offending patch is "drm/radeon: set default bl level to
something reasonable".
I reverted this patch and recompiled 3.13.0-35, and it solved the problem.
I also checked that this problem also affects mainline kernel 3.17rc3.
More technical details can be found on Ubuntu's bugtracker :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1364148

-- 
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/20140903/2d58510f/attachment.html>

[PATCH 4/9] drm/omap: make modesetting synchronous

[Daniel Vetter]

On Wed, Sep 3, 2014 at 6:00 PM, Rob Clark  wrote:
> so, I am not quite sure that would work..  (and maybe this is an extra
> thing to think about for atomic).
>
> The problem is that hw has no hw cursor.  So cursor is implemented
> using plane.  But thanks to retarded userspace that rapidly
> enables/disables cursor in some cases, we really need plane updates to
> be async.  The way it currently works is userspace thread updates
> plane state as rapidly as it wants.  When worker eventually gets to
> run, it takes the most current state, possibly skipping 1000's of
> enable/disable that happened in the mean time.
>
> But for that to work, at least the way the driver is structured
> currently, the worker needs to synchronize against userspace somehow.

We could cancel the async worker before the update. But that still
leaves the problem that in general this needs full driver support to
work, and we can't really assume that. I guess we need to make a
special hack for the cursor emulation code to make sure this keeps
working: Cursor updates would only update the sw state and then rearm
a fully async cursor update work item, except when the cursor size
changed since the driver might reject that. I need to think more about
this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 81239] Evolution window content not shown fully (only desktop background)

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

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

--- Comment #9 from Paul Menzel  ---
I think I hit the same problem again today with Evolution 3.12.5, GTK+
3.12.2-3+b1 and xserver-xorg-video-radeon 1:7.4.0-2.

$ sudo perf top
[?]
  7,22%  libglib-2.0.so.0.4000.0[.] g_main_context_prepare
  5,71%  libglib-2.0.so.0.4000.0[.] 0x00090a0c
  4,84%  libglib-2.0.so.0.4000.0[.] g_main_context_check
[?]

-- 
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/20140903/e6dc7f42/attachment.html>

[PATCH] drm: sti: do not iterate over the info frame array

[Benjamin Gaignard]

avi infoframe is a 13 bytes array, do not read after this limite.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 284e541..90ee20a 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -298,7 +298,6 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi *hdmi)
hdmi_write(hdmi, val, HDMI_SW_DI_N_PKT_WORD2(HDMI_IFRAME_SLOT_AVI));

val = frame[0xC];
-   val |= frame[0xD] << 8;
hdmi_write(hdmi, val, HDMI_SW_DI_N_PKT_WORD3(HDMI_IFRAME_SLOT_AVI));

/* Enable transmission slot for AVI infoframe
-- 
1.9.1

[Bug 80878] Metro: Last Light freezes when trying to kill stealthily (RV770)

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

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

--- Comment #9 from Benjamin Bellec  ---
I can't reproduce the bug with your save.

-- 
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/20140903/4d62d96b/attachment.html>

[PATCH 4/9] drm/omap: make modesetting synchronous

[Daniel Vetter]

On Wed, Sep 03, 2014 at 11:05:08AM -0400, Rob Clark wrote:
> On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter  wrote:
> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
> >> Currently modesetting is not done synchronously, but it queues work that
> >> is done later. In theory this is fine, but the driver doesn't handle it
> >> at properly. This means that if an application first does a full
> >> modeset, then immediately afterwards starts page flipping, the page
> >> flipping will not work properly as there's modeset work still in the
> >> queue.
> >>
> >> The result with my test application was that a backbuffer was shown on
> >> the screen.
> >>
> >> Fixing this properly would be rather big undertaking. Thus this patch
> >> fixes the issue by making the modesetting synchronous, by waiting for
> >> the queued work to be done at the end of omap_crtc->commit().
> >>
> >> The ugly part here is that the background work takes crtc->mutex, and
> >> the modesetting also holds that lock, which means that the background
> >> work never gets done. To get around this, we unclock, wait, and lock
> >> again.
> >>
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> >> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> index 193979f97bdb..3261fbf94957 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc *crtc)
> >>  static void omap_crtc_commit(struct drm_crtc *crtc)
> >>  {
> >>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> >> + struct drm_device *dev = crtc->dev;
> >>   DBG("%s", omap_crtc->name);
> >>   omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
> >> +
> >> + drm_modeset_unlock_all(dev);
> >
> > This will run afoul of the upcoming locking rework in the atomic work. And
> > I'm fairly sure that the crtc helpers will fall over badly if someone
> > submits a concurrent setCrtc while you've dropped the locks here.
> 
> what about just dropping and re-acquiring crtc->mutex, since that is
> all the worker actually needs..
> 
> it would be a bigger task to get rid of the mutex on the worker, since
> we'd have to double buffer state.  It seemed like rather than
> re-invent atomic, it would be better just to wait for atomic to land
> and then restructure the driver

Well atomic kinda has the same idea to not take locks in the worker and
instead relying on ordering.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/3] drm/qxl: Fix crash in eviction from, qxl_release_fence_buffer_objects

[Maarten Lankhorst]

This crash was already here before the conversion, but qxl never leaked
hard enough to hit this.

Signed-off-by: Maarten Lankhorst 
---
The crash is probably only going to happen in extreme memory stress
when the system's already fucked, but hey still a bug. :-)

 drivers/gpu/drm/qxl/qxl_release.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 29ab4ec44c40..a6e19c83143e 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -440,7 +440,7 @@ void qxl_release_fence_buffer_objects(struct qxl_release 
*release)

/* if only one object on the release its the release itself
   since these objects are pinned no need to reserve */
-   if (list_is_singular(>bos))
+   if (list_is_singular(>bos) || list_empty(>bos))
return;

bo = list_first_entry(>bos, struct ttm_validate_buffer, 
head)->bo;
-- 
2.0.4

[PATCH 2/3] drm/qxl: fix gaping memory hole

[Maarten Lankhorst]

This is how you implement a sieve in a driver. ;-)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/qxl/qxl_release.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 828d47e90dce..29ab4ec44c40 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -162,12 +162,14 @@ static void
 qxl_release_free_list(struct qxl_release *release)
 {
while (!list_empty(>bos)) {
-   struct ttm_validate_buffer *entry;
+   struct qxl_bo_list *entry;
+   struct qxl_bo *bo;

entry = container_of(release->bos.next,
-struct ttm_validate_buffer, head);
-
-   list_del(>head);
+struct qxl_bo_list, tv.head);
+   bo = to_qxl_bo(entry->tv.bo);
+   qxl_bo_unref();
+   list_del(>tv.head);
kfree(entry);
}
 }
-- 
2.0.4

[PATCH 1/3] drm/qxl: Remove release_lock stupidity

[Maarten Lankhorst]

The locking of release_lock was stupid; it should have been be called with
fence_lock_irq if it was legitimately used. Unfortunately it never protected
anything except the fence implementation correctly.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/qxl/qxl_debugfs.c | 2 --
 drivers/gpu/drm/qxl/qxl_release.c | 9 +++--
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c 
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index a4a63fd84803..6911b8c44492 100644
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -57,7 +57,6 @@ qxl_debugfs_buffers_info(struct seq_file *m, void *data)
struct qxl_device *qdev = node->minor->dev->dev_private;
struct qxl_bo *bo;

-   spin_lock(>release_lock);
list_for_each_entry(bo, >gem.objects, list) {
struct reservation_object_list *fobj;
int rel;
@@ -71,7 +70,6 @@ qxl_debugfs_buffers_info(struct seq_file *m, void *data)
   (unsigned long)bo->gem_base.size,
   bo->pin_count, rel);
}
-   spin_unlock(>release_lock);
return 0;
 }

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 15158c5a5b3a..828d47e90dce 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -71,7 +71,7 @@ static long qxl_fence_wait(struct fence *fence, bool intr, 
signed long timeout)
 retry:
sc++;

-   if (fence_is_signaled_locked(fence))
+   if (fence_is_signaled(fence))
goto signaled;

qxl_io_notify_oom(qdev);
@@ -80,11 +80,11 @@ retry:
if (!qxl_queue_garbage_collect(qdev, true))
break;

-   if (fence_is_signaled_locked(fence))
+   if (fence_is_signaled(fence))
goto signaled;
}

-   if (fence_is_signaled_locked(fence))
+   if (fence_is_signaled(fence))
goto signaled;

if (have_drawable_releases || sc < 4) {
@@ -457,8 +457,6 @@ void qxl_release_fence_buffer_objects(struct qxl_release 
*release)
glob = bo->glob;

spin_lock(>lru_lock);
-   /* acquire release_lock to protect bo->resv->fence and its contents */
-   spin_lock(>release_lock);

list_for_each_entry(entry, >bos, head) {
bo = entry->bo;
@@ -468,7 +466,6 @@ void qxl_release_fence_buffer_objects(struct qxl_release 
*release)
ttm_bo_add_to_lru(bo);
__ttm_bo_unreserve(bo);
}
-   spin_unlock(>release_lock);
spin_unlock(>lru_lock);
ww_acquire_fini(>ticket);
 }
-- 
2.0.4

[PATCH -v3 4/4] drm/i915: split intel_primary_plane_setplane() into check() and commit()

[Gustavo Padovan]

From: Gustavo Padovan 

As a preparation for atomic updates we need to split the code to check
everything we are going to commit first. This patch starts the work to
split intel_primary_plane_setplane() into check() and commit() parts.

More work is expected on this to get a better split of the two steps.
Ideally the commit() step should never fail.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 130 +++
 1 file changed, 72 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c3f1967..1e3985b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11663,63 +11663,37 @@ disable_unpin:
 }

 static int
-intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
+intel_check_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+   struct drm_crtc *crtc = state->crtc;
+   struct drm_framebuffer *fb = state->fb;
+   struct drm_rect *dest = >dst;
+   struct drm_rect *src = >src;
+   const struct drm_rect *clip = >clip;
+
+   return drm_plane_helper_check_update(plane, crtc, fb,
+   src, dest, clip,
+   DRM_PLANE_HELPER_NO_SCALING,
+   DRM_PLANE_HELPER_NO_SCALING,
+   false, true, >visible);
+}
+
+static int
+intel_commit_primary_plane(struct drm_plane *plane,
+  struct intel_plane_state *state)
 {
+   struct drm_crtc *crtc = state->crtc;
+   struct drm_framebuffer *fb = state->fb;
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
-   struct drm_rect dest = {
-   /* integer pixels */
-   .x1 = crtc_x,
-   .y1 = crtc_y,
-   .x2 = crtc_x + crtc_w,
-   .y2 = crtc_y + crtc_h,
-   };
-   struct drm_rect src = {
-   /* 16.16 fixed point */
-   .x1 = src_x,
-   .y1 = src_y,
-   .x2 = src_x + src_w,
-   .y2 = src_y + src_h,
-   };
-   const struct drm_rect clip = {
-   /* integer pixels */
-   .x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
-   .y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
-   };
-   const struct {
-   int crtc_x, crtc_y;
-   unsigned int crtc_w, crtc_h;
-   uint32_t src_x, src_y, src_w, src_h;
-   } orig = {
-   .crtc_x = crtc_x,
-   .crtc_y = crtc_y,
-   .crtc_w = crtc_w,
-   .crtc_h = crtc_h,
-   .src_x = src_x,
-   .src_y = src_y,
-   .src_w = src_w,
-   .src_h = src_h,
-   };
struct intel_plane *intel_plane = to_intel_plane(plane);
-   bool visible;
+   struct drm_rect *src = >src;
int ret;

-   ret = drm_plane_helper_check_update(plane, crtc, fb,
-   , , ,
-   DRM_PLANE_HELPER_NO_SCALING,
-   DRM_PLANE_HELPER_NO_SCALING,
-   false, true, );
-
-   if (ret)
-   return ret;
-
/*
 * If the CRTC isn't enabled, we're just pinning the framebuffer,
 * updating the fb pointer, and returning without touching the
@@ -11754,7 +11728,7 @@ intel_primary_plane_setplane(struct drm_plane *plane, 
struct drm_crtc *crtc,
 * happens if userspace explicitly disables the plane by passing fb=0
 * because plane->fb still gets set and pinned.
 */
-   if (!visible) {
+   if (!state->visible) {
mutex_lock(>struct_mutex);

/*
@@ -11801,7 +11775,7 @@ intel_primary_plane_setplane(struct drm_plane *plane, 
struct drm_crtc *crtc,
intel_disable_fbc(dev);
}
}
-   ret = intel_pipe_set_base(crtc, src.x1, src.y1, fb);
+   ret = intel_pipe_set_base(crtc, src->x1, src->y1, fb);
if (ret)
return ret;

@@ -11809,19 +11783,59 @@ intel_primary_plane_setplane(struct drm_plane 

[PATCH -v3 3/4] drm/i915: split intel_cursor_plane_update() into check() and commit()

[Gustavo Padovan]

From: Gustavo Padovan 

Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.

The commit part can still fail, but that should be solved in another
upcoming patch.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 104 ++-
 1 file changed, 67 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 22d3902..c3f1967 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11896,51 +11896,42 @@ intel_cursor_plane_disable(struct drm_plane *plane)
 }

 static int
-intel_cursor_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+intel_check_cursor_plane(struct drm_plane *plane,
+struct intel_plane_state *state)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
-   struct drm_i915_gem_object *obj = intel_fb->obj;
-   struct drm_rect dest = {
-   /* integer pixels */
-   .x1 = crtc_x,
-   .y1 = crtc_y,
-   .x2 = crtc_x + crtc_w,
-   .y2 = crtc_y + crtc_h,
-   };
-   struct drm_rect src = {
-   /* 16.16 fixed point */
-   .x1 = src_x,
-   .y1 = src_y,
-   .x2 = src_x + src_w,
-   .y2 = src_y + src_h,
-   };
-   const struct drm_rect clip = {
-   /* integer pixels */
-   .x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
-   .y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
-   };
-   bool visible;
-   int ret;
+   struct drm_crtc *crtc = state->crtc;
+   struct drm_framebuffer *fb = state->fb;
+   struct drm_rect *dest = >dst;
+   struct drm_rect *src = >src;
+   const struct drm_rect *clip = >clip;

-   ret = drm_plane_helper_check_update(plane, crtc, fb,
-   , , ,
+   return drm_plane_helper_check_update(plane, crtc, fb,
+   src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
-   true, true, );
-   if (ret)
-   return ret;
+   true, true, >visible);
+}

-   crtc->cursor_x = crtc_x;
-   crtc->cursor_y = crtc_y;
+static int
+intel_commit_cursor_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+   struct drm_crtc *crtc = state->crtc;
+   struct drm_framebuffer *fb = state->fb;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+   struct drm_i915_gem_object *obj = intel_fb->obj;
+   struct drm_rect *dest = >dst;
+   int crtc_w, crtc_h;
+
+   crtc->cursor_x = state->dst.x1;
+   crtc->cursor_y = state->dst.y1;
if (fb != crtc->cursor->fb) {
+   crtc_w = drm_rect_width(dest);
+   crtc_h = drm_rect_height(dest);
return intel_crtc_cursor_set_obj(crtc, obj, crtc_w, crtc_h);
} else {
-   intel_crtc_update_cursor(crtc, visible);
+   intel_crtc_update_cursor(crtc, state->visible);

intel_frontbuffer_flip(crtc->dev,
   
INTEL_FRONTBUFFER_CURSOR(intel_crtc->pipe));
@@ -11948,6 +11939,45 @@ intel_cursor_plane_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
return 0;
}
 }
+
+static int
+intel_cursor_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_plane_state state;
+   int ret;
+
+   state.crtc = crtc;
+   state.fb = fb;
+
+   /* sample coordinates in 16.16 fixed point */
+   state.src.x1 = src_x;
+   state.src.x2 = src_x + src_w;
+   state.src.y1 = src_y;
+   state.src.y2 = src_y + src_h;
+
+   /* integer pixels */
+   state.dst.x1 = crtc_x;
+   state.dst.x2 = crtc_x + crtc_w;
+   state.dst.y1 = 

[PATCH -v3 2/4] drm/i915: split intel_update_plane into check() and commit()

[Gustavo Padovan]

From: Gustavo Padovan 

Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.

This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning procedure.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_sprite.c | 253 +---
 1 file changed, 150 insertions(+), 103 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 07a74ef..7b0d1a9 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -845,57 +845,24 @@ static bool colorkey_enabled(struct intel_plane 
*intel_plane)
 }

 static int
-intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
-  struct drm_framebuffer *fb, int crtc_x, int crtc_y,
-  unsigned int crtc_w, unsigned int crtc_h,
-  uint32_t src_x, uint32_t src_y,
-  uint32_t src_w, uint32_t src_h)
+intel_check_sprite_plane(struct drm_plane *plane,
+struct intel_plane_state *state)
 {
-   struct drm_device *dev = plane->dev;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc *intel_crtc = to_intel_crtc(state->crtc);
struct intel_plane *intel_plane = to_intel_plane(plane);
-   enum pipe pipe = intel_crtc->pipe;
+   struct drm_framebuffer *fb = state->fb;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;
-   struct drm_i915_gem_object *old_obj = intel_plane->obj;
-   int ret;
-   bool primary_enabled;
-   bool visible;
+   int crtc_x, crtc_y;
+   unsigned int crtc_w, crtc_h;
+   uint32_t src_x, src_y, src_w, src_h;
+   struct drm_rect *src = >src;
+   struct drm_rect *dst = >dst;
+   struct drm_rect *orig_src = >orig_src;
+   const struct drm_rect *clip = >clip;
int hscale, vscale;
int max_scale, min_scale;
int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
-   struct drm_rect src = {
-   /* sample coordinates in 16.16 fixed point */
-   .x1 = src_x,
-   .x2 = src_x + src_w,
-   .y1 = src_y,
-   .y2 = src_y + src_h,
-   };
-   struct drm_rect dst = {
-   /* integer pixels */
-   .x1 = crtc_x,
-   .x2 = crtc_x + crtc_w,
-   .y1 = crtc_y,
-   .y2 = crtc_y + crtc_h,
-   };
-   const struct drm_rect clip = {
-   .x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
-   .y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
-   };
-   const struct {
-   int crtc_x, crtc_y;
-   unsigned int crtc_w, crtc_h;
-   uint32_t src_x, src_y, src_w, src_h;
-   } orig = {
-   .crtc_x = crtc_x,
-   .crtc_y = crtc_y,
-   .crtc_w = crtc_w,
-   .crtc_h = crtc_h,
-   .src_x = src_x,
-   .src_y = src_y,
-   .src_w = src_w,
-   .src_h = src_h,
-   };

/* Don't modify another pipe's plane */
if (intel_plane->pipe != intel_crtc->pipe) {
@@ -927,55 +894,55 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
max_scale = intel_plane->max_downscale << 16;
min_scale = intel_plane->can_scale ? 1 : (1 << 16);

-   drm_rect_rotate(, fb->width << 16, fb->height << 16,
+   drm_rect_rotate(src, fb->width << 16, fb->height << 16,
intel_plane->rotation);

-   hscale = drm_rect_calc_hscale_relaxed(, , min_scale, max_scale);
+   hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
BUG_ON(hscale < 0);

-   vscale = drm_rect_calc_vscale_relaxed(, , min_scale, max_scale);
+   vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
BUG_ON(vscale < 0);

-   visible = drm_rect_clip_scaled(, , , hscale, vscale);
+   state->visible =  drm_rect_clip_scaled(src, dst, clip, hscale, vscale);

-   crtc_x = dst.x1;
-   crtc_y = dst.y1;
-   crtc_w = drm_rect_width();
-   crtc_h = drm_rect_height();
+   crtc_x = dst->x1;
+   crtc_y = dst->y1;
+   crtc_w = drm_rect_width(dst);
+   crtc_h = drm_rect_height(dst);

-   if (visible) {
+   if (state->visible) {
/* check again in case clipping clamped the results */
-   hscale = drm_rect_calc_hscale(, , min_scale, max_scale);
+   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
if (hscale < 0) {
DRM_DEBUG_KMS("Horizontal scaling factor out of 
limits\n");
-   

[PATCH -v3 1/4] drm/i915: create struct intel_plane_state

[Gustavo Padovan]

From: Gustavo Padovan 

This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_drv.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d727d20..be668ea 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 

 /**
  * _wait_for - magic (register) wait macro
@@ -237,6 +238,17 @@ typedef struct dpll {
int p;
 } intel_clock_t;

+struct intel_plane_state {
+   struct drm_crtc *crtc;
+   struct drm_framebuffer *fb;
+   struct drm_rect src;
+   struct drm_rect dst;
+   struct drm_rect clip;
+   struct drm_rect orig_src;
+   struct drm_rect orig_dst;
+   bool visible;
+};
+
 struct intel_plane_config {
bool tiled;
int size;
-- 
1.9.3

[PATCH -v3 0/4] split plane's updates functions into check() and commit()

[Gustavo Padovan]

From: Gustavo Padovan 

This is the beginning of the work to prepare i915 for the upcoming
atomic modesetting API. Here we split the plane update fucntions in
the check and commit states.

v2: use struct intel_plane_state to keep states between check and
commit stages.

v3: take Ville's comments
- rename pstate to state
- get rid of non-drm_rect coordinates in intel_plane_state
- keep 'clip' const

Gustavo Padovan (4):
  drm/i915: create struct intel_plane_state
  drm/i915: split intel_update_plane into check() and commit()
  drm/i915: split intel_cursor_plane_update() into check() and commit()
  drm/i915: split intel_primary_plane_setplane() into check() and
commit()

 drivers/gpu/drm/i915/intel_display.c | 234 +++-
 drivers/gpu/drm/i915/intel_drv.h |  12 ++
 drivers/gpu/drm/i915/intel_sprite.c  | 253 +--
 3 files changed, 301 insertions(+), 198 deletions(-)

-- 
1.9.3

[Bug 83432] r600_query.c:269:r600_emit_query_end: Assertion `ctx->num_pipelinestat_queries > 0' failed [Gallium HUD]

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

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

--- Comment #4 from Marek Ol??k  ---
Yes, it does, but you have to really lucky and have a lot of queries active to
be able to hit the assertion.

-- 
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/20140903/b237836b/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #80 from Aaron B  ---
(In reply to comment #79)
> Aaron, most likely the bisection didn't work because you marked commits as
> good which would have shown the problem after more testing. I'm afraid
> you'll have to test longer before declaring a commit as good.

Hmm, okay, I'll try again. I'll test for about 8 hours this time. I don't have
the best grasp of the Mesa works, but I didn't think I screwed up as it seemed
to be something related to multisampler blitting which sounds darn close to
what is screwed up.

Starting over.

-- 
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/20140903/c0c1a94b/attachment.html>

[PATCH 8/9] drm/omap: fix preclose to wait for scheduled work

[Daniel Vetter]

On Wed, Sep 03, 2014 at 02:55:09PM +0300, Tomi Valkeinen wrote:
> We already wait for all scheduled work to be done on the driver's unload
> function. However, I think we need to wait on preclose() also, so that
> when an application closes the drm file descriptor, we are sure that
> there's no left around.

The justification (likely, didn't check omapdrm code) for this is that we
need to clear out all outstanding drm_events. Currently i915 and some
other drivers (but not all) have that open-coded. We should probably track
drm_events on a per-fd list and move this logic into the core instead of
adding more driver-specific hacks.
-Daniel
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 26fda74c1e48..f59fa6600cf8 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -594,7 +594,20 @@ static void dev_lastclose(struct drm_device *dev)
>  
>  static void dev_preclose(struct drm_device *dev, struct drm_file *file)
>  {
> + struct omap_drm_private *priv = dev->dev_private;
> + int i;
> +
>   DBG("preclose: dev=%p", dev);
> +
> + /*
> +  * Flush crtcs to finish any pending work.
> +  * Note: this may not be correct if there are multiple applications
> +  * using the drm device, and could possibly result in a timeout from
> +  * omap_crtc_flush() if an other application is actively queuing new
> +  * work.
> +  */
> + for (i = 0; i < priv->num_crtcs; i++)
> + omap_crtc_flush(priv->crtcs[i]);
>  }
>  
>  static void dev_postclose(struct drm_device *dev, struct drm_file *file)
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

[Daniel Vetter]

On Wed, Sep 03, 2014 at 02:55:08PM +0300, Tomi Valkeinen wrote:
> omap_crtc_flush() is used to wait for scheduled work to be done for the
> give crtc. However, it's not quite right at the moment.
> 
> omap_crtc_flush() does wait for work that is ran via vsync irq to be
> done. However, work is also queued to the driver's priv->wq workqueue,
> which is not handled by omap_crtc_flush().
> 
> Improve omap_crtc_flush() to flush the workqueue so that work there will
> be ran.
> 
> This fixes a race issue on module unload, where an unpin work may be on
> the work queue, but does not get ran before drm core starts tearing the
> driver down, leading to a WARN.
> 
> Signed-off-by: Tomi Valkeinen 

I didn't really dig into details, but isn't that the same workqueue as
used by the async modeset code? So the same deadlocks might happen ...

lockdep won't complain though since you essentially open-code a
workqueue_flush, and lockdep also doesn't complain about all possible
deadlocks (due to some design issues with lockdep).
-Daniel

> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 31 ++-
>  1 file changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 3261fbf94957..506cf8bc804f 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -655,21 +655,42 @@ static void omap_crtc_post_apply(struct omap_drm_apply 
> *apply)
>   /* nothing needed for post-apply */
>  }
>  
> +static bool omap_crtc_work_pending(struct omap_crtc *omap_crtc)
> +{
> + return !list_empty(_crtc->pending_applies) ||
> + !list_empty(_crtc->queued_applies) ||
> + omap_crtc->event || omap_crtc->old_fb;
> +}
> +
> +/*
> + * Wait for any work on the workqueue to be finished, and any work which will
> + * be run via vsync irq to be done.
> + *
> + * Note that work on workqueue could schedule new vsync work, and vice versa.
> + */
>  void omap_crtc_flush(struct drm_crtc *crtc)
>  {
>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> + struct omap_drm_private *priv = crtc->dev->dev_private;
>   int loops = 0;
>  
> - while (!list_empty(_crtc->pending_applies) ||
> - !list_empty(_crtc->queued_applies) ||
> - omap_crtc->event || omap_crtc->old_fb) {
> + while (true) {
> + /* first flush the wq, so that any scheduled work is done */
> + flush_workqueue(priv->wq);
> +
> + /* if we have nothing queued for this crtc, we're done */
> + if (!omap_crtc_work_pending(omap_crtc))
> + break;
>  
>   if (++loops > 10) {
> - dev_err(crtc->dev->dev,
> - "omap_crtc_flush() timeout\n");
> + dev_err(crtc->dev->dev, "omap_crtc_flush() timeout\n");
>   break;
>   }
>  
> + /*
> +  * wait for a bit so that a vsync has (probably) happened, and
> +  * that the crtc work is (probably) done.
> +  */
>   schedule_timeout_uninterruptible(msecs_to_jiffies(20));
>   }
>  }
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 4/9] drm/omap: make modesetting synchronous

[Daniel Vetter]

On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
> Currently modesetting is not done synchronously, but it queues work that
> is done later. In theory this is fine, but the driver doesn't handle it
> at properly. This means that if an application first does a full
> modeset, then immediately afterwards starts page flipping, the page
> flipping will not work properly as there's modeset work still in the
> queue.
> 
> The result with my test application was that a backbuffer was shown on
> the screen.
> 
> Fixing this properly would be rather big undertaking. Thus this patch
> fixes the issue by making the modesetting synchronous, by waiting for
> the queued work to be done at the end of omap_crtc->commit().
> 
> The ugly part here is that the background work takes crtc->mutex, and
> the modesetting also holds that lock, which means that the background
> work never gets done. To get around this, we unclock, wait, and lock
> again.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 193979f97bdb..3261fbf94957 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc *crtc)
>  static void omap_crtc_commit(struct drm_crtc *crtc)
>  {
>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
>   DBG("%s", omap_crtc->name);
>   omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
> +
> + drm_modeset_unlock_all(dev);

This will run afoul of the upcoming locking rework in the atomic work. And
I'm fairly sure that the crtc helpers will fall over badly if someone
submits a concurrent setCrtc while you've dropped the locks here.

Can't you instead just drop the locking from the worker? As long as you
synchronize like here at the right places it can't race. I expect that you
might want to synchronize in the crtc_prepare hook, too. But beyond that
it should work.

As-is nacked because future headaches for me ;-)

Cheers, Daniel

> + omap_crtc_flush(crtc);
> + drm_modeset_lock_all(dev);
>  }
>  
>  static int omap_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 83432] r600_query.c:269:r600_emit_query_end: Assertion `ctx->num_pipelinestat_queries > 0' failed [Gallium HUD]

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

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

--- Comment #3 from Heiko  ---
(In reply to comment #2)
> Created attachment 105679 [details] [review]
> possible fix 2
> 
> Please try this instead.

Hello Marek, the patch seems to resolve the issue. Didn't hit the assertion
anymore. The patch does also affect the non-statistics/non-hud path, doesn't
it?

-- 
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/20140903/74e36b73/attachment.html>

[RFC] firmware coredump: add new firmware coredump class

[Daniel Vetter]

> +   .name   = "fwcoredump",
> +   .dev_release= fwc_dev_release,
> +   .dev_groups = fwc_dev_groups,
> +};
> +
> +static ssize_t fwc_readv(char *buffer, loff_t offset, size_t count,
> +const void *data, size_t datalen)
> +{
> +   if (offset > datalen)
> +   return -EINVAL;
> +
> +   if (offset + count > datalen)
> +   count = datalen - offset;
> +
> +   if (count)
> +   memcpy(buffer, ((u8 *)data) + offset, count);
> +
> +   return count;
> +}
> +
> +/**
> + * fw_coredumpv - create firmware coredump with vmalloc data
> + * @dev: the struct device for the crashed device
> + * @data: vmalloc data containing the firmware coredump
> + * @datalen: length of the data
> + * @gfp: allocation flags
> + */
> +void fw_coredumpv(struct device *dev, const void *data, size_t datalen,
> + gfp_t gfp)
> +{
> +   fw_coredumpm(dev, NULL, data, datalen, gfp, fwc_readv, vfree);
> +}
> +EXPORT_SYMBOL(fw_coredumpv);
> +
> +/**
> + * fw_coredumpm - create firmware coredump with read/free methods
> + * @dev: the struct device for the crashed device
> + * @data: data cookie for the @read/@free functions
> + * @datalen: length of the data
> + * @gfp: allocation flags
> + * @read: function to read from the given buffer
> + * @free: function to free the given buffer
> + */
> +void fw_coredumpm(struct device *dev, struct module *owner,
> + const void *data, size_t datalen, gfp_t gfp,
> + ssize_t (*read)(char *buffer, loff_t offset, size_t
> count,
> + const void *data, size_t datalen),
> + void (*free)(const void *data))
> +{
> +   static atomic_t fwc_count = ATOMIC_INIT(0);
> +   struct fwc_entry *fwc;
> +
> +   if (!try_module_get(owner))
> +   return;
> +
> +   fwc = kzalloc(sizeof(*fwc), gfp);
> +   if (!fwc)
> +   goto put_module;
> +
> +   fwc->owner = owner;
> +   fwc->data = data;
> +   fwc->datalen = datalen;
> +   fwc->read = read;
> +   fwc->free = free;
> +
> +   device_initialize(>fwc_dev);
> +
> +   dev_set_name(>fwc_dev, "fwc%d",
> atomic_inc_return(_count));
> +   fwc->fwc_dev.class = _class;
> +
> +   if (device_add(>fwc_dev))
> +   goto put_device;
> +
> +   if (sysfs_create_link(>fwc_dev.kobj, >kobj,
> "failing_device"))
> +   /* nothing - symlink will be missing but that's ok */;
> +
> +   INIT_DELAYED_WORK(>del_wk, fwc_del);
> +   schedule_delayed_work(>del_wk, FWC_TIMEOUT);
> +
> +   return;
> + put_device:
> +   put_device(>fwc_dev);
> + put_module:
> +   module_put(owner);
> +}
> +EXPORT_SYMBOL(fw_coredumpm);
> +
> +static int __init fwcoredump_init(void)
> +{
> +   return class_register(_class);
> +}
> +module_init(fwcoredump_init);
> +
> +static int fwc_free(struct device *dev, void *data)
> +{
> +   struct fwc_entry *fwc = dev_to_fwc(dev);
> +
> +   flush_delayed_work(>del_wk);
> +   return 0;
> +}
> +
> +static void __exit fwcoredump_exit(void)
> +{
> +   class_for_each_device(_class, NULL, NULL, fwc_free);
> +   class_unregister(_class);
> +}
> +module_exit(fwcoredump_exit);
> diff --git a/include/linux/fwcoredump.h b/include/linux/fwcoredump.h
> new file mode 100644
> index ..168f2d6abfc0
> --- /dev/null
> +++ b/include/linux/fwcoredump.h
> @@ -0,0 +1,35 @@
> +#ifndef __FWCOREDUMP_H
> +#define __FWCOREDUMP_H
> +
> +#include 
> +#include 
> +#include 
> +
> +#ifdef CONFIG_FW_COREDUMP
> +void fw_coredumpv(struct device *dev, const void *data, size_t datalen,
> + gfp_t gfp);
> +
> +void fw_coredumpm(struct device *dev, struct module *owner,
> + const void *data, size_t datalen, gfp_t gfp,
> + ssize_t (*read)(char *buffer, loff_t offset, size_t
> count,
> + const void *data, size_t datalen),
> + void (*free)(const void *data));
> +#else
> +static inline void fw_coredumpv(struct device *dev, const void *data,
> +   size_t datalen, gfp_t gfp)
> +{
> +   vfree(data);
> +}
> +
> +static inline void
> +fw_coredumpm(struct device *dev, struct module *owner,
> +const void *data, size_t datalen, gfp_t gfp,
> +ssize_t (*read)(char *buffer, loff_t offset, size_t count,
> +const void *data, size_t datalen),
> +void (*free)(const void *data))
> +{
> +   free(data);
> +}
> +#endif /* CONFIG_FW_COREDUMP */
> +
> +#endif /* __FWCOREDUMP_H */
> --
> 2.1.0
>
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/ac86d648/attachment-0001.html>

[PATCH] drm/i915: init sprites with univeral plane init function

[Daniel Vetter]

On Wed, Sep 03, 2014 at 10:38:20AM -0300, Gustavo Padovan wrote:
> From: Derek Foreman 
> 
> Really just for completeness - old init function ends up making the plane
> exactly the same way due to the way the enums are set up.
> 
> Signed-off-by: Derek Foreman 
> Signed-off-by: Gustavo Padovan 

Queued for -next, thanks for the patch.
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 0bdb00b..4cbe286 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe 
> pipe, int plane)
>   intel_plane->plane = plane;
>   intel_plane->rotation = BIT(DRM_ROTATE_0);
>   possible_crtcs = (1 << pipe);
> - ret = drm_plane_init(dev, _plane->base, possible_crtcs,
> -  _plane_funcs,
> -  plane_formats, num_plane_formats,
> -  false);
> + ret = drm_universal_plane_init(dev, _plane->base, possible_crtcs,
> +_plane_funcs,
> +plane_formats, num_plane_formats,
> +DRM_PLANE_TYPE_OVERLAY);
>   if (ret) {
>   kfree(intel_plane);
>   goto out;
> -- 
> 1.9.3
> 

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

Radeon R7 240 Garbled Text

[Esben Stien]

I just wanted to provide a note on this issue. 

I saw lots of text getting garbled up all the time on the Radeon R7
240. It was certain letters that just got all messed up all the
time. When I minimized the window and maximized it again or entered the
tty and back again, it was gone. 

Anyways, by chance, I got a new card, a R9 270x, which I almost never
see it. I think I've seen the screen corruption two times the last
month, while on the last card, I saw it like 20 times a day. 

Other than that, I experience here that the Xonotic game takes down the
whole Xorg server, something that never happened on the last card, but
I'll request help on that in another mail.

-- 
Esben Stien is b0ef at e s  a 
 http://www. s tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #56 from Andy Furniss  ---
(In reply to comment #55)
> BTW, this could also mean that the pyrit performance regression was simply
> due to LLVM now taking slightly longer to compile a shader.

The llvm commit still reverts cleanly, so I tested and didn't gain anything
significant.

-- 
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/20140903/2fb0403c/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #79 from Michel D?nzer  ---
Aaron, most likely the bisection didn't work because you marked commits as good
which would have shown the problem after more testing. I'm afraid you'll have
to test longer before declaring a commit as good.

-- 
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/20140903/155402f7/attachment.html>

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, here's a couple of display regression fixes for 3.17.

BR,
Jani.

The following changes since commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a:

  drm/i915: Remove bogus __init annotation from DMI callbacks (2014-08-28 
09:54:27 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-09-03

for you to fetch changes up to bbfb44e8b688e778964275ab0862f67463ba4f84:

  drm/i915: Fix lock dropping in intel_tv_detect() (2014-09-02 12:58:51 +0300)


Dave Airlie (1):
  drm/i915: handle G45/GM45 pulse detection connected state.

Ville Syrj?l? (1):
  drm/i915: Fix lock dropping in intel_tv_detect()

 drivers/gpu/drm/i915/intel_dp.c | 55 +++--
 drivers/gpu/drm/i915/intel_tv.c | 10 +---
 2 files changed, 44 insertions(+), 21 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] gpu: ipu-v3: ipu-di: Print the generated pixelclock error

[Philipp Zabel]

Hi Fabio,

Am Dienstag, den 02.09.2014, 10:31 -0300 schrieb Fabio Estevam:
> For debug purposes it is useful to know how far away the generated pixelclock 
> is
> from the desired rate, so print the amount of error.
> 
> After adding this patch and with debug enabled we have:
> 
> imx-ipuv3 240.ipu: disp 0: panel size = 1920 x 1080
> imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 2400Hz Needed 
> 13850Hz
> imx-ipuv3 240.ipu:   IPU clock can give 13200 with divider 2, error 
> -4.3%
> imx-ipuv3 240.ipu: Want 13850Hz IPU 26400Hz DI 13850Hz using 
> DI, 13850Hz, error 0.0%
> imx-ipuv3 240.ipu: disp 1: panel size = 1024 x 768
> imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz
> imx-ipuv3 240.ipu: Want 6500Hz IPU 26400Hz DI 6499Hz using 
> DI, 6499Hz, error 0.9%

As this example shows ...

[...]
> - dev_dbg(di->ipu->dev, "Want %luHz IPU %luHz DI %luHz using %s, %luHz\n",
> + error = (clk_get_rate(di->clk_di_pixel) / (clkgen0 >> 4)) / 
> (sig->pixelclock / 1000);
> +
> + dev_dbg(di->ipu->dev, "Want %luHz IPU %luHz DI %luHz using %s, %luHz, 
> error %d.%u%%\n",
>   sig->pixelclock,
>   clk_get_rate(di->clk_ipu),
>   clk_get_rate(di->clk_di),
>   clk == di->clk_di ? "DI" : "IPU",
> - clk_get_rate(di->clk_di_pixel) / (clkgen0 >> 4));
> + clk_get_rate(di->clk_di_pixel) / (clkgen0 >> 4),
> + (signed)(error - 1000) / 10, error % 10);

... this only works for positive deviations. If error < 1000, error % 10
will return the wrong value and for 990 < error < 1000 the sign is
missing.

Also you are losing a lot of presicion. the real error in the example is
more like 0.02%, so I wonder how useful this really is.

regards
Philipp

[PATCH 9/9] drm/omap: add a comment why locking is missing

[Tomi Valkeinen]

unpin_worker() calls omap_framebuffer_unpin() without any locks, which
looks very suspicious. However, both pin and unpin are always called via
the driver's private workqueue, so the access is synchronized that way.

Add a comment to make this clear.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_plane.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 891a4dc608af..743d04981d71 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -71,6 +71,10 @@ static void unpin_worker(struct drm_flip_work *work, void 
*val)
container_of(work, struct omap_plane, unpin_work);
struct drm_device *dev = omap_plane->base.dev;

+   /*
+* omap_framebuffer_pin/unpin are always called from priv->wq,
+* so there's no need for locking here.
+*/
omap_framebuffer_unpin(val);
mutex_lock(>mode_config.mutex);
drm_framebuffer_unreference(val);
-- 
1.9.1

[PATCH 8/9] drm/omap: fix preclose to wait for scheduled work

[Tomi Valkeinen]

We already wait for all scheduled work to be done on the driver's unload
function. However, I think we need to wait on preclose() also, so that
when an application closes the drm file descriptor, we are sure that
there's no left around.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 26fda74c1e48..f59fa6600cf8 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -594,7 +594,20 @@ static void dev_lastclose(struct drm_device *dev)

 static void dev_preclose(struct drm_device *dev, struct drm_file *file)
 {
+   struct omap_drm_private *priv = dev->dev_private;
+   int i;
+
DBG("preclose: dev=%p", dev);
+
+   /*
+* Flush crtcs to finish any pending work.
+* Note: this may not be correct if there are multiple applications
+* using the drm device, and could possibly result in a timeout from
+* omap_crtc_flush() if an other application is actively queuing new
+* work.
+*/
+   for (i = 0; i < priv->num_crtcs; i++)
+   omap_crtc_flush(priv->crtcs[i]);
 }

 static void dev_postclose(struct drm_device *dev, struct drm_file *file)
-- 
1.9.1

[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

[Tomi Valkeinen]

omap_crtc_flush() is used to wait for scheduled work to be done for the
give crtc. However, it's not quite right at the moment.

omap_crtc_flush() does wait for work that is ran via vsync irq to be
done. However, work is also queued to the driver's priv->wq workqueue,
which is not handled by omap_crtc_flush().

Improve omap_crtc_flush() to flush the workqueue so that work there will
be ran.

This fixes a race issue on module unload, where an unpin work may be on
the work queue, but does not get ran before drm core starts tearing the
driver down, leading to a WARN.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 3261fbf94957..506cf8bc804f 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -655,21 +655,42 @@ static void omap_crtc_post_apply(struct omap_drm_apply 
*apply)
/* nothing needed for post-apply */
 }

+static bool omap_crtc_work_pending(struct omap_crtc *omap_crtc)
+{
+   return !list_empty(_crtc->pending_applies) ||
+   !list_empty(_crtc->queued_applies) ||
+   omap_crtc->event || omap_crtc->old_fb;
+}
+
+/*
+ * Wait for any work on the workqueue to be finished, and any work which will
+ * be run via vsync irq to be done.
+ *
+ * Note that work on workqueue could schedule new vsync work, and vice versa.
+ */
 void omap_crtc_flush(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   struct omap_drm_private *priv = crtc->dev->dev_private;
int loops = 0;

-   while (!list_empty(_crtc->pending_applies) ||
-   !list_empty(_crtc->queued_applies) ||
-   omap_crtc->event || omap_crtc->old_fb) {
+   while (true) {
+   /* first flush the wq, so that any scheduled work is done */
+   flush_workqueue(priv->wq);
+
+   /* if we have nothing queued for this crtc, we're done */
+   if (!omap_crtc_work_pending(omap_crtc))
+   break;

if (++loops > 10) {
-   dev_err(crtc->dev->dev,
-   "omap_crtc_flush() timeout\n");
+   dev_err(crtc->dev->dev, "omap_crtc_flush() timeout\n");
break;
}

+   /*
+* wait for a bit so that a vsync has (probably) happened, and
+* that the crtc work is (probably) done.
+*/
schedule_timeout_uninterruptible(msecs_to_jiffies(20));
}
 }
-- 
1.9.1

[PATCH 6/9] drm/omap: add pin refcounting to omap_framebuffer

[Tomi Valkeinen]

omap_framebuffer_pin() and omap_framebuffer_unpin() are currently
broken, as they cannot be called multiple times (i.e. pin, pin, unpin,
unpin), which is what happens in certain cases. This issue causes the
driver to possibly use 0 as an address for a displayed buffer, leading
to OCP error from DSS.

This patch fixes the issue by adding a simple pin_count, used to track
the number of pins.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_fb.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2a5cacdc344b..58f2af32ede8 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -86,6 +86,7 @@ struct plane {

 struct omap_framebuffer {
struct drm_framebuffer base;
+   int pin_count;
const struct format *format;
struct plane planes[4];
 };
@@ -261,6 +262,11 @@ int omap_framebuffer_pin(struct drm_framebuffer *fb)
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
int ret, i, n = drm_format_num_planes(fb->pixel_format);

+   if (omap_fb->pin_count > 0) {
+   omap_fb->pin_count++;
+   return 0;
+   }
+
for (i = 0; i < n; i++) {
struct plane *plane = _fb->planes[i];
ret = omap_gem_get_paddr(plane->bo, >paddr, true);
@@ -269,6 +275,8 @@ int omap_framebuffer_pin(struct drm_framebuffer *fb)
omap_gem_dma_sync(plane->bo, DMA_TO_DEVICE);
}

+   omap_fb->pin_count++;
+
return 0;

 fail:
@@ -287,6 +295,11 @@ int omap_framebuffer_unpin(struct drm_framebuffer *fb)
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
int ret, i, n = drm_format_num_planes(fb->pixel_format);

+   omap_fb->pin_count--;
+
+   if (omap_fb->pin_count > 0)
+   return 0;
+
for (i = 0; i < n; i++) {
struct plane *plane = _fb->planes[i];
ret = omap_gem_put_paddr(plane->bo);
-- 
1.9.1

[PATCH 5/9] drm/omap: clear omap_obj->paddr in omap_gem_put_paddr()

[Tomi Valkeinen]

Clear omap_obj's paddr when unmapping the memory, so that it's easier to
catch bad use of the paddr.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index e4849413ee80..b342e7b3bf00 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -829,6 +829,7 @@ int omap_gem_put_paddr(struct drm_gem_object *obj)
dev_err(obj->dev->dev,
"could not release unmap: %d\n", ret);
}
+   omap_obj->paddr = 0;
omap_obj->block = NULL;
}
}
-- 
1.9.1

[PATCH 4/9] drm/omap: make modesetting synchronous

[Tomi Valkeinen]

Currently modesetting is not done synchronously, but it queues work that
is done later. In theory this is fine, but the driver doesn't handle it
at properly. This means that if an application first does a full
modeset, then immediately afterwards starts page flipping, the page
flipping will not work properly as there's modeset work still in the
queue.

The result with my test application was that a backbuffer was shown on
the screen.

Fixing this properly would be rather big undertaking. Thus this patch
fixes the issue by making the modesetting synchronous, by waiting for
the queued work to be done at the end of omap_crtc->commit().

The ugly part here is that the background work takes crtc->mutex, and
the modesetting also holds that lock, which means that the background
work never gets done. To get around this, we unclock, wait, and lock
again.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 193979f97bdb..3261fbf94957 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc *crtc)
 static void omap_crtc_commit(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   struct drm_device *dev = crtc->dev;
DBG("%s", omap_crtc->name);
omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
+
+   drm_modeset_unlock_all(dev);
+   omap_crtc_flush(crtc);
+   drm_modeset_lock_all(dev);
 }

 static int omap_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
-- 
1.9.1

[PATCH 3/9] drm/omap: fix race issue with vsync irq and apply

[Tomi Valkeinen]

omap_crtc's apply_worker does:

omap_irq_register(dev, _crtc->apply_irq);
dispc_mgr_go(channel);

This is supposed to enable the vsync irq, and set the GO bit. The vsync
handler will later check if the HW has cleared the GO bit and queue
apply work.

However, what may happen is that the vsync irq is enabled, and it gets
ran before the GO bit is set by the apply_worker. In this case the vsync
handler will see the GO bit as cleared, and queues the apply work too
early.

This causes WARN'ings from dispc driver, and possibly other problems.

This patch fixes the issue by adding a new variable, 'go_bit_set' which
is used to track the supposed state of GO bit and helps the apply worker
and irq handler handle the job without a race.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0812b0f80167..193979f97bdb 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -47,6 +47,9 @@ struct omap_crtc {
bool enabled;
bool full_update;

+   /* tracks the state of GO bit between irq handler and apply worker */
+   bool go_bit_set;
+
struct omap_drm_apply apply;

struct omap_drm_irq apply_irq;
@@ -442,11 +445,16 @@ static void omap_crtc_apply_irq(struct omap_drm_irq *irq, 
uint32_t irqstatus)
if (!omap_crtc->error_irq.registered)
__omap_irq_register(crtc->dev, _crtc->error_irq);

-   if (!dispc_mgr_go_busy(omap_crtc->channel)) {
+   /* make sure we see the most recent 'go_bit_set' */
+   rmb();
+   if (omap_crtc->go_bit_set && !dispc_mgr_go_busy(omap_crtc->channel)) {
struct omap_drm_private *priv =
crtc->dev->dev_private;
DBG("%s: apply done", omap_crtc->name);
__omap_irq_unregister(crtc->dev, _crtc->apply_irq);
+   omap_crtc->go_bit_set = false;
+   /* make sure apple_worker sees 'go_bit_set = false' */
+   wmb();
queue_work(priv->wq, _crtc->apply_work);
}
 }
@@ -472,7 +480,9 @@ static void apply_worker(struct work_struct *work)
 * If we are still pending a previous update, wait.. when the
 * pending update completes, we get kicked again.
 */
-   if (omap_crtc->apply_irq.registered)
+   /* make sure we see the most recent 'go_bit_set' */
+   rmb();
+   if (omap_crtc->go_bit_set)
goto out;

/* finish up previous apply's: */
@@ -502,6 +512,9 @@ static void apply_worker(struct work_struct *work)
if (dispc_mgr_is_enabled(channel)) {
omap_irq_register(dev, _crtc->apply_irq);
dispc_mgr_go(channel);
+   omap_crtc->go_bit_set = true;
+   /* make sure the irq handler sees 'go_bit_set' */
+   wmb();
} else {
struct omap_drm_private *priv = dev->dev_private;
queue_work(priv->wq, _crtc->apply_work);
-- 
1.9.1

[PATCH 2/9] drm/omap: page_flip: return -EBUSY if flip pending

[Tomi Valkeinen]

The DRM documentation says:

"If a page flip is already pending, the page_flip operation must return
-EBUSY."

Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning
-EBUSY.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 2d28dc337cfb..0812b0f80167 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -360,7 +360,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
if (omap_crtc->old_fb) {
spin_unlock_irqrestore(>event_lock, flags);
dev_err(dev->dev, "already a pending flip\n");
-   return -EINVAL;
+   return -EBUSY;
}

omap_crtc->event = event;
-- 
1.9.1

[PATCH 1/9] drm/omap: fix encoder-crtc mapping

[Tomi Valkeinen]

OMAP DSS hardware supports changing the output port to which an overlay
manager's video stream goes. For example, DPI video stream can come from
any of the four overlay managers on OMAP5.

However, as it's difficult to manage the change in the driver, the
omapdss driver does not support that at the moment, and has a hardcoded
overlay manager per output.

omapdrm, on the other hand, uses the hardware features to find out which
overlay manager to use for an output, which causes problems. For
example, on OMAP5, omapdrm tries to use DIGIT overlay manager for DPI
output, instead of the LCD3 required by the omapdss driver.

This patch changes the omapdrm to use the omapdss driver's hardcoded
overlay managers, which fixes the issue.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 002b9721e85a..26fda74c1e48 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -286,14 +286,13 @@ static int omap_modeset_init(struct drm_device *dev)
for (id = 0; id < priv->num_crtcs; id++) {
struct drm_crtc *crtc = priv->crtcs[id];
enum omap_channel crtc_channel;
-   enum omap_dss_output_id supported_outputs;

crtc_channel = omap_crtc_channel(crtc);
-   supported_outputs =
-   dss_feat_get_supported_outputs(crtc_channel);

-   if (supported_outputs & output->id)
+   if (output->dispc_channel == crtc_channel) {
encoder->possible_crtcs |= (1 << id);
+   break;
+   }
}

omap_dss_put_device(output);
-- 
1.9.1

linux-next: manual merge of the drm-intel tree with the tree

[Mark Brown]

On Wed, Sep 03, 2014 at 02:31:46PM +0100, Mark Brown wrote:

> @@ -3923,7 +3942,9 @@ static void valleyview_irq_uninstall(struct drm_device 
> *dev)
>  
>   I915_WRITE(VLV_MASTER_IER, 0);
>  
> - for_each_pipe(pipe)
> + intel_hpd_irq_uninstall(dev_priv);
> +
> + for_each_pipe(dev_priv, pipe)
>   I915_WRITE(PIPESTAT(pipe), 0x);
>  
>   I915_WRITE(HWSTAM, 0x);

...or actually this since the above doesn't build, I was too hasty:


@@ -3923,7 +3942,9 @@ static void valleyview_irq_uninstall(struct drm_device 
*dev)

I915_WRITE(VLV_MASTER_IER, 0);

-   for_each_pipe(pipe)
+
+   for_each_pipe(dev_priv, pipe)
I915_WRITE(PIPESTAT(pipe), 0x);

I915_WRITE(HWSTAM, 0x);
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/736a97be/attachment-0001.sig>

linux-next: manual merge of the drm-intel tree with the tree

[Mark Brown]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict which I'm not 
really sure of and commit b47d1189da119e ("drm/i915: Use dev_priv as first 
argument of for_each_pipe()") from the drm-intel tree.

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

@@ -3923,7 +3942,9 @@ static void valleyview_irq_uninstall(struct drm_device 
*dev)

I915_WRITE(VLV_MASTER_IER, 0);

-   for_each_pipe(pipe)
+   intel_hpd_irq_uninstall(dev_priv);
+
+   for_each_pipe(dev_priv, pipe)
I915_WRITE(PIPESTAT(pipe), 0x);

I915_WRITE(HWSTAM, 0x);
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140903/5a887253/attachment.sig>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #11 from Vadim Girlin  ---
(In reply to comment #2)
> I get no lockup either, but I do see the same GPUVM protection faults:
> 
>  radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0FF00819
> 
> The FF bits make me suspect bits 32-4x of the GPUVM address are getting
> clobbered, maybe because of the LLVM backend generating invalid shader code.

I've found similar bug with incorrect high part of the address and the problem
was that llvm backend uses S_ADD/SUB_I32 for lowering 64-bit integer add/sub,
but it should use _U32 versions instead. I was going to send the patch but the
fix is trivial, basically just replace all uses of S_ADD/SUB_I32 with
S_ADD/SUB_U32. I'm not sure if you are hitting the same issue though.

-- 
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/20140903/c6cc8169/attachment.html>

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #55 from Michel D?nzer  ---
BTW, this could also mean that the pyrit performance regression was simply due
to LLVM now taking slightly longer to compile a shader.

-- 
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/20140903/99732755/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

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

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

--- Comment #7 from smoki  ---
 Actually nothing to do with the -O3, but with the -mtune -march it seems.

 On Debian default is -mtune=generic -march=i586 maybe that is the problem, if
i pass -mtune=native -march=native then it performs fine in most cases :) But
not all, glretrace sometimes perform slow sometimes fast... so build system
seems borked currently even more on 32bit :)

-- 
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/20140903/f93c67b2/attachment.html>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #10 from Laurent carlier  ---
Just tried with mesa-10.2.6/llvm-3.4.2 and the trace works fine except the
following from LLVM:
LLVM ERROR: ran out of registers during register allocation

Here are the flags used:
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
--param=ssp-buffer-size=4"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
--param=ssp-buffer-size=4"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

-- 
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/20140903/1d4d444f/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

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

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

--- Comment #6 from Maciej  ---
Yes, it's 64bit for sure. 

As for your fix, I'm getting my mesa from Oibaf PPA, got not enough knowledge
to compile it myself.

-- 
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/20140903/e46d425d/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

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

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

--- Comment #5 from smoki  ---
(In reply to comment #4)
> Wait a minute... Unigine is affected, but it's 64bit. Reporting bugs is
> confusing, especially when you can't edit your post ;)

 Unigine Heaven have 64 and 32 variants in it as i see, are you sure he does
not load 32bit one? 

 If you build you mesa try -O3 gcc optimization, that seems fixed those...
don't know yet what is particular issue with default optimization :).

-- 
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/20140903/4863bedc/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

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

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

Maciej  changed:

   What|Removed |Added

   Severity|major   |normal

-- 
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/20140903/afdff33f/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

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

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

--- Comment #4 from Maciej  ---
Wait a minute... Unigine is affected, but it's 64bit. Reporting bugs is
confusing, especially when you can't edit your post ;)

-- 
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/20140903/153e2573/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

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

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

--- Comment #3 from Maciej  ---
Yes all 32bit. Xonotic (64bit) is not affected by sudden drops, only by
performance decrease, I should have made it a bit more clear, sorry.

-- 
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/20140903/b74a4f78/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games

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

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

--- Comment #2 from smoki  ---

 I seeing that too now, all of those are 32bit apps is it? 

 -03 compiled mesa seems to fixed that for me.

-- 
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/20140903/7e15ca13/attachment.html>

[Intel-gfx] [PATCH -v2 1/4] drm/i915: init sprites with univeral plane init function

[Daniel Vetter]

On Wed, Sep 03, 2014 at 10:38:17AM +0200, Daniel Vetter wrote:
> On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrj?l? wrote:
> > On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
> > > From: Derek Foreman 
> > > 
> > > Really just for completeness - old init function ends up making the plane
> > > exactly the same way due to the way the enums are set up.
> > > 
> > > Signed-off-by: Derek Foreman 
> > 
> > Reviewed-by: Ville Syrj?l? 
> 
> Queued for -next, thanks for the patch. And patch 2 is already merged from
> the previous round.

Actually I can't merge this patch since it's not authered by you, but is
missing your signed-off-by line. Please resend with that fixed, thanks.

If you handle a patch for the linux kernel, you _always_ have to add your
sob in accordance with the Developer's Certificate of Origin.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 83436] Sudden framerate drops in multiple games

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

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

--- Comment #1 from Maciej  ---
Created attachment 105681
  --> https://bugs.freedesktop.org/attachment.cgi?id=105681=edit
Xorg.0.log

-- 
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/20140903/762f302a/attachment.html>

[Bug 83436] New: Sudden framerate drops in multiple games

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

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

  Priority: medium
Bug ID: 83436
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Sudden framerate drops in multiple games
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: gutigen at outlook.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 105680
  --> https://bugs.freedesktop.org/attachment.cgi?id=105680=edit
dmesg

I'm having a lot of fps drops in TF2, Unigine Heaven, Xonotic, Wine games.
Framerate goes from even something like stable 100fps to sudden 5-15fps, it
hangs there for few seconds and goes back up to usual. 

On top of that I've noticed some performance decrease in above apps by even
20%.

This is happening since last week (maybe friday? something around the weekend).

-- 
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/20140903/896cd89c/attachment-0001.html>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #9 from smoki  ---

 Try also some stable mesas if you can 10.2 or 10.3, i have very strange issues
with 32bit mesa and apps, particulary build system in current git seems very
broken for me. Make install, SSE41 macro compile needs much more CPU time,
striping does not work fine, default optimization level is not good -O3 fixes
it, etc.

-- 
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/20140903/7aaceb9d/attachment.html>

[Bug 83432] r600_query.c:269:r600_emit_query_end: Assertion `ctx->num_pipelinestat_queries > 0' failed [Gallium HUD]

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

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

Marek Ol??k  changed:

   What|Removed |Added

 Attachment #105678|0   |1
is obsolete||

--- Comment #2 from Marek Ol??k  ---
Created attachment 105679
  --> https://bugs.freedesktop.org/attachment.cgi?id=105679=edit
possible fix 2

Please try this instead.

-- 
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/20140903/b7df0f41/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #78 from Marek Ol??k  ---
(In reply to comment #77)
> Took a few hours, but only one shot thankfully.
> 
> first bad commit: [0e7b0f2a0ad3818d02907746a86568c264c97701] meta: Refactor
> binding of renderbuffer as texture image
> 
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=0e7b0f2a0ad3818d02907746a86568c264c97701
> 
> I think this is all you guys, now.

That commit doesn't have any effect on radeonsi. Back to square one I guess.

-- 
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/20140903/a7a469e0/attachment.html>

[Bug 83432] r600_query.c:269:r600_emit_query_end: Assertion `ctx->num_pipelinestat_queries > 0' failed [Gallium HUD]

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

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

--- Comment #1 from Marek Ol??k  ---
Created attachment 105678
  --> https://bugs.freedesktop.org/attachment.cgi?id=105678=edit
possible fix

Could you please test this patch?

-- 
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/20140903/70fc8f5b/attachment.html>

[PATCH 4/9] drm/omap: make modesetting synchronous

[Rob Clark]

On Wed, Sep 3, 2014 at 11:21 AM, Daniel Vetter  wrote:
> On Wed, Sep 03, 2014 at 11:05:08AM -0400, Rob Clark wrote:
>> On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter  wrote:
>> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
>> >> Currently modesetting is not done synchronously, but it queues work that
>> >> is done later. In theory this is fine, but the driver doesn't handle it
>> >> at properly. This means that if an application first does a full
>> >> modeset, then immediately afterwards starts page flipping, the page
>> >> flipping will not work properly as there's modeset work still in the
>> >> queue.
>> >>
>> >> The result with my test application was that a backbuffer was shown on
>> >> the screen.
>> >>
>> >> Fixing this properly would be rather big undertaking. Thus this patch
>> >> fixes the issue by making the modesetting synchronous, by waiting for
>> >> the queued work to be done at the end of omap_crtc->commit().
>> >>
>> >> The ugly part here is that the background work takes crtc->mutex, and
>> >> the modesetting also holds that lock, which means that the background
>> >> work never gets done. To get around this, we unclock, wait, and lock
>> >> again.
>> >>
>> >> Signed-off-by: Tomi Valkeinen 
>> >> ---
>> >>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
>> >>  1 file changed, 5 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> >> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> index 193979f97bdb..3261fbf94957 100644
>> >> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc *crtc)
>> >>  static void omap_crtc_commit(struct drm_crtc *crtc)
>> >>  {
>> >>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> >> + struct drm_device *dev = crtc->dev;
>> >>   DBG("%s", omap_crtc->name);
>> >>   omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>> >> +
>> >> + drm_modeset_unlock_all(dev);
>> >
>> > This will run afoul of the upcoming locking rework in the atomic work. And
>> > I'm fairly sure that the crtc helpers will fall over badly if someone
>> > submits a concurrent setCrtc while you've dropped the locks here.
>>
>> what about just dropping and re-acquiring crtc->mutex, since that is
>> all the worker actually needs..
>>
>> it would be a bigger task to get rid of the mutex on the worker, since
>> we'd have to double buffer state.  It seemed like rather than
>> re-invent atomic, it would be better just to wait for atomic to land
>> and then restructure the driver
>
> Well atomic kinda has the same idea to not take locks in the worker and
> instead relying on ordering.

so, I am not quite sure that would work..  (and maybe this is an extra
thing to think about for atomic).

The problem is that hw has no hw cursor.  So cursor is implemented
using plane.  But thanks to retarded userspace that rapidly
enables/disables cursor in some cases, we really need plane updates to
be async.  The way it currently works is userspace thread updates
plane state as rapidly as it wants.  When worker eventually gets to
run, it takes the most current state, possibly skipping 1000's of
enable/disable that happened in the mean time.

But for that to work, at least the way the driver is structured
currently, the worker needs to synchronize against userspace somehow.

BR,
-R

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

[PATCH -v2 4/4] drm/i915: split intel_update_plane into check() and commit()

[Ville Syrjälä]

On Tue, Sep 02, 2014 at 04:23:47PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Due to the upcoming atomic modesetting feature we need to separate
> some update functions into a check step that can fail and a commit
> step that should, ideally, never fail.
> 
> This commit splits intel_update_plane() and its commit part can still
> fail due to the fb pinning procedure.
> 
> v2: use the new struct intel_plane_state to store information
> between check and commit stages.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 236 
> ++--
>  1 file changed, 146 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 4cbe286..062eca2 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -845,57 +845,28 @@ static bool colorkey_enabled(struct intel_plane 
> *intel_plane)
>  }
>  
>  static int
> -intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
> -struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> -unsigned int crtc_w, unsigned int crtc_h,
> -uint32_t src_x, uint32_t src_y,
> -uint32_t src_w, uint32_t src_h)
> +intel_check_sprite_plane(struct drm_plane *plane,
> +  struct intel_plane_state *pstate)

pstate looks a bit funny. Makes me think on cpu pstates. Maybe just call
it 'state' everywhere?

>  {
> - struct drm_device *dev = plane->dev;
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc *intel_crtc = to_intel_crtc(pstate->crtc);
>   struct intel_plane *intel_plane = to_intel_plane(plane);
> - enum pipe pipe = intel_crtc->pipe;
> + struct drm_framebuffer *fb = pstate->fb;
>   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
>   struct drm_i915_gem_object *obj = intel_fb->obj;
> - struct drm_i915_gem_object *old_obj = intel_plane->obj;
> - int ret;
> - bool primary_enabled;
> - bool visible;
> + int crtc_x = pstate->crtc_x;
> + int crtc_y = pstate->crtc_y;
> + int crtc_w = pstate->crtc_w;
> + int crtc_h = pstate->crtc_h;
> + int src_x = pstate->src_x;
> + int src_y = pstate->src_y;
> + int src_w = pstate->src_w;
> + int src_h = pstate->src_h;

AFAICS we don't need to initialize this stuff here. We already populate
it all before we need it further down. So I think the only thing we need
is add a bit of code to write the src_? coordinates back into
pstate->src (at the end of check() like you already do for the dst
coordinates). To avoid warning about unitialized variables that
probably needs to be wrapped in an 'if (visible)' check.

> + struct drm_rect *src = >src;
> + struct drm_rect *dst = >dst;
> + struct drm_rect *clip = >clip;

Please keep 'clip' const here to prevent silly accidents.

>   int hscale, vscale;
>   int max_scale, min_scale;
>   int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
> - struct drm_rect src = {
> - /* sample coordinates in 16.16 fixed point */
> - .x1 = src_x,
> - .x2 = src_x + src_w,
> - .y1 = src_y,
> - .y2 = src_y + src_h,
> - };
> - struct drm_rect dst = {
> - /* integer pixels */
> - .x1 = crtc_x,
> - .x2 = crtc_x + crtc_w,
> - .y1 = crtc_y,
> - .y2 = crtc_y + crtc_h,
> - };
> - const struct drm_rect clip = {
> - .x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
> - .y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
> - };
> - const struct {
> - int crtc_x, crtc_y;
> - unsigned int crtc_w, crtc_h;
> - uint32_t src_x, src_y, src_w, src_h;
> - } orig = {
> - .crtc_x = crtc_x,
> - .crtc_y = crtc_y,
> - .crtc_w = crtc_w,
> - .crtc_h = crtc_h,
> - .src_x = src_x,
> - .src_y = src_y,
> - .src_w = src_w,
> - .src_h = src_h,
> - };
>  
>   /* Don't modify another pipe's plane */
>   if (intel_plane->pipe != intel_crtc->pipe) {
> @@ -927,55 +898,55 @@ intel_update_plane(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>   max_scale = intel_plane->max_downscale << 16;
>   min_scale = intel_plane->can_scale ? 1 : (1 << 16);
>  
> - drm_rect_rotate(, fb->width << 16, fb->height << 16,
> + drm_rect_rotate(src, fb->width << 16, fb->height << 16,
>   intel_plane->rotation);
>  
> - hscale = drm_rect_calc_hscale_relaxed(, , min_scale, max_scale);
> + hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
>   BUG_ON(hscale < 0);
>  
> - vscale = drm_rect_calc_vscale_relaxed(, , min_scale, max_scale);
> + vscale = 

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #8 from smoki  ---
 @Laurent carlier

 Is this new issue or regressions maybe?

 Don't have SSAM3 game, but i remember from earlier versions that Serios Sam
have bunch of different settings, maybe you can try some different settings
started with Low or something, maybe only some of settings triggers the issue,
etc.

-- 
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/20140903/b773393c/attachment.html>

[PATCH -v2 3/4] drm/i915: create struct intel_plane_state

[Ville Syrjälä]

On Tue, Sep 02, 2014 at 04:23:46PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This new struct will be the storage of src and dst coordinates
> between the check and commit stages of a plane update.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 4ab0d92..59c1675 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * _wait_for - magic (register) wait macro
> @@ -227,6 +228,25 @@ typedef struct dpll {
>   int p;
>  } intel_clock_t;
>  
> +struct intel_plane_state {
> + struct drm_crtc *crtc;
> + struct drm_framebuffer *fb;
> + int crtc_x;
> + int crtc_y;
> + unsigned int crtc_w;
> + unsigned int crtc_h;
> + uint32_t src_x;
> + uint32_t src_y;
> + uint32_t src_w;
> + uint32_t src_h;

Seems to me we shouldn't need these non-drm_rect coordinates in
this struct. I'll comment a bit more on the next patch since that's
where this is used.

> + struct drm_rect src;
> + struct drm_rect dst;
> + struct drm_rect clip;
> + struct drm_rect orig_src;
> + struct drm_rect orig_dst;
> + bool visible;
> +};
> +
>  struct intel_plane_config {
>   bool tiled;
>   int size;
> -- 
> 1.9.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Intel-gfx] [PATCH -v2 1/4] drm/i915: init sprites with univeral plane init function

[Ville Syrjälä]

On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
> From: Derek Foreman 
> 
> Really just for completeness - old init function ends up making the plane
> exactly the same way due to the way the enums are set up.
> 
> Signed-off-by: Derek Foreman 

Reviewed-by: Ville Syrj?l? 

> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 0bdb00b..4cbe286 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe 
> pipe, int plane)
>   intel_plane->plane = plane;
>   intel_plane->rotation = BIT(DRM_ROTATE_0);
>   possible_crtcs = (1 << pipe);
> - ret = drm_plane_init(dev, _plane->base, possible_crtcs,
> -  _plane_funcs,
> -  plane_formats, num_plane_formats,
> -  false);
> + ret = drm_universal_plane_init(dev, _plane->base, possible_crtcs,
> +_plane_funcs,
> +plane_formats, num_plane_formats,
> +DRM_PLANE_TYPE_OVERLAY);
>   if (ret) {
>   kfree(intel_plane);
>   goto out;
> -- 
> 1.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrj?l?
Intel OTC

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #127 from Andy Furniss  ---
(In reply to comment #126)
> (In reply to comment #124)
> > I can very quickly, almost deterministically, hang the GPU (radeonsi, Cape
> > Verde) with the following command:
> > 
> > > LIBGL_ALWAYS_SOFTWARE=1 mpv --fs --vo=opengl:sw /path/to/some_video
> 
> I'm sorry but I can't reproduce it with Tahiti (HD7950).

I also can't reproduce with pitcairn (R9270X)

On agd5f drm-next-3.18-wip, git mesa,llvm,ddx,glamor. Xorg couple of months
old.

Tried with mplayer and 2 versions of mpv.

Running fluxbox, so no compositor.

Other differences - I guess mesa/llvmpipe uses different sse for me on older
CPU (phenom II x4 965).

Screen res? I am testing 1920x1080 at 60Hz.

-- 
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/20140903/ad81bd39/attachment-0001.html>

[PATCH 4/9] drm/omap: make modesetting synchronous

[Rob Clark]

On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter  wrote:
> On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
>> Currently modesetting is not done synchronously, but it queues work that
>> is done later. In theory this is fine, but the driver doesn't handle it
>> at properly. This means that if an application first does a full
>> modeset, then immediately afterwards starts page flipping, the page
>> flipping will not work properly as there's modeset work still in the
>> queue.
>>
>> The result with my test application was that a backbuffer was shown on
>> the screen.
>>
>> Fixing this properly would be rather big undertaking. Thus this patch
>> fixes the issue by making the modesetting synchronous, by waiting for
>> the queued work to be done at the end of omap_crtc->commit().
>>
>> The ugly part here is that the background work takes crtc->mutex, and
>> the modesetting also holds that lock, which means that the background
>> work never gets done. To get around this, we unclock, wait, and lock
>> again.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> index 193979f97bdb..3261fbf94957 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc *crtc)
>>  static void omap_crtc_commit(struct drm_crtc *crtc)
>>  {
>>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> + struct drm_device *dev = crtc->dev;
>>   DBG("%s", omap_crtc->name);
>>   omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>> +
>> + drm_modeset_unlock_all(dev);
>
> This will run afoul of the upcoming locking rework in the atomic work. And
> I'm fairly sure that the crtc helpers will fall over badly if someone
> submits a concurrent setCrtc while you've dropped the locks here.

what about just dropping and re-acquiring crtc->mutex, since that is
all the worker actually needs..

it would be a bigger task to get rid of the mutex on the worker, since
we'd have to double buffer state.  It seemed like rather than
re-invent atomic, it would be better just to wait for atomic to land
and then restructure the driver

BR,
-R

> Can't you instead just drop the locking from the worker? As long as you
> synchronize like here at the right places it can't race. I expect that you
> might want to synchronize in the crtc_prepare hook, too. But beyond that
> it should work.
>
> As-is nacked because future headaches for me ;-)
>
> Cheers, Daniel
>
>> + omap_crtc_flush(crtc);
>> + drm_modeset_lock_all(dev);
>>  }
>>
>>  static int omap_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 83422] i was opening systemsettings, chose workspace design and the default look and feel screen just stays black when resizing the window or chosing another option on the left panel, it crashes

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

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

--- Comment #6 from simon  ---
@Michel D?nzer

my xorg.conf is empty. if i add your lines the complete screen turns black the
next time i login making kubuntu unusable.

not keen to mess arround with mesa drivers, as i have kde plasma next installed
next to kde 4 and need kde4 for work.
or is this update available through the update center?

-- 
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/20140903/b9d665aa/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #77 from Aaron B  ---
Took a few hours, but only one shot thankfully.

first bad commit: [0e7b0f2a0ad3818d02907746a86568c264c97701] meta: Refactor
binding of renderbuffer as texture image

http://cgit.freedesktop.org/mesa/mesa/commit/?id=0e7b0f2a0ad3818d02907746a86568c264c97701

I think this is all you guys, now.

-- 
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/20140903/9945a7de/attachment.html>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #7 from smoki  ---
Created attachment 105676
  --> https://bugs.freedesktop.org/attachment.cgi?id=105676=edit
segfault

(In reply to comment #5)
>  For me nothing new in dmesg, but there is something very interesting here
> happen. When radeonsi.so is striped this trace segfault for me, if not
> striped it pass fine no segfault, what that can be? Hmm...

 After restart it works but segfault again, wwird... this one tried on a pure
32bit OS.

-- 
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/20140903/50097269/attachment.html>

[Bug 83432] New: r600_query.c:269:r600_emit_query_end: Assertion `ctx->num_pipelinestat_queries > 0' failed [Gallium HUD]

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

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

  Priority: medium
Bug ID: 83432
  Assignee: dri-devel at lists.freedesktop.org
   Summary: r600_query.c:269:r600_emit_query_end: Assertion
`ctx->num_pipelinestat_queries > 0' failed [Gallium
HUD]
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: lil_tux at web.de
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 105675
  --> https://bugs.freedesktop.org/attachment.cgi?id=105675=edit
gdb bt full

r600_query.c:269:r600_emit_query_end: Assertion `ctx->num_pipelinestat_queries
> 0' failed.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7fffead44700 (LWP 30641)]
0x70446979 in _debug_assert_fail (expr=0x7072f078
"ctx->num_pipelinestat_queries > 0", file=0x7072efe8 "r600_query.c",
line=269, 
function=0x7072f210 <__func__.9395> "r600_emit_query_end") at
util/u_debug.c:309
309os_abort();
(gdb) bt
#0  0x70446979 in _debug_assert_fail (expr=0x7072f078
"ctx->num_pipelinestat_queries > 0", file=0x7072efe8 "r600_query.c",
line=269, 
function=0x7072f210 <__func__.9395> "r600_emit_query_end") at
util/u_debug.c:309
#1  0x7054882b in r600_emit_query_end (ctx=0xb5ea700, query=0x3a0cc890)
at r600_query.c:269
#2  0x70549e05 in r600_suspend_nontimer_queries (ctx=0xb5ea700) at
r600_query.c:805
#3  0x705462cf in r600_preflush_suspend_features (ctx=0xb5ea700) at
r600_pipe_common.c:136
#4  0x7056342a in r600_context_gfx_flush (context=0xb5ea700, flags=1,
fence=0x0) at r600_hw_context.c:253
#5  0x70562f2f in r600_need_cs_space (ctx=0xb5ea700, num_dw=16393,
count_draw_in=1 '\001') at r600_hw_context.c:96
#6  0x70596077 in r600_need_gfx_cs_space (ctx=0xb5ea700, num_dw=16,
include_draw_vbo=true) at r600_state_common.c:2396
#7  0x705482fe in r600_emit_query_begin (ctx=0xb5ea700,
query=0x3a0cc890) at r600_query.c:162
#8  0x70549ec4 in r600_resume_nontimer_queries (ctx=0xb5ea700) at
r600_query.c:817
#9  0x70560806 in r600_blitter_end (ctx=0xb5ea700) at r600_blit.c:99
#10 0x7056106c in r600_blit_decompress_color (ctx=0xb5ea700,
rtex=0x3708fb30, first_level=0, last_level=0, first_layer=0, last_layer=0) at
r600_blit.c:316
#11 0x705612ff in r600_decompress_subresource (ctx=0xb5ea700,
tex=0x3708fb30, level=0, first_layer=0, last_layer=0) at r600_blit.c:381
#12 0x7056276c in r600_blit (ctx=0xb5ea700, info=0x7fffead43800) at
r600_blit.c:812
#13 0x70284aff in st_BlitFramebuffer (ctx=0x7fffe2c61010, srcX0=0,
srcY0=0, srcX1=482, srcY1=272, dstX0=0, dstY0=272, dstX1=482, dstY1=0,
mask=16384, filter=9728)
at ../../src/mesa/state_tracker/st_cb_blit.c:263
#14 0x7008fec9 in _mesa_BlitFramebuffer (srcX0=0, srcY0=0, srcX1=482,
srcY1=272, dstX0=0, dstY0=272, dstX1=482, dstY1=0, mask=16384, filter=9728) at
../../src/mesa/main/blit.c:509
[..]
(gdb) p ctx.num_pipelinestat_queries 
$3 = 0

Looks like resume_nontimer_queries/emit_query_begin is recursing into
suspend_nontimer_queries/emit_query_end


Was running on HD6850 `OpenGL version string: 3.0 Mesa 10.4.0-devel
(git-2adf7ee)'
With
GALLIUM_HUD="fps,draw-calls;samples-passed+primitives-generated;ia-vertices+ia-primitives;vs-invocations+ps-invocations+hs-invocations+ds-invocations;VRAM-usage+GTT-usage"
R600_DEBUG=hyperz. Though, I assume GALLIUM_HUD="fps" could be enough.

-- 
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/20140903/8515b7cc/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #126 from darkbasic  ---
(In reply to comment #124)
> I can very quickly, almost deterministically, hang the GPU (radeonsi, Cape
> Verde) with the following command:
> 
> > LIBGL_ALWAYS_SOFTWARE=1 mpv --fs --vo=opengl:sw /path/to/some_video

I'm sorry but I can't reproduce it with Tahiti (HD7950).

-- 
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/20140903/2d70624f/attachment-0001.html>

[PATCH v3 16/17] drm/exynos/ipp: remove file argument from node related functions

[Joonyoung Shim]

On 09/02/2014 09:55 PM, Andrzej Hajda wrote:
> Since file pointer is preserved in c_node passing it
> as argument in node functions is redundant.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v3:
> - file check moved to next patch
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 

About both patch 16 and 17

Reviewed-by: Joonyoung Shim 

Thanks.

> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 05f0f4e..9e9714a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
>  
>  static struct drm_exynos_ipp_mem_node
>   *ipp_get_mem_node(struct drm_device *drm_dev,
> - struct drm_file *file,
>   struct drm_exynos_ipp_cmd_node *c_node,
>   struct drm_exynos_ipp_queue_buf *qbuf)
>  {
> @@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
>   dma_addr_t *addr;
>  
>   addr = exynos_drm_gem_get_dma_addr(drm_dev,
> - qbuf->handle[i], file);
> + qbuf->handle[i], c_node->filp);
>   if (IS_ERR(addr)) {
>   DRM_ERROR("failed to get addr.\n");
>   ipp_put_mem_node(drm_dev, c_node, m_node);
> @@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event 
> *event)
>  }
>  
>  static int ipp_get_event(struct drm_device *drm_dev,
> - struct drm_file *file,
>   struct drm_exynos_ipp_cmd_node *c_node,
>   struct drm_exynos_ipp_queue_buf *qbuf)
>  {
> @@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
>   e = kzalloc(sizeof(*e), GFP_KERNEL);
>   if (!e) {
>   spin_lock_irqsave(_dev->event_lock, flags);
> - file->event_space += sizeof(e->event);
> + c_node->filp->event_space += sizeof(e->event);
>   spin_unlock_irqrestore(_dev->event_lock, flags);
>   return -ENOMEM;
>   }
> @@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
>   e->event.prop_id = qbuf->prop_id;
>   e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
>   e->base.event = >event.base;
> - e->base.file_priv = file;
> + e->base.file_priv = c_node->filp;
>   e->base.destroy = ipp_free_event;
>   mutex_lock(_node->event_lock);
>   list_add_tail(>base.link, _node->event_list);
> @@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
> void *data,
>   switch (qbuf->buf_type) {
>   case IPP_BUF_ENQUEUE:
>   /* get memory node */
> - m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
> + m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
>   if (IS_ERR(m_node)) {
>   DRM_ERROR("failed to get m_node.\n");
>   return PTR_ERR(m_node);
> @@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
> void *data,
>*/
>   if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) {
>   /* get event for destination buffer */
> - ret = ipp_get_event(drm_dev, file, c_node, qbuf);
> + ret = ipp_get_event(drm_dev, c_node, qbuf);
>   if (ret) {
>   DRM_ERROR("failed to get event.\n");
>   goto err_clean_node;
> 

[PATCH 1/2] drm/edid: Reduce horizontal timings for pixel replicated modes

[Daniel Vetter]

On Tue, Sep 02, 2014 at 05:03:35PM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor 
> 
> Pixel replicated modes should be non-2x horizontal timings and pixel
> replicated by the HW across the HDMI cable at 2X pixel clock. Current
> horizontal resolution of 1440 does not allow pixel duplication to
> occur and scaling artifacts occur on the TV. HDMI certification
> 7-26 currently fails for all pixel replicated modes. This change will
> allow HDMI certification with 480i/576i modes once pixel replication
> is turned on.
> 
> Signed-off-by: Clint Taylor 
> Cc: Daniel Vetter 
> Cc: Ville Syrj?l? 
> Reviewed-by: Ville Syrj?l? 

Patch is missing the per-patch revision log and the cover letter also
doesn't have anything. Please remember to add that the next time around.

Anyway, patches merged to topic/core-stuff to make sure they don't get
lost.

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_edid.c |   96 
> ++--
>  1 file changed, 48 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index daf3cd8..1bdbfd0 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -632,27 +632,27 @@ static const struct drm_display_mode edid_cea_modes[] = 
> {
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>   DRM_MODE_FLAG_INTERLACE),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> - /* 6 - 1440x480i at 60Hz */
> - { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> -1602, 1716, 0, 480, 488, 494, 525, 0,
> + /* 6 - 720(1440)x480i at 60Hz */
> + { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> +801, 858, 0, 480, 488, 494, 525, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
>   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> - /* 7 - 1440x480i at 60Hz */
> - { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> -1602, 1716, 0, 480, 488, 494, 525, 0,
> + /* 7 - 720(1440)x480i at 60Hz */
> + { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> +801, 858, 0, 480, 488, 494, 525, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
>   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> - /* 8 - 1440x240 at 60Hz */
> - { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> -1602, 1716, 0, 240, 244, 247, 262, 0,
> + /* 8 - 720(1440)x240 at 60Hz */
> + { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> +801, 858, 0, 240, 244, 247, 262, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
>   DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> - /* 9 - 1440x240 at 60Hz */
> - { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> -1602, 1716, 0, 240, 244, 247, 262, 0,
> + /* 9 - 720(1440)x240 at 60Hz */
> + { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> +801, 858, 0, 240, 244, 247, 262, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
>   DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> @@ -714,27 +714,27 @@ static const struct drm_display_mode edid_cea_modes[] = 
> {
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>   DRM_MODE_FLAG_INTERLACE),
> .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> - /* 21 - 1440x576i at 50Hz */
> - { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
> -1590, 1728, 0, 576, 580, 586, 625, 0,
> + /* 21 - 720(1440)x576i at 50Hz */
> + { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
> +795, 864, 0, 576, 580, 586, 625, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
>   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> - /* 22 - 1440x576i at 50Hz */
> - { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
> -1590, 1728, 0, 576, 580, 586, 625, 0,
> + /* 22 - 720(1440)x576i at 50Hz */
> + { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
> +795, 864, 0, 576, 580, 586, 625, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
>   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> 

[PATCH] drm/i915: init sprites with univeral plane init function

[Gustavo Padovan]

From: Derek Foreman 

Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.

Signed-off-by: Derek Foreman 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_sprite.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0bdb00b..4cbe286 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe 
pipe, int plane)
intel_plane->plane = plane;
intel_plane->rotation = BIT(DRM_ROTATE_0);
possible_crtcs = (1 << pipe);
-   ret = drm_plane_init(dev, _plane->base, possible_crtcs,
-_plane_funcs,
-plane_formats, num_plane_formats,
-false);
+   ret = drm_universal_plane_init(dev, _plane->base, possible_crtcs,
+  _plane_funcs,
+  plane_formats, num_plane_formats,
+  DRM_PLANE_TYPE_OVERLAY);
if (ret) {
kfree(intel_plane);
goto out;
-- 
1.9.3

[Intel-gfx] [PATCH -v2 1/4] drm/i915: init sprites with univeral plane init function

[Daniel Vetter]

On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrj?l? wrote:
> On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
> > From: Derek Foreman 
> > 
> > Really just for completeness - old init function ends up making the plane
> > exactly the same way due to the way the enums are set up.
> > 
> > Signed-off-by: Derek Foreman 
> 
> Reviewed-by: Ville Syrj?l? 

Queued for -next, thanks for the patch. And patch 2 is already merged from
the previous round.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [PATCH -v2 1/4] drm/i915: init sprites with univeral plane init function

[Daniel Vetter]

On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrj?l? wrote:
> On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
> > From: Derek Foreman 
> > 
> > Really just for completeness - old init function ends up making the plane
> > exactly the same way due to the way the enums are set up.
> > 
> > Signed-off-by: Derek Foreman 
> 
> Reviewed-by: Ville Syrj?l? 

Queued for -next, thanks for the patch.
-Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_sprite.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 0bdb00b..4cbe286 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe 
> > pipe, int plane)
> > intel_plane->plane = plane;
> > intel_plane->rotation = BIT(DRM_ROTATE_0);
> > possible_crtcs = (1 << pipe);
> > -   ret = drm_plane_init(dev, _plane->base, possible_crtcs,
> > -_plane_funcs,
> > -plane_formats, num_plane_formats,
> > -false);
> > +   ret = drm_universal_plane_init(dev, _plane->base, possible_crtcs,
> > +  _plane_funcs,
> > +  plane_formats, num_plane_formats,
> > +  DRM_PLANE_TYPE_OVERLAY);
> > if (ret) {
> > kfree(intel_plane);
> > goto out;
> > -- 
> > 1.9.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 73785] [HyperZ] Team Fortress 2 causes random GPU stalls on radeonsi

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

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

--- Comment #8 from Marek Ol??k  ---
I don't see any hang here.

-- 
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/20140903/6c8c0576/attachment.html>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #6 from Laurent carlier  ---
Just to note that this trace is produced with apitrace 5.0 and with the
following commandline:
GALLIUM_HUD=num-bytes-moved apitrace32 trace %command%

-- 
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/20140903/7fa90a2b/attachment.html>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #5 from smoki  ---
(In reply to comment #2)
> I get no lockup either, but I do see the same GPUVM protection faults:
> 
>  radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0FF00819
> 
> The FF bits make me suspect bits 32-4x of the GPUVM address are getting
> clobbered, maybe because of the LLVM backend generating invalid shader code.

 For me nothing new in dmesg, but there is something very interesting here
happen. When radeonsi.so is striped this trace segfault for me, if not striped
it pass fine no segfault, what that can be? Hmm...

-- 
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/20140903/c6551c07/attachment.html>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #4 from Laurent carlier  ---
Link to the trace in google drive:
https://drive.google.com/file/d/0B1WCo3k21FK3dTZmaFFmU2wwQzQ/edit?usp=sharing

-- 
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/20140903/ad71a7ba/attachment.html>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #3 from Laurent carlier  ---
Created attachment 105674
  --> https://bugs.freedesktop.org/attachment.cgi?id=105674=edit
ouput of 'R600_DEBUG=ps,vs glretrace Sam3.trace'

LLVM is 3.6svn r216889

-- 
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/20140903/94e1ea22/attachment.html>

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #54 from Michel D?nzer  ---
(In reply to comment #53)
> > Just updated llvm and my perf on pyrit is back to normal -
[...]
> Not llvm it's mesa -
> 
> radeonsi: Compile dummy pixel shader on demand

Sounds like pyrit ends up creating a lot of Gallium contexts. You might get
even better performance with the LLVM regression fixed.

-- 
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/20140903/ab4db9ee/attachment.html>

[Bug 83422] i was opening systemsettings, chose workspace design and the default look and feel screen just stays black when resizing the window or chosing another option on the left panel, it crashes

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

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

--- Comment #5 from Michel D?nzer  ---
Does it also happen with

 Option "AccelMethod" "glamor"

in /etc/X11/xorg.conf? If yes, can you try a newer version of Mesa?

-- 
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/20140903/def440a1/attachment-0001.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

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

Bug 75112 depends on bug 74863, which changed state.

Bug 74863 Summary: [r600g] HyperZ broken on RV770 and CYPRESS (Left 4 Dead 2 
trees corruption) bisected!
https://bugs.freedesktop.org/show_bug.cgi?id=74863

   What|Removed |Added

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

-- 
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/20140903/dbab49c5/attachment.html>

[Bug 74863] [r600g] HyperZ broken on RV770 and CYPRESS (Left 4 Dead 2 trees corruption) bisected!

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

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

Marek Ol??k  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Ol??k  ---
Fixed by 8abdc3c4a9c81e359d5dc1694253b05dd5562c95. 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/20140903/3206ce6f/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #125 from Christian K?nig  ---
(In reply to comment #124)
> I can very quickly, almost deterministically, hang the GPU (radeonsi, Cape
> Verde) with the following command:
> 
> > LIBGL_ALWAYS_SOFTWARE=1 mpv --fs --vo=opengl:sw /path/to/some_video
> 
> this works on both 3.16.0 and 3.17rc3. Try seeking, it often happens
> directly after a seek. In most cases, the hang is unrecoverable and crashes
> the kernel after some "atombios stuck in a loop" messages. Very strange
> indeed, software rendered glxgears doesn't cause this.
> 
> Can anyone verify? A somewhat reliable test case might be a good start to
> finally fixing this.

Well this is interesting, so you're saying that using software rendering on the
client side can crash the GPU? That only leaves glamor and maybe the compositor
as the only one using the hardware driver.

-- 
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/20140903/ce35948e/attachment.html>

[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start

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

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

--- Comment #2 from Michel D?nzer  ---
I get no lockup either, but I do see the same GPUVM protection faults:

 radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0FF00819

The FF bits make me suspect bits 32-4x of the GPUVM address are getting
clobbered, maybe because of the LLVM backend generating invalid shader 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/20140903/0f98d235/attachment.html>

[Bug 74784] [hyperz] Strange artifacts when rendering trees in Dota 2

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

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

Bruno Jim?nez  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Bruno Jim?nez  ---
Hi,

I have just tried with 'R600_DEBUG=hyperz' to enable hyperz with mesa built
from yesterday master.

I have played a match with a hero that used to cause failures with some of his
abilities, but as far as I can tell, there has been no problem.

So it seems that this bug has been resolved (^_^)

If you need anything else just ask.

Thanks!

-- 
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/20140903/cacae5f4/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

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

Bug 75112 depends on bug 74784, which changed state.

Bug 74784 Summary: [hyperz] Strange artifacts when rendering trees in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=74784

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

-- 
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/20140903/295ae326/attachment.html>

[Bug 83418] EU IV is incorrectly rendered after git1409011930.d571f2

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

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

--- Comment #2 from Jos? Su?rez  ---
The last good known version is d571f2, and the first known bad version is
9f2050. 

I will try to narrow that a bit but, aAs stated, it is a bit difficult for me
to bisect. I am using oibaf's ppa which I can recompile myself in a chroot
environment. However, since I am not used to working with git I presume it will
be a bit tricky for me to obtain the diffs to be applied.

I know this is noob, but is there a way to obtain a diff between version from
http://cgit.freedesktop.org/mesa/mesa without having to clone the git repo?
That would surely help me identify the offending commit...

-- 
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/20140903/d5641c2f/attachment.html>

[PATCH/RESEND 0/8] tilcdc-panel: Backlight and GPIO devicetree support

[Johannes Pointner]

2014-09-02 14:51 GMT+02:00 Ezequiel Garcia :
> Dave,
>
> I'm resending this, hoping it can be pushed for v3.18. The patchset was
> ready for v3.17, but it got no maintainer feedback or review. Maybe it fell
> through some crack?
>
> Just for reference, here goes the details about this series and why it's
> needed:
>
> This patchset adds the required changes to support an optional backlight
> and GPIO for the tilcdc panel driver.
>
> There was some code to support a backlight, but it was broken and 
> undocumented.
> I've followed the nice implementation in panel-simple and added a similar
> one here.
>
> The enable GPIO is required to turn on and off devices with such capability.
> Also here, I've followed panel-simple which looks correct.
>
> In addition to this there are very minor cosmetic cleanups and a larger
> fix for the error path in tilcdc's DRM driver .load error path.
>

I tested the series with 3.16.1 (with additonal patches from Guido and
Sachin) and with 3.17-rc3 with a custom AM335x board and it worked for
me without an issue. I tried it with and without the backlight
addition in the dts file.

For the series:
Tested-by: Johannes Pointner 

> Ezequiel Garcia (8):
>   drm/tilcdc: Fix the error path in tilcdc_load()
>   drm/tilcdc: panel: Add missing of_node_put
>   drm/tilcdc: panel: Remove unused variable
>   drm/tilcdc: panel: Spurious whitespace removal
>   drm/tilcdc: panel: Use devm_kzalloc to simplify the error path
>   drm/tilcdc: panel: Fix backlight devicetree support
>   drm/tilcdc: panel: Set return value explicitly
>   drm/tilcdc: panel: Add support for enable GPIO
>
>  .../devicetree/bindings/drm/tilcdc/panel.txt   |  7 ++
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 60 +++---
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 74 
> +-
>  3 files changed, 114 insertions(+), 27 deletions(-)
>
> --
> 2.0.1
>

[PATCH/RESEND 0/8] tilcdc-panel: Backlight and GPIO devicetree support

[Ezequiel Garcia]

On 3 September 2014 03:08, Johannes Pointner
 wrote:
[..]
>
> I tested the series with 3.16.1 (with additonal patches from Guido and
> Sachin) and with 3.17-rc3 with a custom AM335x board and it worked for
> me without an issue. I tried it with and without the backlight
> addition in the dts file.
>
> For the series:
> Tested-by: Johannes Pointner 
>

Thanks a lot for the test,
-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar

[Bug 83422] i was opening systemsettings, chose workspace design and the default look and feel screen just stays black when resizing the window or chosing another option on the left panel, it crashes

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

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

--- Comment #4 from simon  ---
Created attachment 105662
  --> https://bugs.freedesktop.org/attachment.cgi?id=105662=edit
dmesg

-- 
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/20140903/2b6dafe7/attachment.html>

[Bug 83422] i was opening systemsettings, chose workspace design and the default look and feel screen just stays black when resizing the window or chosing another option on the left panel, it crashes

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

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

--- Comment #3 from simon  ---
Created attachment 105661
  --> https://bugs.freedesktop.org/attachment.cgi?id=105661=edit
glxinfo

-- 
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/20140903/a8076369/attachment.html>

[Bug 83422] i was opening systemsettings, chose workspace design and the default look and feel screen just stays black when resizing the window or chosing another option on the left panel, it crashes

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

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

--- Comment #2 from simon  ---
Created attachment 105660
  --> https://bugs.freedesktop.org/attachment.cgi?id=105660=edit
xorg.0.log

-- 
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/20140903/040586fa/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #76 from Aaron B  ---
Ah, okay. Yeah, dropped to LLVM 3.4 and we're good to go. I'll report any
results I find interesting or believe may be problematic soon, along with my
bisect paths. I have 4 days off, so I'll probably be posting here a lot if I
get anything. Also helps I'm currently working on getting my projects to a
publishable state so I'll be in the programming-debugging mood to boot.

-- 
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/20140903/497bff20/attachment-0001.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #75 from Michel D?nzer  ---
(In reply to comment #72)
> Yeah, but I build it with yaourt, which likes to contain it's gits elsewhere
> and apparently deletes them every time as you can't keep a clone unless it's
> in the same session.

Sounds like a severe yaourt limitation, but maybe you can convince it to clone
an existing local repository instead of a remote one?


> And running glretrace about 10 times on the trace files, no beans on getting
> another crash.

Then those trace files won't help others reproduce the problem either
unfortunately, let alone fix it.

-- 
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/20140903/9cc36c2c/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #74 from Michel D?nzer  ---
(In reply to comment #73)
> Could it be I'm using LLVM 3.6 [...]

Yes, only released versions of LLVM can be supported by released versions of
Mesa. Even LLVM 3.5 is only being released now, so you might need LLVM 3.4(.y)
for Mesa 10.1.

-- 
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/20140903/74e224a6/attachment.html>