Hi Rebecca,
On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
> I have a system where the data is planar, but the kernel drivers
> expect to get one allocation with offsets for the planes. I can't
> figure out how to do that with the current dma_buf implementation. I
> thought I could pas
On Mon June 4 2012 23:58:07 Hans Verkuil wrote:
> Hi Rebecca,
>
> On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
> > I have a system where the data is planar, but the kernel drivers
> > expect to get one allocation with offsets for the planes. I can't
> > figure out how to do that with
https://bugzilla.kernel.org/show_bug.cgi?id=37112
--- Comment #9 from Hrvoje Senjan 2012-06-05
06:33:47 ---
(In reply to comment #6)
> (In reply to comment #5)
> > My first guess is , that kernel changes memory clock too low - with fglrx
> > lowest memory clock is at 400MHz , but with radeo
https://bugs.freedesktop.org/show_bug.cgi?id=49322
--- Comment #4 from Brian Schott 2012-06-04 23:15:11
PDT ---
Still present in kernel 3.5-rc1
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee f
It probably is a fixed offset, but all the information describing it
is in userspace... In my experience, it's always almost one of the
pre-defined formats, but then there's some extra padding, weird
alignment etc. I'm trying to convert code that used userptr, but
where the planes were offsets in
On 4 June 2012 14:43, Ben Widawsky wrote:
> Based off of a patch from Ken Graunke. I just modified it for a more
> modern mesa (also don't allow contexts on blit ring).
>
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/brw_context.c|1 +
> src/mesa/drivers/dri/i965/b
Also the data_offset field (and bytes_used field) only get copied
from the v4l2_buffer into the vb2_buffer struct if the buffer is an
output buffer.
Rebecca
On Mon, Jun 4, 2012 at 1:46 PM, Rebecca Schultz Zavin
wrote:
> I'm trying to do it in my drivier, but I'm not sure how to make it
> safe s
I'm trying to do it in my drivier, but I'm not sure how to make it
safe since there is no way to tell the kernel the total size of the
buffer. From what I can tell, I can't sanity check that the offset
and lengths are within the buffer without adding a field.
Rebecca
On Mon, Jun 4, 2012 at 1:28
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the current dma_buf implementation. I
thought I could pass the same dma_buf several times and use the
data_offset field of the v4l2_pla
>
> I've run these on various workloads and saw nothing worth mentioning.
Nothing at all? no speedups, slowdowns, etc
why should we merge all this code then :-)
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.o
On 04.06.2012 21:54, Daniel Vetter wrote:
>
> In i915-land we're trying to make things Just Work. If needed we can
> expose (generation/platform-specific) tunables in sysfs. But on snb and
> later the combination of rc6+gpu turbo (mostly handled all by hw) is
> rather ok, so I don't see anything go
On 04.06.2012 20:29, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse wrote:
>>>
>>> Yeah, I get your point as a kernel dev, but I pitty the userspace dev that
>>> will need to figure out how to use all these ioctls and configuration
>>> options.
>> My point there is that we do
On Mon, Jun 04, 2012 at 02:18:00PM -0400, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres wrote:
> > Answers inlined.
> >
> > Le 04/06/2012 19:19, Jerome Glisse a ?crit :
> >
> >>
> >> My point is that there is no way for power management to find an API
> >> that fits all GPU.
Hi Dave,
Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes
this branch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 47819ba234d41465b76f179ba674ff549255a5d2
this patch set had bee
https://bugs.freedesktop.org/show_bug.cgi?id=27314
--- Comment #68 from Rafael Ávila de Espíndola
2012-06-04 21:05:29 PDT ---
I don't know exactly what changed, but I just installed fedora 17 and after
updating the kernel kms is working! :-)
--
Configure bugmail: https://bugs.freedesktop.org/u
https://bugs.freedesktop.org/show_bug.cgi?id=50696
--- Comment #1 from Alex Deucher 2012-06-04 14:03:23 PDT
---
should be fixed with this patch:
http://lists.freedesktop.org/archives/dri-devel/2012-June/023783.html
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=50696
Bug #: 50696
Summary: HDMI Audio is Choppy on RS880M / 4200
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
It probably is a fixed offset, but all the information describing it
is in userspace... In my experience, it's always almost one of the
pre-defined formats, but then there's some extra padding, weird
alignment etc. I'm trying to convert code that used userptr, but
where the planes were offsets in
Many TVs and A/V receivers don't work with this bit set. Problem was
confirmed using: Onkyo TX-SR605, Sony BRAVIA KDL-52X3500, Sony BRAVIA
KDL-40S40xx. In theory this bit shouldn't affect audio engine when
feeding it with data, however it seems it does. Driver fglrx doesn't set
that bit in any of t
Answers inlined.
Le 04/06/2012 19:19, Jerome Glisse a ?crit :
>
> My point is that there is no way for power management to find an API
> that fits all GPU. If i were to do it now, i would have one ioctl
> version for r3xx, one for r5xx, one for r6xx/r7xx, one for r8xx, one
> for r9xx, ... yes ther
On Mon, 04 Jun 2012 18:18:10 +0200
Christian K?nig wrote:
> > My experience is that things that are true today for GPU, are not
> > tomorrow. Yes there will still be clock/voltage, but there could be
> > new complete different things, like shutting down block.
> >
> > I am not even mentioning thin
Le 04/06/2012 17:18, Jerome Glisse a ?crit :
>
> My experience is that things that are true today for GPU, are not
> tomorrow. Yes there will still be clock/voltage, but there could be
> new complete different things, like shutting down block.
IMO, this isn't something the user should ever be aware
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #7 from Bryan Quigley 2012-06-04 18:50:08
UTC ---
Just upgrading Mesa (which does pull in libdrm upgrades) causes the bug.. even
on the 3.2 kernel without Xorg/Drivers upgraded... I think this confirms it is
mesa bug..
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #7 from Bryan Quigley 2012-06-04
18:50:08 UTC ---
Just upgrading Mesa (which does pull in libdrm upgrades) causes the bug.. even
on the 3.2 kernel without Xorg/Drivers upgraded... I think this confirms it is
mesa bug..
--
Configure
This is based on info released by AMD, should allow using audio in much
more cases.
Signed-off-by: Rafa? Mi?ecki
Cc:
---
drivers/gpu/drm/radeon/r600_audio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon
On 04.06.2012 17:18, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 11:02 AM, Martin Peres wrote:
>> Le 04/06/2012 16:31, Jerome Glisse a ?crit :
>>
>>> I don't think sysfs is the way to go, i am pretty sure that power
>>> management will change drasticly again in the future especialy btw
>>> discr
From: Alex Deucher
Call it in the asic startup callback on all asics.
Previously r600 and rv770 called it in the startup
and resume callbacks while all the other asics called
it in the startup callback.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c | 15 ++-
driv
Le 04/06/2012 16:31, Jerome Glisse a ?crit :
>
> I don't think sysfs is the way to go, i am pretty sure that power
> management will change drasticly again in the future especialy btw
> discret and integrated GPU. I would rather have hardware specific
> ioctl.
>
> Cheers,
> Jerome
Any particular id
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c|2 --
drivers/gpu/drm/gma500/cdv_intel_lvds.c |8
drivers/gpu/drm/gma500/mdfld_dsi_output.c |5 -
drivers/gpu/drm/gma500/psb_intel_lvds.c |9 -
drivers/gpu/drm/i915/intel_lvds.c
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |9 +
include/drm/drm_crtc.h |4
2 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c3b5139..c278f2d 100644
--- a/drivers/gpu/drm/drm_edid
On Mon, Jun 04, 2012 at 09:24:19AM +0800, Dave Young wrote:
> On 06/01/2012 10:32 PM, Daniel Vetter wrote:
>
> > On Fri, Jun 01, 2012 at 02:21:25PM +0800, Dave Young wrote:
> >> Today I got a lot i915 warnings on a thinkpad t400, here is the something
> >> copied from syslog:
> >> [Known issue?]
On Mon, 4 Jun 2012 16:01:54 -0700
Paul Berry wrote:
> On 4 June 2012 14:43, Ben Widawsky wrote:
>
> > Based off of a patch from Ken Graunke. I just modified it for a more
> > modern mesa (also don't allow contexts on blit ring).
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > src/mesa/drivers
On Mon, 4 Jun 2012 16:01:54 -0700
Paul Berry wrote:
> On 4 June 2012 14:43, Ben Widawsky wrote:
>
> > Based off of a patch from Ken Graunke. I just modified it for a more
> > modern mesa (also don't allow contexts on blit ring).
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > src/mesa/drivers
t lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
I'm kind of surprised to see a call to drm_intel_gem_context_create(), but
no call anywhere to a clean-up function that destroys the context. Was
that an oversight, or is there a reason why it's unnecessary? If it's the
latter, a comment in brw_destroy_context() would be helpful.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120604/440ec69f/attachment-0001.htm>
On Mon, Jun 4, 2012 at 2:18 PM, Rafa? Mi?ecki wrote:
> Many TVs and A/V receivers don't work with this bit set. Problem was
> confirmed using: Onkyo TX-SR605, Sony BRAVIA KDL-52X3500, Sony BRAVIA
> KDL-40S40xx. In theory this bit shouldn't affect audio engine when
> feeding it with data, however i
Hi Rebecca,
On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
> I have a system where the data is planar, but the kernel drivers
> expect to get one allocation with offsets for the planes. I can't
> figure out how to do that with the current dma_buf implementation. I
> thought I could pas
Based off of a patch from Ken Graunke. I just modified it for a more
modern mesa (also don't allow contexts on blit ring).
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_context.c|1 +
src/mesa/drivers/dri/i965/brw_vtbl.c |5 -
src/mesa/drivers/dri/in
Signed-off-by: Ben Widawsky
---
intel/intel_decode.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index bf23706..5f90a47 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -139,6 +139,22 @@ instr_
To support this we extract the common execbuf2 functionality to be
called with, or without contexts.
The context'd execbuf does not support some of the dri1 stuff.
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr.h |5 +
intel/intel_bufmgr_gem.c | 32 +---
Add an opaque type representing a HW context.
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_priv.h |5 +
2 files changed, 6 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index c197abc..83a43cb 100644
--- a/intel/intel_buf
Signed-off-by: Ben Widawsky
---
include/drm/i915_drm.h | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 6d9a9f1..0ca2d4f 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -192,6 +
The patches have already been sucked in to the kernel. So we need a
placeholder for this IOCTL until the libdrm wait render patches land.
---
include/drm/i915_drm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index af3ce17..6d9a9f1 100644
Setting myself up for a late night crying session once again. Most of the
people reading this probably know the history and reasons for the patches. If
not, you can search the intel-gfx mailing list to try to learn more. I won't
recap the whole thing here, and instead let the patches speak for them
Based off of a patch from Ken Graunke. I just modified it for a more
modern mesa (also don't allow contexts on blit ring).
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_context.c|1 +
src/mesa/drivers/dri/i965/brw_vtbl.c |5 -
src/mesa/drivers/dri/in
Signed-off-by: Ben Widawsky
---
intel/intel_decode.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index bf23706..5f90a47 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -139,6 +139,22 @@ instr_
To support this we extract the common execbuf2 functionality to be
called with, or without contexts.
The context'd execbuf does not support some of the dri1 stuff.
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr.h |5 +
intel/intel_bufmgr_gem.c | 32 +---
Add an opaque type representing a HW context.
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_priv.h |5 +
2 files changed, 6 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index c197abc..83a43cb 100644
--- a/intel/intel_buf
Signed-off-by: Ben Widawsky
---
include/drm/i915_drm.h | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 6d9a9f1..0ca2d4f 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -192,6 +
The patches have already been sucked in to the kernel. So we need a
placeholder for this IOCTL until the libdrm wait render patches land.
---
include/drm/i915_drm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index af3ce17..6d9a9f1 100644
Setting myself up for a late night crying session once again. Most of the
people reading this probably know the history and reasons for the patches. If
not, you can search the intel-gfx mailing list to try to learn more. I won't
recap the whole thing here, and instead let the patches speak for them
Le 04/06/2012 13:30, Christian K?nig a ?crit :
> On 04.06.2012 10:44, Lauri Kasanen wrote:
>> So the issue is the location of the info, not the format. I'd be more
>> than happy to split it into six files (default_core_clock,
>> current_core_clock...) that each offer just a kHz number, just like
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #6 from Bryan Quigley 2012-06-04
07:37:58 PDT ---
I did test with a 3.2 and the same 3.4 kernel and the stable mesa/X/drivers
that came with Precise. This did not cause a crash..
I think I tested with 3.2 and the git mesa/X/drivers
On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres wrote:
>> Answers inlined.
>>
>> Le 04/06/2012 19:19, Jerome Glisse a ?crit :
>>
>>>
>>> My point is that there is no way for power management to find an API
>>> that fits all GPU. If i were to do
From: Alex Deucher
Call it in the asic startup callback on all asics.
Previously r600 and rv770 called it in the startup
and resume callbacks while all the other asics called
it in the startup callback.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c | 15 ++-
driv
On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres wrote:
> Answers inlined.
>
> Le 04/06/2012 19:19, Jerome Glisse a ?crit :
>
>>
>> My point is that there is no way for power management to find an API
>> that fits all GPU. If i were to do it now, i would have one ioctl
>> version for r3xx, one for r5x
can you check expected size vs dmabuf->size - offset?
On Tue, Jun 5, 2012 at 4:46 AM, Rebecca Schultz Zavin
wrote:
> I'm trying to do it in my drivier, but I'm not sure how to make it
> safe since there is no way to tell the kernel the total size of the
> buffer. From what I can tell, I can't sa
https://bugs.freedesktop.org/show_bug.cgi?id=50696
--- Comment #1 from Alex Deucher 2012-06-04 14:03:23 PDT ---
should be fixed with this patch:
http://lists.freedesktop.org/archives/dri-devel/2012-June/023783.html
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=50696
Bug #: 50696
Summary: HDMI Audio is Choppy on RS880M / 4200
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Also the data_offset field (and bytes_used field) only get copied
from the v4l2_buffer into the vb2_buffer struct if the buffer is an
output buffer.
Rebecca
On Mon, Jun 4, 2012 at 1:46 PM, Rebecca Schultz Zavin
wrote:
> I'm trying to do it in my drivier, but I'm not sure how to make it
> safe s
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c|2 --
drivers/gpu/drm/gma500/cdv_intel_lvds.c |8
drivers/gpu/drm/gma500/mdfld_dsi_output.c |5 -
drivers/gpu/drm/gma500/psb_intel_lvds.c |9 -
drivers/gpu/drm/i915/intel_lvds.c
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |9 +
include/drm/drm_crtc.h |4
2 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c3b5139..c278f2d 100644
--- a/drivers/gpu/drm/drm_edid
That's probably safest, however on Intel we can change the stride and
tiling format for sync flips at least. But I'm ok with this patch; we
generally need to recalculate bw requirements and watermarks when
adjusting depth and such.
On Thu, 31 May 2012 15:54:03 -0400
Alex Deucher wrote:
> On Thu
I'm trying to do it in my drivier, but I'm not sure how to make it
safe since there is no way to tell the kernel the total size of the
buffer. From what I can tell, I can't sanity check that the offset
and lengths are within the buffer without adding a field.
Rebecca
On Mon, Jun 4, 2012 at 1:28
That's probably safest, however on Intel we can change the stride and
tiling format for sync flips at least. But I'm ok with this patch; we
generally need to recalculate bw requirements and watermarks when
adjusting depth and such.
On Thu, 31 May 2012 15:54:03 -0400
Alex Deucher wrote:
> On Thu
On 04.06.2012 21:54, Daniel Vetter wrote:
In i915-land we're trying to make things Just Work. If needed we can
expose (generation/platform-specific) tunables in sysfs. But on snb and
later the combination of rc6+gpu turbo (mostly handled all by hw) is
rather ok, so I don't see anything going abo
On 04.06.2012 20:29, Jerome Glisse wrote:
On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse wrote:
Yeah, I get your point as a kernel dev, but I pitty the userspace dev that
will need to figure out how to use all these ioctls and configuration
options.
My point there is that we do the userspace b
Some comments inline.. at this stage mostly superficial issues about
how the API works, etc.. not had a chance to dig too much into the
implementation yet (although some of my comments about the API would
change those anyways).
Anyways, thanks for getting the ball rolling on this, and I think I
c
On 04.06.2012 10:44, Lauri Kasanen wrote:
> On Sun, 03 Jun 2012 12:54:30 +0200
> Christian K?nig wrote:
>
>>> This moves the pm_info file from debugfs to next to the other two power
>>> files.
>>>
>>> Requested by several users at Phoronix.
>>>
>>> PS: Please CC me. Also please be gentle, it's my
this is at least how we do it w/ drm/kms.. I would expect that if you
could do that w/ output for v4l you also could for input, but perhaps
the individual driver needs to do something to support mplane? I
guess the v4l folks would know better
BR,
-R
On Tue, Jun 5, 2012 at 3:34 AM, Rebecca Schult
On Mon, Jun 4, 2012 at 1:01 PM, Martin Peres wrote:
> Le 04/06/2012 17:18, Jerome Glisse a ?crit :
>
>>
>> My experience is that things that are true today for GPU, are not
>> tomorrow. Yes there will still be clock/voltage, but there could be
>> new complete different things, like shutting down b
On Mon, Jun 4, 2012 at 12:29 PM, Lauri Kasanen wrote:
> On Mon, 04 Jun 2012 18:18:10 +0200
> Christian K?nig wrote:
>> > My experience is that things that are true today for GPU, are not
>> > tomorrow. Yes there will still be clock/voltage, but there could be
>> > new complete different things, l
On Mon, Jun 04, 2012 at 02:18:00PM -0400, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres wrote:
> > Answers inlined.
> >
> > Le 04/06/2012 19:19, Jerome Glisse a écrit :
> >
> >>
> >> My point is that there is no way for power management to find an API
> >> that fits all GPU.
On Mon, Jun 4, 2012 at 12:36 PM, Rafa? Mi?ecki wrote:
> This is based on info released by AMD, should allow using audio in much
> more cases.
>
> Signed-off-by: Rafa? Mi?ecki
> Cc:
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/r600_audio.c | ? ?5 +++--
> ?1 files changed, 3 insert
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the current dma_buf implementation. I
thought I could pass the same dma_buf several times and use the
data_offset field of the v4l2_pla
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #5 from Alex Deucher 2012-06-04 05:33:01 PDT
---
Would it be possible to narrow down which component (kernel, ddx, or mesa) is
causing the problem and bisect? I'd guess it's a mesa issue.
--
Configure bugmail: https://bugs.freedes
On Mon, Jun 4, 2012 at 2:18 PM, Rafał Miłecki wrote:
> Many TVs and A/V receivers don't work with this bit set. Problem was
> confirmed using: Onkyo TX-SR605, Sony BRAVIA KDL-52X3500, Sony BRAVIA
> KDL-40S40xx. In theory this bit shouldn't affect audio engine when
> feeding it with data, however i
Linear copy works by adding the offset to the buffer address,
which may end up not being 16-byte aligned.
Some tests I've written for prime_pcopy show that the engine
allows this correctly, so the restriction on lowest 4 bits of
address can be lifted safely.
The comments added were by envyas, I t
On Sun, 03 Jun 2012 12:54:30 +0200
Christian K?nig wrote:
> > This moves the pm_info file from debugfs to next to the other two power
> > files.
> >
> > Requested by several users at Phoronix.
> >
> > PS: Please CC me. Also please be gentle, it's my first step in kernel-land
> > ;)
> Hui? What
On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres wrote:
>> Answers inlined.
>>
>> Le 04/06/2012 19:19, Jerome Glisse a écrit :
>>
>>>
>>> My point is that there is no way for power management to find an API
>>> that fits all GPU. If i were to do
Many TVs and A/V receivers don't work with this bit set. Problem was
confirmed using: Onkyo TX-SR605, Sony BRAVIA KDL-52X3500, Sony BRAVIA
KDL-40S40xx. In theory this bit shouldn't affect audio engine when
feeding it with data, however it seems it does. Driver fglrx doesn't set
that bit in any of t
On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres wrote:
> Answers inlined.
>
> Le 04/06/2012 19:19, Jerome Glisse a écrit :
>
>>
>> My point is that there is no way for power management to find an API
>> that fits all GPU. If i were to do it now, i would have one ioctl
>> version for r3xx, one for r5x
On Mon, Jun 4, 2012 at 11:02 AM, Martin Peres wrote:
> Le 04/06/2012 16:31, Jerome Glisse a ?crit :
>
>>
>> I don't think sysfs is the way to go, i am pretty sure that power
>> management will change drasticly again in the future especialy btw
>> discret and integrated GPU. I would rather have har
On 05/31/2012 10:08 AM, Sascha Hauer wrote:
> [...]
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
> new file mode 100644
> index 000..d8c0dc7
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -0,0 +1,243 @@
> +/*
> + * drm gem cma (co
https://bugs.freedesktop.org/show_bug.cgi?id=50657
--- Comment #2 from Thomas Lindroth 2012-06-04
04:03:45 PDT ---
I get a similar error in Psychonauts from the humble bundle. It fails every
time and give a slightly different error in dmesg. I applied the patch from
here https://bugzilla.icculus
https://bugs.freedesktop.org/show_bug.cgi?id=50657
--- Comment #1 from Thomas Lindroth 2012-06-04
04:00:47 PDT ---
Created attachment 62497
--> https://bugs.freedesktop.org/attachment.cgi?id=62497
dmesg, Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
Answers inlined.
Le 04/06/2012 19:19, Jerome Glisse a écrit :
My point is that there is no way for power management to find an API
that fits all GPU. If i were to do it now, i would have one ioctl
version for r3xx, one for r5xx, one for r6xx/r7xx, one for r8xx, one
for r9xx, ... yes there would
On 05/31/2012 08:11 PM, Sascha Hauer wrote:
> On Thu, May 31, 2012 at 11:34:37AM +0200, Lars-Peter Clausen wrote:
+ drm_helper_mode_fill_fb_struct(&fb_cma->fb, mode_cmd);
+
+ for (i = 0; i < num_planes; i++)
+ fb_cma->obj[i] = obj[i];
>>>
>>> Check for valid num_plane
https://bugs.freedesktop.org/show_bug.cgi?id=50618
--- Comment #7 from Andy Furniss 2012-06-04
03:39:30 PDT ---
(In reply to comment #3)
> I use a "real card" so even if 40mbit worked for me, it wouldn't mean anything
> for you I guess.
>
> I'll make one and try soon - AFK for tonight.
I trie
On Mon, Jun 4, 2012 at 8:40 AM, Martin Peres wrote:
> Le 04/06/2012 13:30, Christian K?nig a ?crit :
>>
>> On 04.06.2012 10:44, Lauri Kasanen wrote:
>>>
>>> So the issue is the location of the info, not the format. I'd be more
>>> than happy to split it into six files (default_core_clock,
>>> curr
On Mon, Jun 4, 2012 at 1:01 PM, Martin Peres wrote:
> Le 04/06/2012 17:18, Jerome Glisse a écrit :
>
>>
>> My experience is that things that are true today for GPU, are not
>> tomorrow. Yes there will still be clock/voltage, but there could be
>> new complete different things, like shutting down b
https://bugs.freedesktop.org/show_bug.cgi?id=50618
--- Comment #6 from Pasi K?rkk?inen 2012-06-04 03:18:50 PDT
---
(In reply to comment #5)
> Those integrated chipsets like IGPs and APUs current don't have a full power
> management implementation. So they are running with whatever is the (very
On Mon, Jun 4, 2012 at 12:29 PM, Lauri Kasanen wrote:
> On Mon, 04 Jun 2012 18:18:10 +0200
> Christian König wrote:
>> > My experience is that things that are true today for GPU, are not
>> > tomorrow. Yes there will still be clock/voltage, but there could be
>> > new complete different things, l
Le 04/06/2012 17:18, Jerome Glisse a écrit :
My experience is that things that are true today for GPU, are not
tomorrow. Yes there will still be clock/voltage, but there could be
new complete different things, like shutting down block.
IMO, this isn't something the user should ever be aware of.
On Mon, Jun 4, 2012 at 12:36 PM, Rafał Miłecki wrote:
> This is based on info released by AMD, should allow using audio in much
> more cases.
>
> Signed-off-by: Rafał Miłecki
> Cc:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_audio.c | 5 +++--
> 1 files changed, 3 insert
This is based on info released by AMD, should allow using audio in much
more cases.
Signed-off-by: Rafał Miłecki
Cc:
---
drivers/gpu/drm/radeon/r600_audio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon
On Mon, 04 Jun 2012 18:18:10 +0200
Christian König wrote:
> > My experience is that things that are true today for GPU, are not
> > tomorrow. Yes there will still be clock/voltage, but there could be
> > new complete different things, like shutting down block.
> >
> > I am not even mentioning thin
On 06/01/2012 10:32 PM, Daniel Vetter wrote:
> On Fri, Jun 01, 2012 at 02:21:25PM +0800, Dave Young wrote:
>> Today I got a lot i915 warnings on a thinkpad t400, here is the something
>> copied from syslog:
>> [Known issue?]
>
> The gpu refuses to clear the write fifo. Which means it pretty much
On 04.06.2012 17:18, Jerome Glisse wrote:
On Mon, Jun 4, 2012 at 11:02 AM, Martin Peres wrote:
Le 04/06/2012 16:31, Jerome Glisse a écrit :
I don't think sysfs is the way to go, i am pretty sure that power
management will change drasticly again in the future especialy btw
discret and integrat
Hi Emil,
we included "drm.h" with g2d driver patch instead of "
so your patch will be removed from exynos-drm-fixes. sorry for
confusing.
for this, you can refer to below link.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=include/drm/exynos_drm.h;h=b6d7ce92eadd67a67db
On Mon, Jun 4, 2012 at 7:30 AM, Christian K?nig
wrote:
> On 04.06.2012 10:44, Lauri Kasanen wrote:
>>
>> On Sun, 03 Jun 2012 12:54:30 +0200
>> Christian K?nig ?wrote:
>>
This moves the pm_info file from debugfs to next to the other two power
files.
Requested by several users a
1 - 100 of 125 matches
Mail list logo
