On 15.01.2013 20:44, Stephen Warren wrote:
> On 01/15/2013 04:26 AM, Terje Bergstrom wrote:
>> Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
>> of 2D clock to that driver alias.
>
> FYI on this one patch - it won't be applied to the Tegra tree until
> after Prashant's common
https://bugs.freedesktop.org/show_bug.cgi?id=58958
Harald Judt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, 14 Jan 2013, Jiri Slaby wrote:
> On 01/14/2013 01:56 PM, Rafael J. Wysocki wrote:
>> On Monday, January 14, 2013 11:11:52 AM Jiri Slaby wrote:
>>> Hi,
>>>
>>> since friday's -next (the last known to be working is the last monday's)
>>> I cannot resume from suspend. The last thing I see wit
On Tue, Jan 15, 2013 at 9:17 PM, Thierry Reding
wrote:
> On Tue, Jan 15, 2013 at 06:53:19PM +0100, Daniel Vetter wrote:
>> On Mon, Jan 14, 2013 at 4:55 PM, Thierry Reding
>> wrote:
>> > +static void tegra_drm_preclose(struct drm_device *drm, struct drm_file
>> > *file)
>> > +{
>> > + struc
On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
>
> gem_prime_pin: callback when
On Wed, Jan 16, 2013 at 10:43:15AM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2013 at 9:17 PM, Thierry Reding
> wrote:
> > On Tue, Jan 15, 2013 at 06:53:19PM +0100, Daniel Vetter wrote:
> >> On Mon, Jan 14, 2013 at 4:55 PM, Thierry Reding
> >> wrote:
> >> > +static void tegra_drm_preclose(stru
On 01/16/2013 10:20 AM, Jani Nikula wrote:
> Hi Jiri, the dmesgs for both cases with drm.debug=0xe module param might
> give us some clues.
>
> Does it work without no_console_suspend?
Hi, no, it does not work either way. But what I found out with debug
enabled, that it's a completely different p
Op 16-01-13 07:28, Inki Dae schreef:
> 2013/1/15 Maarten Lankhorst :
>> This type of fence can be used with hardware synchronization for simple
>> hardware that can block execution until the condition
>> (dma_buf[offset] - value) >= 0 has been met.
>>
>> A software fallback still has to be provided
I'm testing the pageflip & vblank change on cardhu. Seems the HDMI
doesn't work(LVDS only is OK). I'll let you know if I get something.
Mark
On 01/15/2013 12:06 AM, Thierry Reding wrote:
> All the necessary support bits like .mode_set_base() and VBLANK are now
> available, so page-flipping case ea
https://bugs.freedesktop.org/show_bug.cgi?id=59431
Chris Wilson changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
Am Mittwoch, den 16.01.2013, 19:10 +0800 schrieb Mark Zhang:
> I'm testing the pageflip & vblank change on cardhu. Seems the HDMI
> doesn't work(LVDS only is OK). I'll let you know if I get something.
>
Just to provide another data point: I'm running this series and don't
see any failures with DVI
2013/1/16 Maarten Lankhorst :
> Op 16-01-13 07:28, Inki Dae schreef:
>> 2013/1/15 Maarten Lankhorst :
>>> This type of fence can be used with hardware synchronization for simple
>>> hardware that can block execution until the condition
>>> (dma_buf[offset] - value) >= 0 has been met.
>>>
>>> A soft
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher (1):
radeon: add new SI pci id
Ben Skeggs (2):
nouveau: disallow pushbuf BOs in multiple memory types
nouveau: expose channel engine selection on kepler chipsets
Chris Wilson (1):
intel: Remove the fence count con
On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
wrote:
> drm_events_release() should be enough to clean up the events, but I
> suspect the reason why Laurent put that code in was that the drm_crtc
> private data still has a reference to the event and needs to clear it.
> Otherwise the next page f
On Mon, Jan 14, 2013 at 03:30:22PM +0100, Thierry Reding wrote:
> Add generic helpers to pack HDMI infoframes into binary buffers.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - add support for audio, vendor-specific and SPD infoframes
> - add various validity checks on infoframes
>
On Wed, Jan 16, 2013 at 6:36 AM, Daniel Vetter wrote:
> On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
> wrote:
>> drm_events_release() should be enough to clean up the events, but I
>> suspect the reason why Laurent put that code in was that the drm_crtc
>> private data still has a reference t
Op 16-01-13 13:19, Maarten Lankhorst schreef:
> ...
> Jesse Barnes (1):
> man: disable man page building until David saves us all
>
Looks like this commit might break building if you don't build against git
directly, since it's not included in the tarball.
The fix for this is removing man/M
All those functions only scan a predefined EDID block and have no need
to alter anything. Constify the passed in struct edid pointer to reflect
this in the interface.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/drm_edid.c | 73 --
include/drm/drm_cr
Check if sink is HDMI capable when enabling an output. This disables
HDMI audio/infoframes if we are talking to a plain DVI sink. All things
except this check are already in place.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
Remove the "internal" interrupt handling since it's never invoked and
remove "external" reference. This patch removes a bunch of dead code
and clarifies how hotplugging is handled in the HDMI driver.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 74 ++-
On Wed, Jan 16, 2013 at 03:36:41PM +0100, Lucas Stach wrote:
[...]
> @@ -705,7 +705,7 @@ static int standard_timing_level(struct edid *edid)
> * monitors fill with ascii space (0x20) instead.
> */
> static int
> -bad_std_timing(u8 a, u8 b)
> +bad_std_timing(const u8 a, const u8 b)
> {
>
On Wed, Jan 16, 2013 at 03:36:42PM +0100, Lucas Stach wrote:
> Check if sink is HDMI capable when enabling an output. This disables
> HDMI audio/infoframes if we are talking to a plain DVI sink. All things
> except this check are already in place.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/g
On Tue, Jan 15, 2013 at 11:28 PM, Dave Airlie wrote:
> When we are using memcpy to move objects around, and we fail to memcpy
> due to lack of memory to populate or failure to finish the copy, we don't
> want to destroy the mm_node that has been copied into old_copy.
>
> While working on a new kms
On Wed, Jan 16, 2013 at 1:01 AM, Dave Airlie wrote:
> if we have a move notify callback, when moving fails, we call move notify
> the opposite way around, however this ends up with *mem containing the mm_node
> from the bo, which means we double free it. This is a follow on to the
> previous
> fi
Am Mittwoch, den 16.01.2013, 16:23 +0100 schrieb Thierry Reding:
> On Wed, Jan 16, 2013 at 03:36:41PM +0100, Lucas Stach wrote:
> [...]
> > @@ -705,7 +705,7 @@ static int standard_timing_level(struct edid *edid)
> > * monitors fill with ascii space (0x20) instead.
> > */
> > static int
> > -ba
https://bugs.freedesktop.org/show_bug.cgi?id=27704
--- Comment #8 from smoki ---
On Fri, Jan 11, 2013 at 6:37 AM, smoki wrote:
> Piglit passes more fbo tests on rv280, 14/28 before and now 28/33.
> Also should fix bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=27704
Does this regress anyth
https://bugs.freedesktop.org/show_bug.cgi?id=59475
Priority: medium
Bug ID: 59475
Assignee: dri-devel@lists.freedesktop.org
Summary: GL programs crash with glxbadcontext or other errors
in Fedora 18 on this machine
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=27704
--- Comment #9 from Michel Dänzer ---
(In reply to comment #8)
> I am not member on the mesa dev list, so to quick answer here :).
You can post to the list as a non-member, your posts just go through the
moderation queue then. Please don't abus
On Wed, Jan 16, 2013 at 03:36:41PM +0100, Lucas Stach wrote:
> All those functions only scan a predefined EDID block and have no need
> to alter anything. Constify the passed in struct edid pointer to reflect
> this in the interface.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/drm_edi
https://bugs.freedesktop.org/show_bug.cgi?id=59477
Priority: medium
Bug ID: 59477
Assignee: dri-devel@lists.freedesktop.org
Summary: libdrm 2.4.41 build failure
Severity: normal
Classification: Unclassified
OS: Linux (All)
On Wed, 16 Jan 2013, Lucas Stach wrote:
> Am Mittwoch, den 16.01.2013, 16:23 +0100 schrieb Thierry Reding:
>> On Wed, Jan 16, 2013 at 03:36:41PM +0100, Lucas Stach wrote:
>> [...]
>> > @@ -705,7 +705,7 @@ static int standard_timing_level(struct edid *edid)
>> > * monitors fill with ascii space (
https://bugs.freedesktop.org/show_bug.cgi?id=59477
--- Comment #1 from Tobias Klausmann ---
Ok never mind! The tar.bz2 snapshot from here is broken:
http://lists.x.org/archives/xorg-announce/2013-January/002137.html
Please update it, and maybe add a git tag for the 2.4.41 release!
Thanks
--
From: Ville Syrjälä
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
From: Ville Syrjälä
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.
From: Ville Syrjälä
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 33 +
Second attempt at handling the RGB quantization range for HDMI and DP.
The only change to the first set is that I dropped the
has_hdmi_monitor bool. has_hdmi_sink is used instead.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.fr
From: Ville Syrjälä
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise ful
On 01/16/2013 01:10 AM, Terje Bergström wrote:
> On 15.01.2013 20:44, Stephen Warren wrote:
>> On 01/15/2013 04:26 AM, Terje Bergstrom wrote:
>>> Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
>>> of 2D clock to that driver alias.
>>
>> FYI on this one patch - it won't be appli
Hi Maarten
On Wed, Jan 16, 2013 at 3:16 PM, Maarten Lankhorst
wrote:
> Op 16-01-13 13:19, Maarten Lankhorst schreef:
>> ...
>> Jesse Barnes (1):
>> man: disable man page building until David saves us all
>>
> Looks like this commit might break building if you don't build against git
> dire
This fixes all the out-of-tree build-failures with manpages and uses a
.man_fixup file to avoid overriding man-pages on every build.
Manpages are only built if xsltproc is found and the stylesheets are
available locally. You can disable building manpages with
--disable-manpages so the quite expens
Hi Colin
On Thu, Jan 10, 2013 at 1:46 AM, Colin Walters wrote:
> It's not enough to check for xsltproc - the system may not have the
> docbook stylesheets installed. This patch also allows builders to
> override the generation/installation of manpages entirely; for
> example, manpages are of no
On Wed, Jan 16, 2013 at 07:04:22PM +0200, Jani Nikula wrote:
> On Wed, 16 Jan 2013, Lucas Stach wrote:
> > Am Mittwoch, den 16.01.2013, 16:23 +0100 schrieb Thierry Reding:
> >> On Wed, Jan 16, 2013 at 03:36:41PM +0100, Lucas Stach wrote:
> >> [...]
> >> > @@ -705,7 +705,7 @@ static int standard_ti
On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
> On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
> wrote:
> > drm_events_release() should be enough to clean up the events, but I
> > suspect the reason why Laurent put that code in was that the drm_crtc
> > private data still has a
https://bugzilla.kernel.org/show_bug.cgi?id=52491
--- Comment #13 from Jérôme Glisse 2013-01-16
22:31:46 ---
Created an attachment (id=91421)
--> (https://bugzilla.kernel.org/attachment.cgi?id=91421)
Exclude system placement
Does applying this patch without reverting anything fix the issu
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #13 from Jerome Glisse ---
Created attachment 73168
--> https://bugs.freedesktop.org/attachment.cgi?id=73168&action=edit
Exclude system placement
Does applying this patch without reverting anything fix the issue ?
--
You are rece
On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
wrote:
> On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote:
>> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote:
>> > On Die, 2013-01-15 at 16:23 +0100, Markus Trippelsdorf wrote:
>> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote:
On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
> wrote:
> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote:
> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote:
> >> > On Die, 2013-01-15 at 16:23 +0100, Markus Trippelsdorf wrot
On 01/16/2013 01:50 AM, Daniel Vetter wrote:
On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook func
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #14 from Bryan Quigley ---
I tested with just this second patch and it did not help.
Do you want me to test with both patches applied?
--
You are receiving this mail because:
You are the assignee for the bug.
__
On Wed, Jan 16, 2013 at 7:24 AM, Thierry Reding
wrote:
> On Wed, Jan 16, 2013 at 03:36:42PM +0100, Lucas Stach wrote:
>> Check if sink is HDMI capable when enabling an output. This disables
>> HDMI audio/infoframes if we are talking to a plain DVI sink. All things
>> except this check are already
In UMS mode parser->rdev is NULL, so dereferencing
will cause an oops.
Upstream commit-id: ff4bd0827764e10a428a9d39e6814c5478863f94
Stable tree: 3.7
Signed-off-by: Ilija Hadzic
Signed-off-by: Alex Deucher
Signed-off-by: Shuah Khan
CC: sta...@vger.kernel.org 3.7
---
drivers/gpu/drm/radeon/rade
Fix parser->rdev NULL pointer dereference in radeon_cs_parser_fini().
While back-porting drm/radeon: fix NULL pointer dereference in UMS mode
patch (commit-id: ff4bd0827764e10a428a9d39e6814c5478863f94) to 3,7.y, noticed
another instance of NULL pointer dereference in radeon_cs_parser_fini()
functio
On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
wrote:
> On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
>> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
>> wrote:
>> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote:
>> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=52491
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
--- Comment #1
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #37 from Jerome Glisse ---
This patch might help:
http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #15 from Jerome Glisse ---
You sure you using the module with the patch ? You rebuilded your initrd and
all ?
Other user that pointed to same commit have the issue fixed by this patch. A
better version of this patch is also at :
http
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #16 from Bryan Quigley ---
I'm building with
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild#Kernel_Build_and_Installation
I'm running step 9 after doing git apply patch and then git commit.
I'll try the latest patch.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #17 from Jerome Glisse ---
You also need step 12 of and please add :
printk(KERN_INFO "TITITOTOTUTUPOPO\n");
to
radeon_device.c line 992 after DRM_INFO("initializing ke
And when testing to make sure you are using the patched
https://bugs.freedesktop.org/show_bug.cgi?id=59492
Priority: medium
Bug ID: 59492
Assignee: dri-devel@lists.freedesktop.org
Summary: piglit dlist-color-material test fail
Severity: normal
Classification: Unclassified
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=59492
--- Comment #1 from smoki ---
So default command like
glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE)
never worked quite right on tcl.
--
You are receiving this mail because:
You are the assignee for the bug.
_
On Wed, 16 Jan 2013 19:35:25 +0100
David Herrmann wrote:
> This fixes all the out-of-tree build-failures with manpages and uses a
> .man_fixup file to avoid overriding man-pages on every build.
>
> Manpages are only built if xsltproc is found and the stylesheets are
> available locally. You can
https://bugs.freedesktop.org/show_bug.cgi?id=59089
--- Comment #8 from Alexandre Demers ---
(In reply to comment #7)
> I would consider it a flood, the message continually appears until glxgears
> is exited. Can you confirm whether 3e163a137be7f9a80ec720903c4bda028de5681f
> in mesa stops all of
Actually, the code path affected by your patch is not executed in UMS mode
at all. Notice that radeon_cs_parser_fini is only called from
radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
The equivalent of the fix you are trying to do is in
a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e
https://bugs.freedesktop.org/show_bug.cgi?id=59089
--- Comment #9 from Anthony Waters ---
Mesa is at latest git, however, my kernel wasn't at Linus' git, so that may be
the issue, using HD 6950. I will try the newest kernel and if it doesn't work
I'll create a new bug report.
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=59089
--- Comment #10 from Alexandre Demers ---
(In reply to comment #9)
> Mesa is at latest git, however, my kernel wasn't at Linus' git, so that may
> be the issue, using HD 6950. I will try the newest kernel and if it doesn't
> work I'll create a ne
https://bugs.freedesktop.org/show_bug.cgi?id=58354
--- Comment #21 from Alexandre Demers ---
(In reply to comment #19)
> (In reply to comment #18)
> > Created attachment 72794 [details] [review] [review]
> > possible fix
> >
> > Does this kernel patch help?
>
> No. I was able to catch something
On 01/16/2013 07:53 PM, Lucas Stach wrote:
> Am Mittwoch, den 16.01.2013, 19:10 +0800 schrieb Mark Zhang:
>> I'm testing the pageflip & vblank change on cardhu. Seems the HDMI
>> doesn't work(LVDS only is OK). I'll let you know if I get something.
>>
> Just to provide another data point: I'm runnin
https://bugs.freedesktop.org/show_bug.cgi?id=59089
--- Comment #11 from Alexandre Demers ---
(In reply to comment #9)
> Mesa is at latest git, however, my kernel wasn't at Linus' git, so that may
> be the issue, using HD 6950. I will try the newest kernel and if it doesn't
> work I'll create a ne
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #18 from Bryan Quigley ---
I didn't need to do step 12 to get the TITITOTO message printed. I did what
I've been doing all along. (I'm also trying to update the GitKernelBuild page
as I go) If the message was printed that means it
On 01/15/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
> ---
On 01/15/2013 12:06 AM, Thierry Reding wrote:
> All the necessary support bits like .mode_set_base() and VBLANK are now
> available, so page-flipping case easily be implemented on top.
>
> Signed-off-by: Thierry Reding
[...]
> +
> +static int tegra_dc_page_flip(struct drm_crtc *crtc, struct drm_f
2013/1/15 Sean Paul :
> Remove the "internal" interrupt handling since it's never invoked and
Right, internal interrupt handler isn't used yet. It's better to add
when used actually. And below is my comment.
> remove "external" reference. This patch removes a bunch of dead code
> and clarifies h
Applied.
Thanks,
Inki Dae
2013/1/15 Sean Paul :
> Replace the unnecessary atomic mdelay calls with usleep_range calls.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 14 +++---
> drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
> 2 files changed, 8 insert
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130116/8b0ecfbf/attachment.html>
When we are using memcpy to move objects around, and we fail to memcpy
due to lack of memory to populate or failure to finish the copy, we don't
want to destroy the mm_node that has been copied into old_copy.
While working on a new kms driver that uses memcpy, if I overallocated bo's
up to the mem
On 15.01.2013 20:44, Stephen Warren wrote:
>> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
>> b/arch/arm/mach-tegra/board-dt-tegra20.c
>
>> +OF_DEV_AUXDATA("nvidia,tegra20-gr2d", 0x5414, "gr2d", NULL),
>
> I assume the only reason to add AUXDATA is to give the device a specific
>
if we have a move notify callback, when moving fails, we call move notify
the opposite way around, however this ends up with *mem containing the mm_node
from the bo, which means we double free it. This is a follow on to the previous
fix.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.
2013/1/15 Maarten Lankhorst :
> This type of fence can be used with hardware synchronization for simple
> hardware that can block execution until the condition
> (dma_buf[offset] - value) >= 0 has been met.
>
> A software fallback still has to be provided in case the fence is used
> with a device t
On 15.01.2013 20:44, Stephen Warren wrote:
> On 01/15/2013 04:26 AM, Terje Bergstrom wrote:
>> Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
>> of 2D clock to that driver alias.
>
> FYI on this one patch - it won't be applied to the Tegra tree until
> after Prashant's common
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130116/152d5533/attachment.html>
On Mon, 14 Jan 2013, Jiri Slaby wrote:
> On 01/14/2013 01:56 PM, Rafael J. Wysocki wrote:
>> On Monday, January 14, 2013 11:11:52 AM Jiri Slaby wrote:
>>> Hi,
>>>
>>> since friday's -next (the last known to be working is the last monday's)
>>> I cannot resume from suspend. The last thing I see wit
On Tue, Jan 15, 2013 at 9:17 PM, Thierry Reding
wrote:
> On Tue, Jan 15, 2013 at 06:53:19PM +0100, Daniel Vetter wrote:
>> On Mon, Jan 14, 2013 at 4:55 PM, Thierry Reding
>> wrote:
>> > +static void tegra_drm_preclose(struct drm_device *drm, struct drm_file
>> > *file)
>> > +{
>> > + struc
On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
>
> gem_prime_pin: callback when
limited experience, but
> > I'll see if I can make some time to take a look.
>
> The commit message should nicely explain why I've picked the design
> and the various implications for drivers. So just checking whether
> anything collides with your upcoming stuff would be good ...
Okay, I'll take a closer look.
Thierry
-- 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/20130116/faea1311/attachment-0001.pgp>
On 01/16/2013 10:20 AM, Jani Nikula wrote:
> Hi Jiri, the dmesgs for both cases with drm.debug=0xe module param might
> give us some clues.
>
> Does it work without no_console_suspend?
Hi, no, it does not work either way. But what I found out with debug
enabled, that it's a completely different p
Op 16-01-13 07:28, Inki Dae schreef:
> 2013/1/15 Maarten Lankhorst :
>> This type of fence can be used with hardware synchronization for simple
>> hardware that can block execution until the condition
>> (dma_buf[offset] - value) >= 0 has been met.
>>
>> A software fallback still has to be provided
I'm testing the pageflip & vblank change on cardhu. Seems the HDMI
doesn't work(LVDS only is OK). I'll let you know if I get something.
Mark
On 01/15/2013 12:06 AM, Thierry Reding wrote:
> All the necessary support bits like .mode_set_base() and VBLANK are now
> available, so page-flipping case ea
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130116/f65db18f/attachment.html>
Am Mittwoch, den 16.01.2013, 19:10 +0800 schrieb Mark Zhang:
> I'm testing the pageflip & vblank change on cardhu. Seems the HDMI
> doesn't work(LVDS only is OK). I'll let you know if I get something.
>
Just to provide another data point: I'm running this series and don't
see any failures with DVI
2013/1/16 Maarten Lankhorst :
> Op 16-01-13 07:28, Inki Dae schreef:
>> 2013/1/15 Maarten Lankhorst :
>>> This type of fence can be used with hardware synchronization for simple
>>> hardware that can block execution until the condition
>>> (dma_buf[offset] - value) >= 0 has been met.
>>>
>>> A soft
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher (1):
radeon: add new SI pci id
Ben Skeggs (2):
nouveau: disallow pushbuf BOs in multiple memory types
nouveau: expose channel engine selection on kepler chipsets
Chris Wilson (1):
intel: Remove the fence count con
On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
wrote:
> drm_events_release() should be enough to clean up the events, but I
> suspect the reason why Laurent put that code in was that the drm_crtc
> private data still has a reference to the event and needs to clear it.
> Otherwise the next page f
On Mon, Jan 14, 2013 at 03:30:22PM +0100, Thierry Reding wrote:
> Add generic helpers to pack HDMI infoframes into binary buffers.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - add support for audio, vendor-specific and SPD infoframes
> - add various validity checks on infoframes
>
On Wed, Jan 16, 2013 at 6:36 AM, Daniel Vetter wrote:
> On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
> wrote:
>> drm_events_release() should be enough to clean up the events, but I
>> suspect the reason why Laurent put that code in was that the drm_crtc
>> private data still has a reference t
Op 16-01-13 13:19, Maarten Lankhorst schreef:
> ...
> Jesse Barnes (1):
> man: disable man page building until David saves us all
>
Looks like this commit might break building if you don't build against git
directly, since it's not included in the tarball.
The fix for this is removing man/M
All those functions only scan a predefined EDID block and have no need
to alter anything. Constify the passed in struct edid pointer to reflect
this in the interface.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/drm_edid.c | 73 --
include/drm/drm_cr
Check if sink is HDMI capable when enabling an output. This disables
HDMI audio/infoframes if we are talking to a plain DVI sink. All things
except this check are already in place.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
Remove the "internal" interrupt handling since it's never invoked and
remove "external" reference. This patch removes a bunch of dead code
and clarifies how hotplugging is handled in the HDMI driver.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 74 ++-
scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130116/c9ea0d24/attachment.pgp>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130116/4786a6ec/attachment.pgp>
1 - 100 of 131 matches
Mail list logo
