2013/5/15 Rob Clark
> On Wed, May 15, 2013 at 1:19 AM, Inki Dae wrote:
> >
> >
> >> -Original Message-
> >> From: Rob Clark [mailto:robdcl...@gmail.com]
> >> Sent: Tuesday, May 14, 2013 10:39 PM
> >> To: Inki Dae
> >> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJ
--
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/20130517/214f824d/attachment.html>
On Fri, 17 May 2013 19:00:29 +0100
Russell King - ARM Linux wrote:
> > Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> > transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
> > case. And, yes, I better like a hardware cursor: it asks for less
> > computati
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/81bcb7b9/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/70303fe3/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/20130517/2566065a/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #19 from romula...@gmail.com ---
Is this patch upsteam in git?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedeskt
On Fri, 17 May 2013 13:01:15 +0100
Russell King - ARM Linux wrote:
> I already said - I don't support DT. I don't run any DT based ARM
> devices, so I have no experience with DT. What I care more about
> is a working cubox platform, which afaik DT still can't offer yet.
I like the DT concept.
https://bugs.freedesktop.org/show_bug.cgi?id=64443
--- Comment #6 from romula...@gmail.com ---
(In reply to comment #3)
> But that's still several months out, and you probably don't want to wait
> that long. In the meantime, you can do:
> export MESA_GL_VERSION_OVERRIDE=3.2
> export MESA_GLSL_VER
https://bugs.freedesktop.org/show_bug.cgi?id=64443
--- Comment #5 from romula...@gmail.com ---
(In reply to comment #3)
> But that's still several months out, and you probably don't want to wait
> that long. In the meantime, you can do:
> export MESA_GL_VERSION_OVERRIDE=3.2
> export MESA_GLSL_VER
0 (without glamour)
any ideas or patches to test?
--
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/20130517/63f1ab4b/attachment.html>
On Fri, May 17, 2013 at 07:00:29PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> > Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> > transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
> > cas
On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> On Fri, 17 May 2013 13:01:15 +0100
> Russell King - ARM Linux wrote:
> > > - CMA helper
> > >
> > > You don't use DRM_KMS_CMA_HELPER and DRM_GEM_CMA_HELPER which would
> > > simplify some code.
> >
> > Possibly, but the
MDGPU
back-end again.
--
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/20130517/21e1cb5a/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/93132689/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/87701ee3/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/94f61e6e/attachment.html>
g.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/1efd6c3b/attachment.html>
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Change function exynos_plane_init() to return ERR_PTR(), so
the caller can use the error code from it.
Signed-off-by: Wei Yongjun
---
v1 -> v2: change exynos_plan
Hallo,
I hope this is the right place to ask, because I actually don't know
whether it is a bug or a feature that I'm experiencing since linux 3.9:
When I boot my system the backlight gets extremely bright compared to older
kernel versions. It is most obvious when I leave X (more a yellow than a
b
Add syncpoint increment to return a proper return code based on the
return value from host1x.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/drm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index
This patch merges host1x_syncpt_cpu_incr to host1x_syncpt_incr() as
they are in practise doing the same thing. host1x_syncpt_incr() is also
modified to return error codes.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/dev.h |8
drivers/gpu/host1x/hw/cdma_hw.c |
client_managed field in syncpoint structure was defined as an
integer. The field holds, however, only a boolean value. This patch
modifies the type to boolean.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/gr2d.c |2 +-
drivers/gpu/host1x/syncpt.c |8
drivers/gpu/h
This patch fixes a bad memory access in syncpoint request code. If
no syncpoints were available, the code accessed unreserved memory
area causing unexpected behaviour.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/syncpt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
Syncpoint wait returned EAGAIN if it was called with zero timeout.
This patch modifies the function to return ETIMEDOUT.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/syncpt.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers
From: Terje Bergstrom
This patch adds several fixes to host1x firewall:
- Host1x firewall does not survive if it expects a reloc, but user
space didn't pass any relocs. Also it reset the reloc table for
each gather, whereas they should be reset only per submit. Also
class does not need to b
This patch series fixes two issues in the host1x driver: First, the
command buffer validation routine had vulnerabilities that were not
detected in earlier testing. Second, the return codes of some
functions were misleading or completely missing. This caused the
driver to give wrong return codes al
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #7 from wojtek ---
short summary (Alex suggestions on IRC):
remove r600g_dri.so -> NOT OK
"ColorTiling2D" "false" -> NOT OK
kernel-3.10-rc1 -> NOT OK
"NoAccel" "true" -> OK
--
You are receiving this mail because:
You are the assig
On 05/17/13 13:33, Jean-Francois Moine wrote:
> On Thu, 16 May 2013 20:25:10 +0100
> Russell King - ARM Linux wrote:
>> What follows is my DRM driver for Dove, which I've been working on with
>> the Solid-run Cubox, which only offers HDMI output via the TDA19988
>> chip.
...
> - device tree
>
>
On Thu, 16 May 2013 20:25:10 +0100
Russell King - ARM Linux wrote:
> What follows is my DRM driver for Dove, which I've been working on with
> the Solid-run Cubox, which only offers HDMI output via the TDA19988
> chip.
>
> Not everything is finished off perfectly in this driver; there's quite
>
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #6 from wojtek ---
This is the first linux installation on that machine. I cannot confirm if this
is regression.
First time when I installed Arch linux kernel version was 3.7 and GPU lockup
occurred
--
You are receiving this mail b
On Fri, May 17, 2013 at 01:33:45PM +0200, Jean-Francois Moine wrote:
> Hi Russell,
>
> I quickly compared your dove drm driver and ours (Sebastian and me):
I already said - I don't support DT. I don't run any DT based ARM
devices, so I have no experience with DT. What I care more about
is a wor
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #5 from Alex Deucher ---
Is this a regression with kernels 3.8, 3.9? I.e., did 3.7 work ok?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=63599
Alex Deucher changed:
What|Removed |Added
Attachment #78070|application/octet-stream|text/plain
mime type|
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/6176d67c/attachment-0001.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/ee4f5971/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/e0255397/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #4 from wojtek ---
I've just installed Gentoo. Issue still exists.
radeon-ucode-20130513
mesa-9.2-20130515 (without llvm)
kernel-3.9.2 (UVD disabled because kms with UVD don't work)
libdrm-2.4.44
xf86-video-ati-7.1.0 (without glamour
On Fri, May 17, 2013 at 07:00:29PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> > Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> > transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
> > cas
On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> On Fri, 17 May 2013 13:01:15 +0100
> Russell King - ARM Linux wrote:
> > > - CMA helper
> > >
> > > You don't use DRM_KMS_CMA_HELPER and DRM_GEM_CMA_HELPER which would
> > > simplify some code.
> >
> > Possibly, but the
On Fri, 17 May 2013 13:01:15 +0100
Russell King - ARM Linux wrote:
> I already said - I don't support DT. I don't run any DT based ARM
> devices, so I have no experience with DT. What I care more about
> is a working cubox platform, which afaik DT still can't offer yet.
I like the DT concept.
On Fri, May 17, 2013 at 01:33:45PM +0200, Jean-Francois Moine wrote:
> Hi Russell,
>
> I quickly compared your dove drm driver and ours (Sebastian and me):
I already said - I don't support DT. I don't run any DT based ARM
devices, so I have no experience with DT. What I care more about
is a wor
On 05/17/13 13:33, Jean-Francois Moine wrote:
On Thu, 16 May 2013 20:25:10 +0100
Russell King - ARM Linux wrote:
What follows is my DRM driver for Dove, which I've been working on with
the Solid-run Cubox, which only offers HDMI output via the TDA19988
chip.
...
- device tree
Our driver d
On Thu, 16 May 2013 20:25:10 +0100
Russell King - ARM Linux wrote:
> What follows is my DRM driver for Dove, which I've been working on with
> the Solid-run Cubox, which only offers HDMI output via the TDA19988
> chip.
>
> Not everything is finished off perfectly in this driver; there's quite
>
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Change function exynos_plane_init() to return ERR_PTR(), so
the caller can use the error code from it.
Signed-off-by: Wei Yongjun
---
v1 -> v2: change exynos_plan
On Fri, May 17, 2013 at 08:38:03AM +0200, Jean-Francois Moine wrote:
> The signals SIGALRM (most often) and SIGPOLL (sometimes) may be raised
> after irq or some parameter change and this aborts the i2c exchanges.
>
> The problem is solved by masking these signals.
NAK. The real problem is in th
The signals SIGALRM (most often) and SIGPOLL (sometimes) may be raised
after irq or some parameter change and this aborts the i2c exchanges.
The problem is solved by masking these signals.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 40
+
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #24 from Aaron Watry ---
I haven't managed to finish bisecting this yet, but I believe that this bug has
been present since at least January 9th, 2013:
mesa: 4f2d9a8f520cda
llvm: 1db9b6957c
clang: 50767d8c8f2f667255bd
libclc was l
g/archives/dri-devel/attachments/20130517/ade4830f/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #32 from Benjamin Lee ---
UVD register dumps attached.
blee@supra ~/tmp $ diff uvdregs-bios.txt uvdregs-efi.txt
4c4
< 0xef0c0x8002 (-2147483646)
---
> 0xef0c0x (0)
16,18c16,18
< 0xf4980x8010 (
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #31 from Benjamin Lee ---
Created attachment 79475
--> https://bugs.freedesktop.org/attachment.cgi?id=79475&action=edit
UVD regs only, EFI
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #30 from Benjamin Lee ---
Created attachment 79474
--> https://bugs.freedesktop.org/attachment.cgi?id=79474&action=edit
UVD regs only, BIOS emulation
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #15 from Pierre Ossman ---
(In reply to comment #14)
>
> FWIW this is my 24Hz line as shown by xrandr --verbose, maybe yours is
> different?
>
> 1920x1080 (0x2cd) 74.2MHz +HSync +VSync
> h: width 1920 start 2558 end 2602
On Fri, May 17, 2013 at 08:38:03AM +0200, Jean-Francois Moine wrote:
> The signals SIGALRM (most often) and SIGPOLL (sometimes) may be raised
> after irq or some parameter change and this aborts the i2c exchanges.
>
> The problem is solved by masking these signals.
NAK. The real problem is in th
ceiving 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/20130517/4da6d5ee/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/e06c05e3/attachment.html>
The signals SIGALRM (most often) and SIGPOLL (sometimes) may be raised
after irq or some parameter change and this aborts the i2c exchanges.
The problem is solved by masking these signals.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 40
+
freedesktop.org/archives/dri-devel/attachments/20130517/34ed2368/attachment-0001.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/6b0e9911/attachment.html>
On Wed, May 15, 2013 at 4:06 PM, Rob Clark wrote:
> So while it seems nice and orthogonal/clean to couple cache and
> synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> same generic way, but I think in practice we have to make things more
> complex than they otherwise need to b
https://bugs.freedesktop.org/show_bug.cgi?id=64695
--- Comment #2 from Alexandre Demers ---
Sorry, I just had time to copy what I had reported in bug 56534. Gnome Shell
ends up with a "Oops". I'll dig in logs to search for more clues.
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=64695
--- Comment #1 from Alex Deucher ---
What do you mean by crash? system hang? segfault?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=56534
--- Comment #8 from Alex Deucher ---
Is this still an issue with mesa from git? There were some recent fixes for
MSAA on cayman.
--
You are receiving this mail because:
You are the assignee for the bug.
This patch merges host1x_syncpt_cpu_incr to host1x_syncpt_incr() as
they are in practise doing the same thing. host1x_syncpt_incr() is also
modified to return error codes.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/dev.h |8
drivers/gpu/host1x/hw/cdma_hw.c |
client_managed field in syncpoint structure was defined as an
integer. The field holds, however, only a boolean value. This patch
modifies the type to boolean.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/gr2d.c |2 +-
drivers/gpu/host1x/syncpt.c |8
drivers/gpu/h
Add syncpoint increment to return a proper return code based on the
return value from host1x.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/drm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index
This patch fixes a bad memory access in syncpoint request code. If
no syncpoints were available, the code accessed unreserved memory
area causing unexpected behaviour.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/syncpt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
Syncpoint wait returned EAGAIN if it was called with zero timeout.
This patch modifies the function to return ETIMEDOUT.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/syncpt.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers
From: Terje Bergstrom
This patch adds several fixes to host1x firewall:
- Host1x firewall does not survive if it expects a reloc, but user
space didn't pass any relocs. Also it reset the reloc table for
each gather, whereas they should be reset only per submit. Also
class does not need to b
This patch series fixes two issues in the host1x driver: First, the
command buffer validation routine had vulnerabilities that were not
detected in earlier testing. Second, the return codes of some
functions were misleading or completely missing. This caused the
driver to give wrong return codes al
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/1d2530ce/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #29 from Dave Witbrodt ---
(In reply to comment #28)
> Actually "radeonreg regs all" won't give you the UVD regs, cause it doesn't
> know about them yet. So could you guys give us a dump of the following regs,
> once with EFI and once
||g/show_bug.cgi?id=56534
--
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/20130517/7b2cf
||g/show_bug.cgi?id=64695
--
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/20130517/36379
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/20130517/601e4705/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/20130517/83e59622/attachment.html>
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/20130517/c91c9b06/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/a1d1530e/attachment.html>
Hi Linus,
Fix for radeon nomodeset regression, old radeon interface cliprects fix, 2
qxl crasher fixes, and a couple of minor cleanups.
I may have a new AMD hw support branch next week, its one of those doesn't
affect anything existing just adds new support, I'll see how it
shapes up and I mi
https://bugs.freedesktop.org/show_bug.cgi?id=64694
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #28 from Christian König ---
My mistake was that I've forgotton to update the initrd, so if you are using
one make sure that it is up to date as well.
Actually "radeonreg regs all" won't give you the UVD regs, cause it doesn't
know a
https://bugs.freedesktop.org/show_bug.cgi?id=64694
Michel Dänzer changed:
What|Removed |Added
CC||deathsim...@vodafone.de
--- Comment #1 f
>
> I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's
> the
> kernel mode setting panic's as well.
>
> In this example, the first one is my fault; but then cirrus framebuffer DRM
> modesetting craps out.
Yeah the fix went to stable today I think
drm: don't check modeset
https://bugs.freedesktop.org/show_bug.cgi?id=64443
--- Comment #4 from Mike Lothian ---
That only working with the i965 driver at the moment
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel
it.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
--
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/20130517/857b7893/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130517/ae89d3ea/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/a89efa26/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/aee5e954/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130517/ebb9700c/attachment.html>
89 matches
Mail list logo
