https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #92 from 720 ---
The bug is still not fixed.
Been using Radeon 3650 with dpm, and now running rc5.
Everything went well until I had a reboot due to a NOD32 install.
That time I encountered the white screen of death once again.
Can I
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #93 from Francisco Pina Martins ---
Created attachment 83998
--> https://bugs.freedesktop.org/attachment.cgi?id=83998&action=edit
journalctl relevant output
I had a crash with the white screen yestreday.
It occurred while playing C
Hi all,
This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and
may be final RFC.
The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA and DMA
This patch adds a buffer synchronization framework based on DMA BUF[1]
and and based on ww-mutexes[2] for lock mechanism.
The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
user application. This framewor
This patch adds lock and poll callbacks to dma buf file operations,
and these callbacks will be called by fcntl and select system calls.
fcntl and select system calls can be used to wait for the completion
of DMA or CPU access to a shared dmabuf. The difference of them is
fcntl system call takes a
On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
> Hi,
>
> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
> top, it's simply black.
> I can estimate the URL line in Firefox (or open a new tab blindly and
> get a known URL from my
On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> After a logout from my "BROKEN" Unity-2D session - the login-screen
> for LightDM seems to be OK.
> Then entering my Unity-2D desktop is OK - no screen corruptions.
What hardware and display do you have?
-Chris
--
Chris Wilson, Intel
On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
> >> for LightDM seems to be OK.
> >> Th
Hey Alex,
here are my patches for reworking the ring function pointers and separating out
the UVD and DMA rings.
Everything is rebased on your drm-next-3.12-wip branch, please review and add
them to your branch.
Thanks,
Christian.
___
dri-devel mail
From: Christian König
The hardware just doesn't support this correctly.
Disable it before we accidentally write anywhere we shouldn't.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c |3 +--
drivers/gpu/drm/radeon/evergreen.c |3 +--
drivers/gpu/drm/radeon/ni.
From: Christian König
Now that we have callbacks for [rw]ptr handling we can
remove the special handling for the DMA rings and use
the callbacks instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c | 20 ++-
drivers/gpu/drm/radeon/evergreen.c |6
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Mark Brown
> Sent: Tuesday, August 13, 2013 6:54 PM
> To: Inki Dae
> Cc: 'David Airlie'; linux-samsung-...@vger.kernel.org; dri-
> de...@lists.freedesktop.
Please disregard this patch and the related patches. It causes a
regression which I haven't been able to fix yet.
Marek
On Mon, Aug 12, 2013 at 8:19 PM, Marek Olšák wrote:
> Basically just pass RADEON_TILING_R600_SCANOUT everywhere.
> Hopefully I didn't miss anything. This is only compile-tested
VMA offsets are 64bit so do not cast them to "unsigned int". Also remove
the (now useless) offset-retrieval helper. The VMA manager provides simple
enough helpers.
Cc: Thierry Reding
Cc: "Terje Bergström"
Cc: Arto Merilainen
Signed-off-by: David Herrmann
---
drivers/gpu/host1x/drm/drm.c | 2 +
Op 12-08-13 18:19, Ilia Mirkin schreef:
> On Mon, Aug 12, 2013 at 6:43 AM, Maarten Lankhorst
> wrote:
>> Some registers were not initialized in init, this causes them to be
>> uninitialized after suspend.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> diff --git a/drivers/gpu/drm/nouveau/core/s
Just adding more detailed descriptions.
Hi all,
This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and
may be final RFC.
The purpose of this framework is to provide not only buffer access
control to CPU a
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #94 from Alex Deucher ---
(In reply to comment #92)
> The bug is still not fixed.
> Been using Radeon 3650 with dpm, and now running rc5.
>
> Everything went well until I had a reboot due to a NOD32 install.
> That time I encountered
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #31 from wuruxu ---
Hi Alex Deucher
after disable dpm, no such error message in dmesg, that bug should be fixed.
but with dpm is enabled, resume cann't work correctly.
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #32 from Alex Deucher ---
(In reply to comment #31)
> Hi Alex Deucher
>
> after disable dpm, no such error message in dmesg, that bug should be
> fixed.
> but with dpm is enabled, resume cann't work correctly.
Please file a new b
https://bugs.freedesktop.org/show_bug.cgi?id=68059
Priority: medium
Bug ID: 68059
Assignee: dri-devel@lists.freedesktop.org
Summary: with radeon.dpm=1, Xorg crashed a while after resume
Severity: critical
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=66425
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #33 from Christian
> > > > So in the above, after X receives the second DRI2SwapBuffers, it
> > > > doesn't need to get scheduled again for the next frame to be both
> > > > rendered by the GPU and issued to the display for scanout.
> > >
> > > well, this is really only an issue if you are so loaded that you
> > > do
On Tue, Aug 13, 2013 at 5:56 AM, Christian König
wrote:
> Hey Alex,
>
> here are my patches for reworking the ring function pointers and separating
> out the UVD and DMA rings.
>
> Everything is rebased on your drm-next-3.12-wip branch, please review and add
> them to your branch.
Patches look
On Tue, Aug 13, 2013 at 10:35 AM, Tom Cooksey wrote:
>> > > > So in the above, after X receives the second DRI2SwapBuffers, it
>> > > > doesn't need to get scheduled again for the next frame to be both
>> > > > rendered by the GPU and issued to the display for scanout.
>> > >
>> > > well, this is
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 120 +
1 file changed, 120 insertions(+)
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 120 ++
1 file changed, 120 insertions(+)
This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt | 18 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 191 +++-
2 f
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 120 ++
1 file changed, 120 insertions(+)
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 120 +
1 file changed, 120 insertions(+)
This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt | 18 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 191 +++-
2 f
ct against the staging tree.
>
> The akpm tree gained a conflict against the staging tree.
>
> ----
>
Hi,
with today's next-20130813 I cannot see 1/10 of my desktop-screen's
top, it's simply black
;
>>> The akpm tree gained a conflict against the staging tree.
>>>
>>>
>>>
>>
>> Hi,
>>
>> with today's next-20130813 I cannot see 1/10 of my desktop-sc
Hello,
in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced
error which cause that on my Nvidia 6600GT card reclocking not working
anymore. There is missing assigment of return value from pll_calc to ret.
After this patch reclocking on my card working fine again. Above broken
commit
On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
>> top, it's simply black.
>> I can estimate the UR
On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> After a logout from my "BROKEN" Unity-2D session - the login-screen
>> for LightDM seems to be OK.
>> Then entering my Unity-2D desktop is OK - no screen corruptions.
>
> What ha
On Tue, Aug 13, 2013 at 11:27:04AM +0900, Inki Dae wrote:
> > Ensure that all externally accessed functions are correctly prototyped
> > when defined in each file by making sure the headers with the protoypes
> > are included in the file with the definition.
> I definitely missed it. sorry about
Hello,
after commit ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954 temperature information
from lm sensors is not available on my Nvidia 6600GT graphics card. There is
no nouveau hwmon entry in sysfs anymore. Why it was removed? Can I help with
debugging? I'd like to see temperature sensor working ag
On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> >> After a logout from my "BROKEN" Unity-2D sessio
On 13/08/2013 05:56, Pali Rohár wrote:
Hello,
after commit ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954 temperature information
from lm sensors is not available on my Nvidia 6600GT graphics card. There is
no nouveau hwmon entry in sysfs anymore. Why it was removed? Can I help with
debugging? I'd lik
On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
> On 13/08/2013 05:56, Pali Rohár wrote:
> > Hello,
> >
> > after commit ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954 temperature
> > information from lm sensors is not available on my Nvidia 6600GT graphics
> > card. There is no nouveau hwmon ent
On 13/08/2013 09:23, Pali Rohár wrote:
On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
On 13/08/2013 05:56, Pali Rohár wrote:
Hello,
after commit ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954 temperature
information from lm sensors is not available on my Nvidia 6600GT graphics
card. There is
On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres wrote:
On 13/08/2013 09:23, Pali Rohár wrote:
On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
...
You can check the temperature by running nvidia-settings. If you can't
see the temperature in it, then nvidia doesn't support it on y
On 13/08/2013 09:53, Pali Rohár wrote:
On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres wrote:
On 13/08/2013 09:23, Pali Rohár wrote:
On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
...
You can check the temperature by running nvidia-settings. If you can't
see the temperature in
" (HD-3000 was new to me) in my
> Xorg.log :-).
>
> As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
> Starting again a Unity-2D session - no screen corruption, too.
>
> - Sedat -
Some more testing:
[1] With my X stack:
FIRST BAD: next-20130812
L
Hi Laurent,
thanks for this update. I'm very happy about the move to the display
entity model, given that the i.MX6 IPU has both drm/display and
v4l2/capture ports in a single device - this will allow to use a unified
device tree binding scheme. I'm still trying to see how this all fits
together,
make a difference? It shouldn't if the error is occuring before
>>> X even starts...
>>
>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
>> Xorg.log :-).
>>
>> As said logging out of Unity-2D and entering LightDM greeter
https://bugs.freedesktop.org/show_bug.cgi?id=67530
gurket...@googlemail.com changed:
What|Removed |Added
Attachment #83741|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=67530
--- Comment #7 from Christian König ---
(In reply to comment #6)
> Created attachment 84021 [details] [review]
> use more common defaults for the level (all cards)
>
> I fixed the white spaces and added all drivers. The problem I see is, the
> d
On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote:
> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
> >
> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
> > commit 5456fe3882812aba251886e36fe55
On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote:
> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson
> > wrote:
> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek
>
Hi
This is v2 of my anon_inodes allocation series. I would really like some
comments on #1 (and maybe #2) from VFS maintainers/developers so we can continue
with this work. Patches 1 and 2 are unchanged, I added 3 and 4 to clean up DRM
delayed initializations based on the new anon_inode.
This im
DRM core shares a single address_space across all inodes that belong to
the same DRM device. This allows efficient unmapping of user-space
mappings during buffer eviction. However, there is no easy way to get a
shared address_space for DRM devices during initialization. Therefore, we
currently dela
Instead of delaying inode initialization until first ->open(), we can use
an anonymous inode. This avoids modifying FS internal inode fields and
provides us a private address_space right during initialization.
Delayed TTM dev_mapping initialization is currently left untouched to keep
this simple.
With dev->anon_inode we have a global address_space ready for operation
right from the beginning. Therefore, there is no need to do a delayed
setup with TTM. Instead, set dev_mapping during initialization in
ttm_bo_device_init() and remove any if (dev_mapping) conditions.
Cc: Dave Airlie
Cc: Ben
anon_inode->i_mapping is always set. This was needed before we introduced
anon_inodes. We can safely remove it now.
Cc: Rob Clark
Signed-off-by: David Herrmann
---
drivers/gpu/drm/omapdrm/omap_gem.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff -
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> Files attached.
Can you also please attach a full dmesg so I can check for anything
unusual?
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
Hi
On Thu, Aug 8, 2013 at 3:41 PM, Daniel Vetter wrote:
> We might as well have a real ioctl function which checks for the
> callbacks. This seems to be a remnant from back in the days when each
> drm driver had their own complete ioctl table, with no shared core
> drm table at all.
>
> To make r
Hi
On Thu, Aug 8, 2013 at 3:41 PM, Daniel Vetter wrote:
> We kzalloc this structure, and for real kms devices we should never
> loose track of things really.
>
> But ums/legacy drivers rely on the drm core to clean up a bit of cruft
> between lastclose and firstopen (i.e. when X is being restarte
Hello All,
following the inclusion of UVD support for and a post I've seen written by on
of the devs mentioning that the hdmi sound will likely to be activated by
default in 3.12, I've decided to switch my cards and use the hd5450 as the
media center card and connect it to my hdtv.
I've enable
2013/8/13 stompdagg...@yahoo.com :
> following the inclusion of UVD support for and a post I've seen written by
> on of the devs mentioning that the hdmi sound will likely to be activated by
> default in 3.12, I've decided to switch my cards and use the hd5450 as the
> media center card and connect
From: Rafał Miłecki
To: "stompdagg...@yahoo.com"
Cc: "dri-devel@lists.freedesktop.org"
Sent: Tuesday, August 13, 2013 9:39 PM
Subject: Re: no hdmi sound on hd5450
>2013/8/13 stompdagg...@yahoo.com :
>> following the inclusion of UVD support for and a post I've seen written by
>> on of the
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> Files attached.
> >
> > Can you also please attach a full dmesg so I can check for anything
> > unusual?
> >
https://bugzilla.kernel.org/show_bug.cgi?id=60674
--- Comment #7 from nuc...@hotmail.com ---
I have taken the time, read some how-to's and bisected the kernel. I have
managed narrow down the number responsible commits to 8.
Unfortunately out of some reason Xorg sincerely broke on my system (with
Hi all,
Ok I've tossed around another idea with Sean on irc, but it turned out
to be too complicated for irc. So here it's in more detail. So the
goal is to share bridge drivers/transcoders/whatever between different
drivers without going all-in with something like cdf but allowing easy
transition
Hi
On Thu, Aug 8, 2013 at 3:41 PM, Daniel Vetter wrote:
> So I've stumbled over drm_fasync and wondered what it does. Digging
> that up is quite a story.
>
> First I've had to read up on what this does and ended up being rather
> bewildered why peopled loved signals so much back in the days that
Hi
This is the second part of the unified VMA manager. It implements proper access
management so applications can map only buffers that they own handles for.
Patches of interest probably are:
#1: Implement VMA access management helpers
#9: Make TTM deny unprivileged mmap() calls
#10: Do the sa
The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn'
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/ast/ast_drv.c | 2 ++
drivers/gpu/drm/ast/ast_drv.h | 4
drivers/gpu/drm/ast/ast_main.c | 15 +++
3 files changed, 2
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 4
drivers/gpu/drm/cirrus/cirrus_main.c | 15 +++
2 files changed, 19 insertions(+)
diff --git
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++
drivers/gpu/drm/mgag200/mgag200_drv.h | 4
drivers/gpu/drm/mgag200/mgag200_main.c | 15 +++
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
Cc: Ben Skeggs
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nou
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
Cc: Alex Deucher
Signed-off-by: David Herrmann
---
drivers/gpu/drm/radeon/radeon_gem.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/ra
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/qxl/qxl_gem.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/q
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager. We also need to make vmw_user_dmabuf_reference()
correctly increase the vma-allow counter, but it is unused so remove it
instead.
Cc: Thomas Hellstrom
Signed-off-by: David Herrmann
---
drivers/gpu/drm/vm
If a user does not have access to a given buffer, we must not allow them
to mmap it. Otherwise, users could "guess" the buffer offsets of other
users and get access to the buffer.
Similar to mmap(), we also fix ttm_bo_io() which is the backend for read()
and write() syscalls. It's currently unused,
Implement automatic access management for mmap offsets for all GEM
drivers. This prevents user-space applications from "guessing" GEM BO
offsets and accessing buffers which they don't own.
TTM drivers or other modesetting drivers with custom mm handling might
make use of GEM but don't need its mma
Set DRIVER_GEM_MMAP to make GEM core track buffer accesses via the DRM VMA
Offset Manager.
Cc: Daniel Vetter
Signed-off-by: David Herrmann
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/
Set DRIVER_GEM_MMAP to make GEM core track buffer accesses via the DRM VMA
Offset Manager.
Cc: Inki Dae
Signed-off-by: David Herrmann
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/driv
Set DRIVER_GEM_MMAP to make GEM core track buffer accesses via the DRM VMA
Offset Manager.
Cc: Rob Clark
Signed-off-by: David Herrmann
---
drivers/gpu/drm/omapdrm/omap_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/d
Set DRIVER_GEM_MMAP to make GEM core track buffer accesses via the DRM VMA
Offset Manager.
Cc: David Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/u
Set DRIVER_GEM_MMAP to make GEM core track buffer accesses via the DRM VMA
Offset Manager.
Cc: Patrik Jakobsson
Signed-off-by: David Herrmann
---
drivers/gpu/drm/gma500/psb_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu
Set DRIVER_GEM_MMAP to make GEM core track buffer accesses via the DRM VMA
Offset Manager.
Cc: Thierry Reding
Cc: "Terje Bergström"
Cc: Arto Merilainen
Signed-off-by: David Herrmann
---
drivers/gpu/host1x/drm/drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gp
On Tue, Aug 13, 2013 at 3:38 PM, David Herrmann wrote:
> Set DRIVER_GEM_MMAP to make GEM core track buffer accesses via the DRM VMA
> Offset Manager.
>
> Cc: Rob Clark
> Signed-off-by: David Herrmann
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 3 ++-
> 1 file changed, 2
On Tue, Aug 13, 2013 at 3:16 PM, Daniel Vetter wrote:
> Hi all,
>
> Ok I've tossed around another idea with Sean on irc, but it turned out
> to be too complicated for irc. So here it's in more detail. So the
> goal is to share bridge drivers/transcoders/whatever between different
> drivers without
https://bugzilla.kernel.org/show_bug.cgi?id=60674
--- Comment #8 from Alex Deucher ---
Created attachment 107198
--> https://bugzilla.kernel.org/attachment.cgi?id=107198&action=edit
possible fix
This patch should fix it.
--
You are receiving this mail because:
You are watching the assignee o
Uses the wrong array size for some asics.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60674
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/rv770.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rv
On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
> >> wrote:
> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200,
with the known background.
> >> So-to-say 3/4 "blind".
> >
> > That implies that the scanout is always reading from the base of stolen.
> > Can you grab intel_reg_dumper so that I can check what values the
> > transcoder is set to?
> >
> > At the m
https://bugs.freedesktop.org/show_bug.cgi?id=67927
--- Comment #6 from Dieter Nützel ---
The patch fix Mesa-demos 'objview GreatLakesBiplaneHP.obj' for sure, too.
Please commit!
-Dieter
--
You are receiving this mail because:
You are the assignee for the bug.
_
This adds a helper function to extract the speaker allocation
data block from the EDID. This data block describes what speakers
are present on the display device.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c | 50 ++
include/drm/drm_edid
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c | 53 ++---
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/rad
Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.
v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on
On Tue, Aug 13, 2013 at 09:38:31PM +0200, David Herrmann wrote:
> Implement automatic access management for mmap offsets for all GEM
> drivers. This prevents user-space applications from "guessing" GEM BO
> offsets and accessing buffers which they don't own.
>
> TTM drivers or other modesetting dr
Hi
On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann wrote:
> Correctly allow and revoke buffer access on each open/close via the new
> VMA offset manager. We also need to make vmw_user_dmabuf_reference()
> correctly increase the vma-allow counter, but it is unused so remove it
> instead.
>
> Cc: T
On Mon, Aug 12, 2013 at 12:42 PM, Alex Deucher wrote:
> This is the initial set of patches for 3.12 for radeon. The
> big changes here are adding ASPM and DPM support to CIK asics.
> There are also some cleanups related to removing bo copy support
> using the 3D engine in favor of the sDMA engine
https://bugs.freedesktop.org/show_bug.cgi?id=67981
--- Comment #2 from Stefan Schmidt ---
I installed all 9.2.0~git20130729+9.2.9b8ad643-0ubuntu0sarvatt~precise updates
via https://launchpad.net/~xorg-edgers but sadly nothing changed. Any further
ideas?
--
You are receiving this mail because:
Y
On Tue, Aug 13, 2013 at 3:55 PM, Sean Paul wrote:
> On Tue, Aug 13, 2013 at 3:16 PM, Daniel Vetter wrote:
>> Hi all,
>>
>> Ok I've tossed around another idea with Sean on irc, but it turned out
>> to be too complicated for irc. So here it's in more detail. So the
>> goal is to share bridge driver
https://bugs.freedesktop.org/show_bug.cgi?id=68059
wuruxu changed:
What|Removed |Added
Priority|medium |high
--- Comment #1 from wuruxu ---
[ 119.444
1 - 100 of 262 matches
Mail list logo
