On Tue, May 7, 2013 at 4:44 AM, Christian König wrote:
>
> The patch shouldn't be necessary because just removing the firmware should
> have pretty much the same effect.
Soon distros will ship the UVD firmware by default and then users will
need to manually remove it and then do the same with ev
This reduces the size of the stack frame when calling request_module().
Performing the sprintf before the call is not needed.
Signed-off-by: Kees Cook
---
drivers/gpu/drm/drm_encoder_slave.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_s
On Tue, May 7, 2013 at 7:08 AM, Alex Deucher wrote:
> On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski wrote:
>> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote:
>>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote:
On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski
wrote:
Hi Wei Yongjun,
On 7 May 2013 18:54, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> ipp_create_cmd_work() return ERR_PTR() on error and never return
> NULL, so use IS_ERR() instead
From: Wei Yongjun
Fix to return -ENOMEM in the exynos_plane_init() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
ipp_create_cmd_work() return ERR_PTR() on error and never return
NULL, so use IS_ERR() instead of IS_ERR_OR_NULL().
Signed-off-by: Wei Yongjun
---
drivers/gpu/dr
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/cdbe96c6/attachment.html>
From: Wei Yongjun
Fix to return -ENOMEM in the exynos_plane_init() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
ipp_create_cmd_work() return ERR_PTR() on error and never return
NULL, so use IS_ERR() instead of IS_ERR_OR_NULL().
Signed-off-by: Wei Yongjun
---
drivers/gpu/dr
ves/dri-devel/attachments/20130507/ab1e70bf/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130507/606c96ff/attachment.html>
Hi Wei Yongjun,
On 7 May 2013 18:54, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> ipp_create_cmd_work() return ERR_PTR() on error and never return
> NULL, so use IS_ERR() instead
you ever bump into 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/20130507/2b284d2b/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #13 from Erdem U. Altinyurt ---
Oops! LLVM 3.3 is branched today.
I wish this bug vanished from LLVM before release of v3.3 in June
Updated today's mesa and llvm-trunks...
Without "-v1" flag, "bfgminer --benchmark" reports:
[2013-05
On Tue, May 7, 2013 at 4:44 AM, Christian K?nig
wrote:
>
> The patch shouldn't be necessary because just removing the firmware should
> have pretty much the same effect.
Soon distros will ship the UVD firmware by default and then users will
need to manually remove it and then do the same with e
Hi Daniel,
On Tue, 7 May 2013 10:43:17 +0200 Daniel Vetter wrote:
>
> On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell
> wrote:
> >
> > Daniel, I assume all this stuff being added to the drm-intel tree is
> > going upstream very soon?
>
> Oops, no that is stuff for 3.11. Lazy me hoped I could
--
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/20130507/17b50108/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=56659
--- Comment #6 from runetmem...@gmail.com ---
Isn't 7.1.0 is latest version of the driver? http://www.x.org/wiki/radeon
If you talking about Mesa - sure, I already tried Mesa 9.1.1 and 9.2-git.
--
You are receiving this mail because:
You are the
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130507/1c28de12/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/1e3920e5/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/c78c5773/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/9ad65253/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/debafa15/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=63979
Jerome Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=56659
--- Comment #5 from Jerome Glisse ---
7.10 is old please try with at least 9.1
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=62466
--- Comment #10 from Jerome Glisse ---
Patch was against mesa, but patch is now included in mesa except in mesa 9.1
branch, i will push something shortly.
If you want to make a donation make one to EFF https://www.eff.org/
Or buy me a beer if y
>>
>> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
>> cover it with a write combine MTRR. The whole ioctl is use by some ddx
>> or maybe even directly the XServer to do this mtrr mess in userspace.
>
> Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to
>
This reduces the size of the stack frame when calling request_module().
Performing the sprintf before the call is not needed.
Signed-off-by: Kees Cook
---
drivers/gpu/drm/drm_encoder_slave.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_s
ontrol */
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/6d4211ee/attachment.pgp>
Am 07.05.2013 09:02, schrieb Michel D?nzer:
> On Mon, 2013-05-06 at 19:11 -0400, Parag Warudkar wrote:
>> Apparently UVD doesn't yet work everywhere - so allow it to be
>> disabled. Shaves off some reboot and suspend/resume time on machines
>> where it doesn't work. Might be useful for problematic
On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell
wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
> Make data/link N value power of two") from Linus' tree and commit
> e3b95f1eb5b9 ("drm
On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski wrote:
> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote:
>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski
>> wrote:
>>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski
>>> wrote:
Signed-off-by: Andy Lutomirski
---
Thi
On Tue, May 7, 2013 at 7:08 AM, Alex Deucher wrote:
> On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski
> wrote:
>> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote:
>>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski
>>> wrote:
On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski
wro
https://bugs.freedesktop.org/show_bug.cgi?id=62889
--- Comment #22 from Michel Dänzer ---
(In reply to comment #21)
> Yup. Did the same process for the 32-bit drivers. Same result.
Works For Me™... Did you verify with LIBGL_DEBUG=verbose that it's picking up
the right radeonsi_dri.so?
--
You a
On Mon, 2013-05-06 at 19:11 -0400, Parag Warudkar wrote:
> Apparently UVD doesn't yet work everywhere - so allow it to be
> disabled. Shaves off some reboot and suspend/resume time on machines
> where it doesn't work. Might be useful for problematic chips in the
> future as well.
>
> Patch attache
>>> One that appears the same as a GEM object created by userspace. i.e. mmap
>>> works.
>>
>> Oh, we have an mmap interface in the dma_buf thing for that, and iirc
>> Rob Clark even bothered to implement the gem->dma_buf mmap forwarding
>> somewhere. And iirc android's ion-on-dma_buf stuff is eve
https://bugs.freedesktop.org/show_bug.cgi?id=64320
Alex Deucher changed:
What|Removed |Added
Summary|WebGL support in Chrome |WebGL support in Chrome
https://bugs.freedesktop.org/show_bug.cgi?id=64320
--- Comment #3 from Marc Dietrich ---
I don't see Kwin corruptions as reported in bug 64257. Also this bug says
nothing about GPU lockups. But what I also see is a "dark glxgears" effect.
It's kinda hard to bisect this because r600 now depends o
https://bugs.freedesktop.org/show_bug.cgi?id=64320
--- Comment #2 from Alex Deucher ---
It was noted on IRC that the lockups only happen with llvm. This is probably a
duplicate of bug 64257.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=64320
--- Comment #1 from Alex Deucher ---
Is this a regression? If so, can you bisect? Please attach your xorg log and
dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.
On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski wrote:
> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote:
>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote:
>>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote:
Signed-off-by: Andy Lutomirski
---
This needs c
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/7167868e/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64320
Priority: medium
Bug ID: 64320
Assignee: dri-devel@lists.freedesktop.org
Summary: WebGL support in Chrome causes GPU lockup
Severity: normal
Classification: Unclassified
OS:
On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter wrote:
> On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote:
>> >>
>> >> However if we don't set a dma mask on the usb device, the mapping
>> >> ends up using swiotlb on machines that have it enabled, which
>> >> is less than desireable.
>> >>
Am 07.05.2013 09:02, schrieb Michel Dänzer:
On Mon, 2013-05-06 at 19:11 -0400, Parag Warudkar wrote:
Apparently UVD doesn't yet work everywhere - so allow it to be
disabled. Shaves off some reboot and suspend/resume time on machines
where it doesn't work. Might be useful for problematic chips in
On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
> Make data/link N value power of two") from Linus' tree and commit
> e3b95f1eb5b9 ("drm/
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #5 from Mike Lothian ---
I'm afraid it doesn't fix it - I'm going to be out of the country for a week
now - I'll bisect it when I get back if it still isn't working
--
You are receiving this mail because:
You are the assignee for th
On Mon, 2013-05-06 at 19:11 -0400, Parag Warudkar wrote:
> Apparently UVD doesn't yet work everywhere - so allow it to be
> disabled. Shaves off some reboot and suspend/resume time on machines
> where it doesn't work. Might be useful for problematic chips in the
> future as well.
>
> Patch attache
48 matches
Mail list logo
