On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote:
> On Sat, Jun 8, 2013 at 1:43 AM, wrote:
> > From: Foo Bar
>
> ^ ??
>
> git config error?
Whoops. Sorry about that. I created the original patch on a test
machine where I apparently had been too lazy to set up my git
correctly. And
On Wednesday 05 June 2013 07:00:45 Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:44 AM, Daniel Vetter wrote:
> > On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
> >> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart wrote:
> >> > On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
> >> >> co
I was just clearing out some bookmarks in my browser and noticed that
#36602 is still open. Seems like you've had HiZ in r600 for a while, so
I was wondering if this bug can be closed? No new posts there since
September.
DW
p;os=4063&product=4217144&query=dv6-3030ew&tool=
--
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/20130607/3fd13938/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130607/d507d287/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/20130607/048f3464/attachment.html>
From: Ville Syrj?l?
The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
drm_connector_enum_list which does get modified in drm_connector_init().
While at it move the drm_get_connector_status_name() prototyp
From: Ville Syrj?l?
The string isn't modified so make it const.
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Ville Syrj?l?
---
drivers/video/fbmem.c | 2 +-
include/linux/fb.h| 2 +-
2 files changed, 2 insertions(+), 2 deletion
From: Ville Syrj?l?
Use drm_get_format_name to print more readable pixel format names
in debug output.
Also unify the debug messages to say "unsupported pixel format",
which better describes what is going on.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 12 -
From: Foo Bar
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() produces:
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130607/34ecf470/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130607/b1e26a26/attachment.html>
On Fri, Jun 07, 2013 at 06:43:07PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> The structures and strings involved with various pretty-print functions
> aren't meant to be modified, so make them all const. The exception is
> drm_connector_enum_list which does get mod
Hi all,
Came back :)
Please, ignore previous fence helper. I have re-implemented buffer
synchronization mechanism, dmabuf sync, based on DMA BUF and wound/wait
style lock v5[1] and tested it with 2d gpu and drm kms drivers.
The below is dmabuf sync framework codes,
https://git.kernel.org/cgit/l
eview ).
--
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/20130607/7e37230e/attachment.html>
On Sat, Jun 8, 2013 at 6:35 AM, Ville Syrjälä
wrote:
> On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote:
>> On Sat, Jun 8, 2013 at 1:43 AM, wrote:
>> > From: Foo Bar
>>
>> ^ ??
>>
>> git config error?
>
> Whoops. Sorry about that. I created the original patch on a test
> machine wher
On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote:
> On Sat, Jun 8, 2013 at 1:43 AM, wrote:
> > From: Foo Bar
>
> ^ ??
>
> git config error?
Whoops. Sorry about that. I created the original patch on a test
machine where I apparently had been too lazy to set up my git
correctly. And
Op 07-06-13 04:32, ??? schreef:
> Hello Maarten,
>
> On 2013? 06? 05? 22:23, Maarten Lankhorst wrote:
>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
>>> dma-buf attachment has only exporter private data, but importer private data
>>> can be useful for importer especially to re-import the same dma-buf
On Sat, Jun 8, 2013 at 1:43 AM, wrote:
> From: Foo Bar
^ ??
git config error?
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wednesday 05 June 2013 07:00:45 Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:44 AM, Daniel Vetter wrote:
> > On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
> >> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart wrote:
> >> > On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
> >> >> co
https://bugs.freedesktop.org/show_bug.cgi?id=65091
--- Comment #2 from Kamil Bar ---
And I need to correct my first post, on auto/low/mid/default profiles voltage
is 900 mV, but if I switch to high my screen flick, and it goes to 1000 mv.
I cannot attach video bios, because my notebook has vbios
https://bugs.freedesktop.org/show_bug.cgi?id=65091
Kamil Bar changed:
What|Removed |Added
Version|unspecified |DRI CVS
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=65091
--- Comment #1 from Kamil Bar ---
Created attachment 80495
--> https://bugs.freedesktop.org/attachment.cgi?id=80495&action=edit
dmesg | grep radeon after drm.debug=2 and some profile switching
--
You are receiving this mail because:
You are t
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 317 ++-
include/drm/drm_gem_cma_helper.h | 9 +
2 files changed, 323 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_he
The CMA-specific mapping code will be used to implement dma-buf mmap
support.
Signed-off-by: Laurent Pinchart
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem_cma_helper.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma
This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
---
drivers/gpu/drm/drm_gem_cma_helper.c | 83 +---
1 file changed, 48 insertion
The dma-buf mmap code was copied from the GEM mmap implementation.
Replace it with the new drm_gem_mmap_obj() function.
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 32 +++
1 file changed, 3 insertions(+), 29
The drm_gem_mmap() function first finds the GEM object to be mapped
based on the fake mmap offset and then maps the object. Split the object
mapping code into a standalone drm_gem_mmap_obj() function that can be
used to implement dma-buf mmap() operations.
Signed-off-by: Laurent Pinchart
Reviewed
Hello,
Here's the third version of the GEM CMA DMA-BUF support patches. Changes
compared to the previous version are minimal, there will hopefully not be any
need for a v4.
The code is based on the Exynos DRM DMA-BUF implementation. The exporter role
has been successfully tested with the Renesas
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #9 from wojtek ---
Created attachment 80493
--> https://bugs.freedesktop.org/attachment.cgi?id=80493&action=edit
reg_dump_fglrx_kernel39
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #8 from wojtek ---
Created attachment 80492
--> https://bugs.freedesktop.org/attachment.cgi?id=80492&action=edit
reg_dump_radeon_kernel39
--
You are receiving this mail because:
You are the assignee for the bug.
__
Hello Maarten,
On 2013? 06? 05? 22:23, Maarten Lankhorst wrote:
> Op 31-05-13 10:54, Seung-Woo Kim schreef:
>> dma-buf attachment has only exporter private data, but importer private data
>> can be useful for importer especially to re-import the same dma-buf.
>> To use importer private data in att
On Fri, Jun 07, 2013 at 09:23:58AM +0200, Laurent Pinchart wrote:
> On Thursday 06 June 2013 09:21:35 Alex Deucher wrote:
> > On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote:
> > > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote:
> > >> To me at least, it doesn't make sense that an encoder c
On Fri, Jun 07, 2013 at 09:44:45AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> > On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > > On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > > > On Tue, Jun 4, 2013 a
From: Alex Deucher
- remove adding 2 to checksum, this breaks certain monitors
- properly emit the AVI infoframe version, not emitting
the version breaks some monitors.
This should fix blank screen when HDMI audio is enabled on
certain monitors.
Signed-off-by: Alex Deucher
Cc: Rafa? Mi?ecki
-
i/Development/Documentation/ServerDebugging .
--
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/20130607/99ceb9c8/attachment.html>
2013-06-07 03:17 keltez?ssel, Aaron Lu ?rta:
> On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote:
>> Hi,
>>
>> we are working on an Intel Atom-based embedded PC and I have to
>> make suspend-to-RAM work but I can't seem to succeed.
>>
>> The symptom is that quite often, the machine resumes immediate
Hi Daniel,
On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > > On Tuesday 04 June 2013 16:12:36 Da
https://bugs.freedesktop.org/show_bug.cgi?id=65514
Priority: medium
Bug ID: 65514
Assignee: dri-devel@lists.freedesktop.org
Summary: Mesa can't render Google Maps WebGL preview in Firefox
Severity: normal
Classification: Unclassified
On Thu, Jun 6, 2013 at 5:55 PM, wrote:
> From: Jerome Glisse
>
> UVD ring can't use scratch thus it does need writeback buffer to keep
> a valid address or radeon_ring_backup will trigger a kernel fault.
>
> It's ok to not unpin the write back buffer on suspend as it leave in
> gtt and thus does
On 06/06/2013 06:47 PM, Tomasz Figa wrote:
> Hi Joonyoung,
>
> On Thursday 06 of June 2013 13:30:49 Joonyoung Shim wrote:
>> On 05/19/2013 08:32 PM, Tomasz Figa wrote:
>>> Hi,
>>>
>>> On Wednesday 01 of May 2013 22:00:25 Daniel Vetter wrote:
On Wed, May 01, 2013 at 09:06:09PM +0200, Tomasz Fig
On Thursday 06 June 2013 09:21:35 Alex Deucher wrote:
> On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote:
> > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote:
> >> To me at least, it doesn't make sense that an encoder can clone
> >> itself. If an encoder is already in use, trying to clone it
On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote:
> Hi,
>
> we are working on an Intel Atom-based embedded PC and I have to
> make suspend-to-RAM work but I can't seem to succeed.
>
> The symptom is that quite often, the machine resumes immediately
> after pm-suspend. Sometimes more than 20 times
On Fri, Jun 07, 2013 at 06:43:07PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The structures and strings involved with various pretty-print functions
> aren't meant to be modified, so make them all const. The exception is
> drm_connector_enum_list which does get modifie
From: Ville Syrjälä
The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
drm_connector_enum_list which does get modified in drm_connector_init().
While at it move the drm_get_connector_status_name() prototyp
From: Ville Syrjälä
Use drm_get_format_name to print more readable pixel format names
in debug output.
Also unify the debug messages to say "unsupported pixel format",
which better describes what is going on.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12 -
From: Ville Syrjälä
The string isn't modified so make it const.
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/fbmem.c | 2 +-
include/linux/fb.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-
From: Foo Bar
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() produces:
On Fri, Jun 7, 2013 at 5:44 AM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 317
> ++-
> include/drm/drm_gem_cma_helper.h | 9 +
> 2 files changed, 323 insertions(+), 3 d
From: Alex Deucher
- remove adding 2 to checksum, this breaks certain monitors
- properly emit the AVI infoframe version, not emitting
the version breaks some monitors.
This should fix blank screen when HDMI audio is enabled on
certain monitors.
Signed-off-by: Alex Deucher
Cc: Rafał Miłecki
-
On Thu, Jun 6, 2013 at 5:55 PM, wrote:
> From: Jerome Glisse
>
> UVD ring can't use scratch thus it does need writeback buffer to keep
> a valid address or radeon_ring_backup will trigger a kernel fault.
>
> It's ok to not unpin the write back buffer on suspend as it leave in
> gtt and thus does
On Thu, Jun 6, 2013 at 9:25 PM, Rob Clark wrote:
> On Thu, Jun 6, 2013 at 3:\
Why do you "need" drmOpen("omap")? Is it just a convention to use that
kind of name, instead of "omapdrm" style name?
>>>
>>> all of the /dev/dri/cardN get opened, and then DRM_IOCTL_VERSION ioctl
>>> to get th
On Fri, Jun 7, 2013 at 5:44 AM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 317
> ++-
> include/drm/drm_gem_cma_helper.h | 9 +
> 2 files changed, 323 insertions(+), 3 d
roperty on the intel output, but not
on the radeon output.
--
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/20130607/f4bee827/attachment.html>
Op 07-06-13 04:32, 김승우 schreef:
> Hello Maarten,
>
> On 2013년 06월 05일 22:23, Maarten Lankhorst wrote:
>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
>>> dma-buf attachment has only exporter private data, but importer private data
>>> can be useful for importer especially to re-import the same dma-buf
https://bugs.freedesktop.org/show_bug.cgi?id=65438
--- Comment #3 from Michel Dänzer ---
(In reply to comment #2)
> so can you provide me some help to do what you ask in gentoo?
I'm not familiar with Gentoo, but I'm sure there are many tutorials on Git
bisect on the 'net, there might even be one
The CMA-specific mapping code will be used to implement dma-buf mmap
support.
Signed-off-by: Laurent Pinchart
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem_cma_helper.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 317 ++-
include/drm/drm_gem_cma_helper.h | 9 +
2 files changed, 323 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_he
The dma-buf mmap code was copied from the GEM mmap implementation.
Replace it with the new drm_gem_mmap_obj() function.
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 32 +++
1 file changed, 3 insertions(+), 29
This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Clark
---
drivers/gpu/drm/drm_gem_cma_helper.c | 83 +---
1 file changed, 48 insertion
The drm_gem_mmap() function first finds the GEM object to be mapped
based on the fake mmap offset and then maps the object. Split the object
mapping code into a standalone drm_gem_mmap_obj() function that can be
used to implement dma-buf mmap() operations.
Signed-off-by: Laurent Pinchart
Reviewed
Hello,
Here's the third version of the GEM CMA DMA-BUF support patches. Changes
compared to the previous version are minimal, there will hopefully not be any
need for a v4.
The code is based on the Exynos DRM DMA-BUF implementation. The exporter role
has been successfully tested with the Renesas
Hi all,
Came back :)
Please, ignore previous fence helper. I have re-implemented buffer
synchronization mechanism, dmabuf sync, based on DMA BUF and wound/wait
style lock v5[1] and tested it with 2d gpu and drm kms drivers.
The below is dmabuf sync framework codes,
https://git.kernel.or
On Fri, Jun 07, 2013 at 09:23:58AM +0200, Laurent Pinchart wrote:
> On Thursday 06 June 2013 09:21:35 Alex Deucher wrote:
> > On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote:
> > > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote:
> > >> To me at least, it doesn't make sense that an encoder c
On Fri, Jun 07, 2013 at 09:44:45AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> > On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > > On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > > > On Tue, Jun 4, 2013 a
2013-06-07 03:17 keltezéssel, Aaron Lu írta:
On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote:
Hi,
we are working on an Intel Atom-based embedded PC and I have to
make suspend-to-RAM work but I can't seem to succeed.
The symptom is that quite often, the machine resumes immediately
after pm-sus
Hi Daniel,
On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > > On Tuesday 04 June 2013 16:12:36 Da
On Thursday 06 June 2013 09:21:35 Alex Deucher wrote:
> On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote:
> > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote:
> >> To me at least, it doesn't make sense that an encoder can clone
> >> itself. If an encoder is already in use, trying to clone it
68 matches
Mail list logo
