Hi Krzysztof,
å¨ 08/23/2015 07:43 PM, Krzysztof Kozlowski åé:
> 2015-08-24 8:23 GMT+09:00 Rob Herring :
>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
>>> Analogix dp driver is split from exynos dp driver, so we just
>>> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
On Sat, Aug 22, 2015 at 12:00:21AM +0200, Thomas Hellstrom wrote:
> On 08/21/2015 06:00 PM, Jerome Glisse wrote:
> > On Fri, Aug 21, 2015 at 04:15:53PM +0200, Thomas Hellstrom wrote:
> >> On 08/21/2015 03:32 PM, Jerome Glisse wrote:
> >>> On Fri, Aug 21, 2015 at 07:25:07AM +0200, Thomas Hellstrom
Hi Rob,
å¨ 08/23/2015 06:23 PM, Rob Herring åé:
> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
>> Analogix dp driver is split from exynos dp driver, so we just
>> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
>>
>> Beside update some exynos dtsi file with the latest
with this bug.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/93fd830c/attachment.html>
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
> Analogix dp driver is split from exynos dp driver, so we just
> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
>
> Beside update some exynos dtsi file with the latest change
> according to the devicetree binding documents.
You
[+Tom's other mail address]
On Sun, Aug 23, 2015 at 3:05 PM, Zoltán Gilián
wrote:
> Hi Martin,
>
> The summary of my project:
> http://zogi-gsoc2015.blogspot.hu/2015/08/summary.html
>
> Cheers,
> Zoltan
>
> On Sun, Aug 23, 2015 at 3:04 AM, John Hunter wrote:
>> Hi Martin,
>> Here is my blog
Hi Martin,
The summary of my project: http://zogi-gsoc2015.blogspot.hu/2015/08/summary.html
Cheers,
Zoltan
On Sun, Aug 23, 2015 at 3:04 AM, John Hunter wrote:
> Hi Martin,
> Here is my blog post of my current situation http://zhjwpku.blogspot.com/
>
> Cheers,
> Zhao
>
> On Sat, Aug 22, 2015 at
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/c896fcd9/attachment-0001.html>
.
--
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/20150823/4a01cdcd/attachment.html>
On Wed, Aug 12, 2015 at 08:29:13PM -0300, Tiago Vignatti wrote:
> Userspace is the one in charge of flush CPU by wrapping mmap with
> begin{,end}_cpu_access.
>
> v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix
> return
> before transferring ownership when mmap fails.
>
On Wed, Aug 12, 2015 at 08:29:18PM -0300, Tiago Vignatti wrote:
> A userptr doesn't have the obj->base.filp, but can be exported via dma-buf, so
> make sure it fails when mmaping.
>
> Signed-off-by: Tiago Vignatti
> ---
> In machine, export the handle to fd is actually returning error and
On Wed, Aug 12, 2015 at 08:29:12PM -0300, Tiago Vignatti wrote:
> Signed-off-by: Tiago Vignatti
> ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
On Wed, Aug 12, 2015 at 08:29:17PM -0300, Tiago Vignatti wrote:
> This patch moves userptr definitions and helpers implementation that were
> locally in gem_userptr_benchmark and gem_userptr_blits to the library, so
> other
> tests can make use of them as well. There's no functional changes.
We
t;http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/21361393/attachment.html>
situation. If his is the best solution, I'm certainly happy with that!
--
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/20150
|--- |NOTOURBUG
--
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/20150823/a33b6b20/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/f01cd468/attachment-0001.html>
//lists.freedesktop.org/archives/dri-devel/attachments/20150823/248d8d22/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/fde430de/attachment.html>
used it before this issue arose.
--
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/20150823/36e32df3/attachment.html>
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/20150823/dd2eb224/attachment-0001.html>
any ideas, please let me know.
--
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/20150823/02058882/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/5ed3e3aa/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/229e5f09/attachment.html>
||
--
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/20150823/2090c1af/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/5bf53d66/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/eddfbcb0/attachment.html>
e
>+#endif
> #include "xf86drm.h"
> #include "amdgpu_drm.h"
> #include "amdgpu_internal.h"
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lis
There doesn't seem to be any need to have 'ib' volatile, the code is
not even consistent with it and some places already miss it. As it is
now it's just making gcc produce worse code. If there are special
requirements for that memory, then proper primitives like memory
barriers or accessor
After this patch the register check loop does the same thing as before,
except that now gcc does better job optimizing it: it now sees that
end_reg was already checked against PACKET3_SET_CONTEXT_REG_END and can
optimize REG_SAFE_BM_SIZE comparison out of evergreen_is_safe_reg()
as
evergreen_cs_check_reg() is a large function and gcc doesn't want to
inline it. It has a quick check for reg_safe_bm[] to see if register
needs special handling, which often results in early exit. However
because the function is large, it has a long prologue/epilogue to
save/restore all the
To avoid having to distinguish between CAYMAN or older on every register
check, place a pointer in evergreen_cs_track and use it unconditionally.
Also make use of the fact that both reg_safe_bm[] arrays are of the same
length to remove another CAYMAN check.
Signed-off-by: Grazvydas Ignotas
---
These patches try to reduce CPU usage of register command checker
without affecting functionality.
For me this gives 3-4% perf improvement in glxgears and ~1% CPU usage reduction
in "The Talos Principle" CS thread.
Grazvydas Ignotas (4):
drm/radeon: simplify register checker
drm/radeon: split
Propagate error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
The complate semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@ok exists@
identifier f,ret,i;
expression e;
constant c;
@@
// identify a function that returns a negative return value at least once.
f(...) {
... when any
(
return -c at i;
|
ret = -c at i;
...
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150823/2e91a119/attachment.html>
37 matches
Mail list logo
