https://bugzilla.kernel.org/show_bug.cgi?id=71051
--- Comment #15 from Hin-Tak Leung ---
(In reply to Hin-Tak Leung from comment #14)
...
> To answer my own question, attachment 150801 [details] is in 3.17-rcX, so
> will be in 3.17 proper...
besides v3.17-rc6, it is also in v3.16.4 .
--
You ar
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/68f1105f/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/36c453dc/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/78279e1a/attachment.html>
will try with llvm 3.6 and the lastest git latter.
--
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/20141010/9668745e/attachment-0001.html>
On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding
wrote:
> On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote:
>> Hi Ajay,
>>
>> On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote:
>> > On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote:
>> > > On 20/09/14 14:22, Ajay kumar wrote:
i GPU... I'm puzzled.
--
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/20141010/91e522a2/attachment.html>
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 diff
From: Michel D?nzer
The radeon driver uses placement range restrictions for several reasons,
in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
during a page fault.
Without this change, TTM could evict other BOs while trying to satisfy
the requested placement, even if the ev
Am 10.10.2014 um 18:02 schrieb Alex Deucher:
> On Fri, Oct 10, 2014 at 12:00 PM, Alex Deucher
> wrote:
>> On Thu, Oct 9, 2014 at 3:10 PM, Alexander Fyodorov
>> wrote:
>>> 09.10.2014, 22:32, "Christian K?nig" :
Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
> 09.10.2014, 21:42, "C
On 10.10.2014 17:51, Alan Swanson wrote:
> On Fri, 2014-10-10 at 12:20 +0900, Michel D?nzer wrote:
>> On 09.10.2014 19:22, Alan Swanson wrote:
>>> On 2014-10-09 07:02, Michel D?nzer wrote:
From: Michel D?nzer
The radeon driver uses placement range restrictions for several reasons,
>
lt;http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/ab25c569/attachment.html>
From: Christian K?nig
v1: Flush VRAM cache before each read when polling (r600_dma_ring_test only).
v2 (chk): rebased on current drm-fixes, apply to CIK as well.
Signed-off-by: Alexander Fyodorov
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/cik_sdma.c | 1 +
drivers/gpu/drm/radeo
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/dcfc7fe7/attachment.html>
vel/attachments/20141010/139240f7/attachment.html>
/attachments/20141010/0edbd985/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141010/95cab59d/attachment-0001.html>
On Sat, Oct 11, 2014 at 01:37:56AM +0530, Sumit Semwal wrote:
> Devices sharing buffers using dma-buf could benefit from sharing their
> constraints via struct device, and dma-buf framework would manage the
> common constraints for all attached devices per buffer.
>
> With that information, we cou
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/f669241c/attachment.html>
n issue with pyrit?
Pyrit is OK, so closing this one.
--
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/20141010/789cae47/attachment-0001.html>
On 10/02/2014 12:52 PM, Inki Dae wrote:
> On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
>>> The patch disables vblanks during dpms off only if pagefilp has
>>> not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_p
During system suspend after connector switch off its dpms field
is set to connector previous dpms state. To properly resume dpms field
should be set to its actual state (off) before resuming to previous dpms state.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
Before DPMS off driver disables vblank.
It should be balanced by vblank enable after DPMS on.
The patch fixes issue with page_flip ioctl not being able
to acquire vblank counter introduced by patch:
drm: Always reject drm_vblank_get() after drm_vblank_off()
Signed-off-by: Andrzej Hajda
---
drive
HPD events can be generated by components even if drm_dev is not fully
initialized, to skip such events kms poll initialization should
be performed at the end of load callback followed directly by forced
connection detection.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv
In case of error during plane initialization load callback
incorrectly return success, this patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
Hi Inki,
These four independent patches fixes few problems I have encountered recently.
1st patch is a trivial fix.
2nd patch(kms poll init) fixes old issue, which became more visible after my
patch
'drm/exynos: init vblank with real number of crtcs' - driver tried to handle HPD
events even if
org/archives/dri-devel/attachments/20141010/f43bf02e/attachment.html>
desktop.org/archives/dri-devel/attachments/20141010/7646e09c/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141010/a0d8dd0d/attachment.html>
Connector type id is allocated using ida_simple_get, its counterpart
is ida_simple_remove, so we should use it instead of ida_remove.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/drm_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/
From: Michel D?nzer
This avoids them getting in the way of BOs which might be accessed by
the CPU. They can still go to the CPU accessible part of VRAM though if
there's no space outside of it.
Signed-off-by: Michel D?nzer
---
v2: Bump size of struct radeon_bo placements array.
drivers/gpu/d
On 09.10.2014 19:22, Alan Swanson wrote:
> On 2014-10-09 07:02, Michel D?nzer wrote:
>> From: Michel D?nzer
>>
>> The radeon driver uses placement range restrictions for several reasons,
>> in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
>> during a page fault.
>>
>> Withou
https://bugzilla.kernel.org/show_bug.cgi?id=62721
--- Comment #14 from Jason Vas Dias ---
When the lockup happens, the ++ VT switch keys also stop
working, and the only way to access the machine is to SSH in from another host.
I was going to report this as an Ubuntu bug, but it appears to be an
https://bugzilla.kernel.org/show_bug.cgi?id=62721
Jason Vas Dias changed:
What|Removed |Added
CC||jason.vas.dias at gmail.com
--- Comment
On Fri, Oct 10, 2014 at 12:00 PM, Alex Deucher wrote:
> On Thu, Oct 9, 2014 at 3:10 PM, Alexander Fyodorov wrote:
>> 09.10.2014, 22:32, "Christian K?nig" :
>>> Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
09.10.2014, 21:42, "Christian K?nig" :
> For VRAM it is true that we have a
On Thu, Oct 9, 2014 at 3:10 PM, Alexander Fyodorov wrote:
> 09.10.2014, 22:32, "Christian K?nig" :
>> Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
>>> 09.10.2014, 21:42, "Christian K?nig" :
For VRAM it is true that we have a couple of different caches between
the CPU and the act
[0.00] Linux version 3.18.0-0.rc0.git2.1.fc22.x86_64 (mockbuild at
bkernel01.phx2.fedoraproject.org) (gcc version 4.9.1 20140930 (Red Hat
4.9.1-11) (GCC) ) #1 SMP Thu Oct 9 13:57:38 UTC 2014
[0.00] Command line:
BOOT_IMAGE=/vmlinuz-3.18.0-0.rc0.git2.1.fc22.x86_64
root=UUID=a075
guys maybe try recompiling
mesa with llvm 3.6?
--
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/20141010/db46c35a/attachment-0001.html>
On Fri, 2014-10-10 at 12:20 +0900, Michel D?nzer wrote:
> On 09.10.2014 19:22, Alan Swanson wrote:
> > On 2014-10-09 07:02, Michel D?nzer wrote:
> >> From: Michel D?nzer
> >>
> >> The radeon driver uses placement range restrictions for several reasons,
> >> in particular to make sure BOs in VRAM c
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/5d5163f5/attachment.html>
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/88b90fe5/attachment-0001.html>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/19f036ff/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83731
--- Comment #1 from Giancarlo Formicuccia
---
Kernel 3.17 is out and now radeon.dpm=0 is required in order to boot this
system.
Can I receive a comment about this problem? Why is this card special?
--
You are receiving this mail because:
You a
0.3.0
AMD Radeon HD 7730M
--
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/20141010/5472521d/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/20141010/31aa16e4/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/00ce0ebe/attachment.html>
Hi,
On Wed, Oct 08, 2014 at 12:00:27PM -0400, Jerome Glisse wrote:
[...]
> And now all ioctl go through this single entry point :
>
> int radeon_ioctl_stub(int ioctl, void *data, ...)
> {
> struct radeon_ioctl *rio = data;
>
> return rdispatch_ioctls[rio->version][ioctl](data, ...);
>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/7b61a50e/attachment.html>
org/archives/dri-devel/attachments/20141010/2b78eb63/attachment.html>
his 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/20141010/862cbd4c/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141010/b8d5d3cf/attachment.html>
other issues, so hopefully the end result will be even better
than before. :)
--
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
52 matches
Mail list logo
