Properly set the parent device of DP i2c buses before registering them
too.
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
I'm sorry, my previous patch missed the fact that DP i2c buses are
handled separately so they need the same fix.
drivers/gpu/drm/radeon/radeon_i2c.c |
Hi Sumit,
> On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
[snip]
> static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> -struct sg_table *sg)
> + struct sg_table *sg, enum dma_data_direction w
https://bugs.freedesktop.org/show_bug.cgi?id=45432
Bug #: 45432
Summary: memory errors on cayman with VM support + nexuiz
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=45432
Dave Airlie changed:
What|Removed |Added
Keywords||regression
--
Configure bugmail: https://
On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote:
> Hi Sumit,
>
> > On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
>
> [snip]
>
> > static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> > *attach,
> > -struct
Hello,
When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
r600_fence_finish was taking 10% of my CPU time. I determined experimentally
that changing from sched_yield() to os_time_sleep(10) fixed thi
On Tue, Jan 31, 2012 at 3:55 AM, Jean Delvare wrote:
> Properly set the parent device of DP i2c buses before registering them
> too.
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
Reviewed-by: Alex Deucher
> ---
> I'm sorry, my previous patch missed the fact that DP i2c
On Mon, Jan 30, 2012 at 11:10 PM, Ilija Hadzic
wrote:
> copy_blit operation works only on integral number of pages
> so benchmarks shorter than one page size (4K) do not make sense
>
> v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and
> sweep sizes between 1x to 16x doubling
>
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
This code needs completion - in particular, we should fall back to
busywaiting (using the nokernel function that's in radeon_drm_bo.c) if the
kernel doesn't support the new interface.
On Tue, 31 Jan 2012, Alex Deucher wrote:
Signed-off-by: Ilija Hadzic
Reviewed-by: Alex Deucher
Thanks. There will be a v3, though to address one tirvial comment
(whitespace between binary '*' operator) that I received in E-mail sent
directly to me.
I guess the diff v2/v3 will be tr
On Tue, Jan 31, 2012 at 9:27 AM, Ilija Hadzic
wrote:
>
>
> On Tue, 31 Jan 2012, Alex Deucher wrote:
>
>>>
>>> Signed-off-by: Ilija Hadzic
>>
>>
>> Reviewed-by: Alex Deucher
>>
>
> Thanks. There will be a v3, though to address one tirvial comment
> (whitespace between binary '*' operator) that I
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
This currently doesn't work, hence the debug code piled in.
copy_blit operation works only on integral number of pages
so benchmarks shorter than one page size (4K) do not make sense
v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and
sweep sizes between 1 * to 16K * doubling
the size in each iteration; we get the same coverage, as
Alex Deucher pointed out an error on IRC; I'm not using
radeon_irq_kms_sw_irq_get and put to manage the IRQ enablement.
I've fixed this up (as per the partial hunk below), and my bug goes away. I
will be cleaning these patches up for proper submission.
Simon
On Tuesday 31 January 2012, Simon Far
On Tuesday 31 January 2012, Alan Swanson wrote:
> On Tue, 2012-01-31 at 13:16 +, Simon Farnsworth wrote:
> > Hello,
> >
> > When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
> > wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
> > r600_fence
On Tue, 2012-01-31 at 13:16 +, Simon Farnsworth wrote:
> Hello,
>
> When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
> wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
> r600_fence_finish was taking 10% of my CPU time. I determined experimen
On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston
wrote:
> This fixes a failure in 'make check' found by the tinderbox when trying to
> build this code on Linux/ppc. This code is only designed to run on
> Intel platforms, so don't even bother building it if we're not in that set.
Looks reas
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
I've been working on to
On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
> Userspace currently busywaits for fences to complete; on my workload, this
> busywait consumes 10% of the available CPU time.
>
> Provide an ioctl so that userspace can wait for an EOP interrupt that
> corresponds to a previous EVENT_WR
https://bugs.freedesktop.org/show_bug.cgi?id=30502
aceman changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31423
--- Comment #2 from aceman 2012-01-31 10:17:34 PST ---
On R600g, Mesa 8.0rc2 the stars seem to have proper colors.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Y
https://bugs.freedesktop.org/show_bug.cgi?id=28905
aceman changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Some comments below.
> + struct radeon_device *rdev = dev->dev_private;
> + struct drm_gem_object *gobj;
> + struct radeon_bo *robj;
> + void *buffer_data;
> + uint32_t *fence_data;
> + int r = 0;
> + long timeout;
> + int ring = RADEON_RING_TYPE_GFX_INDEX;
> +
>
On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel Dänzer wrote:
> On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
> > Userspace currently busywaits for fences to complete; on my workload, this
> > busywait consumes 10% of the available CPU time.
> >
> > Provide an ioctl so that userspac
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
>
>
> Some comments below.
>
> > + struct radeon_device *rdev = dev->dev_private;
> > + struct drm_gem_object *gobj;
> > + struct radeon_bo *robj;
> > + void *buffer_data;
> > + uint32_t *fence_data;
> > + int r = 0;
> > +
On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse wrote:
> On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
>>
>>
>> Some comments below.
>>
>> > + struct radeon_device *rdev = dev->dev_private;
>> > + struct drm_gem_object *gobj;
>> > + struct radeon_bo *robj;
>> > + void *buffe
On Tue, Jan 31, 2012 at 02:13:00PM -0500, Alex Deucher wrote:
> On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse wrote:
> > On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
> >>
> >>
> >> Some comments below.
> >>
> >> > + struct radeon_device *rdev = dev->dev_private;
> >> > + stru
2012/1/31 Jerome Glisse :
> On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel Dänzer wrote:
>> On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
>> > Userspace currently busywaits for fences to complete; on my workload, this
>> > busywait consumes 10% of the available CPU time.
>> >
>> > Pr
On Tue, 31 Jan 2012 10:34:38 -0800, Jeremy Huddleston
wrote:
>
> On Jan 31, 2012, at 8:59 AM, Eric Anholt wrote:
>
> > On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston
> > wrote:
> >> This fixes a failure in 'make check' found by the tinderbox when trying to
> >> build this code on Linux
On -10.01.-28163 20:59, Jerome Glisse wrote:
On Tue, Jan 31, 2012 at 02:13:00PM -0500, Alex Deucher wrote:
On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse wrote:
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
Some comments below.
+ struct radeon_device *rdev = dev->dev_priv
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #11 from Alexandre Demers 2012-01-31
16:35:53 PST ---
(In reply to comment #10)
> (In reply to comment #9)
> > The bugs is not visible under kernel 3.2, [...]
>
> 3.2 lacks Radeon virtual address space support.
>
> > I will try wit
https://bugs.freedesktop.org/show_bug.cgi?id=45473
Bug #: 45473
Summary: vdpau-r300 requires softpipe
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #4 from Ian Romanick 2012-01-31 22:25:22 PST
---
(In reply to comment #2)
> Can you upgrade to a DDX from -git?
>
> I think the fix is in there, it was allocating too small depth buffers.
I can, but it won't be until next week. I'
On Jan 31, 2012, at 8:59 AM, Eric Anholt wrote:
> On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston
> wrote:
>> This fixes a failure in 'make check' found by the tinderbox when trying to
>> build this code on Linux/ppc. This code is only designed to run on
>> Intel platforms, so don't even
On Fri, Jan 20, 2012 at 05:08:31PM -0600, Seth Forshee wrote:
> > Can you track down who is calling the connector->detect() callbacks
> > during suspend and resume?
>
> I got two different stack traces, see below.
>
> And to slightly amend my statement above, I'm only seeing the wrong
> status re
t( }
> >
> > static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> > *attach, -struct sg_table
*sg)
> > + struct sg_table *sg, enum dma_data_direction
write)
>
> s/write/dir/ (or direction) ?
>
:-) sure.
> > {
> > return;
> > }
>
> --
> Regards,
>
> Laurent Pinchart
Best regards,
-Sumit.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/399047b5/attachment-0001.html>
Properly set the parent device of DP i2c buses before registering them
too.
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
I'm sorry, my previous patch missed the fact that DP i2c buses are
handled separately so they need the same fix.
drivers/gpu/drm/radeon/radeon_i2c.c |
Hi Sumit,
> On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
[snip]
> static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> -struct sg_table *sg)
> + struct sg_table *sg, enum dma_data_direction w
https://bugs.freedesktop.org/show_bug.cgi?id=45432
Bug #: 45432
Summary: memory errors on cayman with VM support + nexuiz
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=45432
Dave Airlie changed:
What|Removed |Added
Keywords||regression
--
Configure bugmail: https://
On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote:
> Hi Sumit,
>
> > On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
>
> [snip]
>
> > static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> > *attach,
> > -struct
Hello,
When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
r600_fence_finish was taking 10% of my CPU time. I determined experimentally
that changing from sched_yield() to os_time_sleep(10) fixed thi
On Tue, Jan 31, 2012 at 3:55 AM, Jean Delvare wrote:
> Properly set the parent device of DP i2c buses before registering them
> too.
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
Reviewed-by: Alex Deucher
> ---
> I'm sorry, my previous patch missed the fact that DP i2c
On Mon, Jan 30, 2012 at 11:10 PM, Ilija Hadzic
wrote:
> copy_blit operation works only on integral number of pages
> so benchmarks shorter than one page size (4K) do not make sense
>
> v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and
> ? ?sweep sizes between 1x to 16x doubling
> ? ?
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
This code needs completion - in particular, we should fall back to
busywaiting (using the nokernel function that's in radeon_drm_bo.c) if the
kernel doesn't support the new interface.
On Tue, 31 Jan 2012, Alex Deucher wrote:
>>
>> Signed-off-by: Ilija Hadzic
>
> Reviewed-by: Alex Deucher
>
Thanks. There will be a v3, though to address one tirvial comment
(whitespace between binary '*' operator) that I received in E-mail sent
directly to me.
I guess the diff v2/v3 will b
On Tue, Jan 31, 2012 at 9:27 AM, Ilija Hadzic
wrote:
>
>
> On Tue, 31 Jan 2012, Alex Deucher wrote:
>
>>>
>>> Signed-off-by: Ilija Hadzic
>>
>>
>> Reviewed-by: Alex Deucher
>>
>
> Thanks. There will be a v3, though to address one tirvial comment
> (whitespace between binary '*' operator) that I
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
This currently doesn't work, hence the debug code piled in.
copy_blit operation works only on integral number of pages
so benchmarks shorter than one page size (4K) do not make sense
v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and
sweep sizes between 1 * to 16K * doubling
the size in each iteration; we get the same coverage, as
t;> 2] );
> +
> + radeon_bo_kunmap(robj);
> +unpin:
> + radeon_bo_unpin(robj);
> +unreserve:
> + radeon_bo_unreserve(robj);
> +unreference:
> + drm_gem_object_unreference_unlocked(gobj);
> +
> + return r;
> +}
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/a6c775b9/attachment-0001.pgp>
hardware.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/17f2538e/attachment.pgp>
On Tue, 2012-01-31 at 13:16 +, Simon Farnsworth wrote:
> Hello,
>
> When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
> wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
> r600_fence_finish was taking 10% of my CPU time. I determined experimen
197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/f3b9dc7d/attachment.pgp>
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
I've been working on to
On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
> Userspace currently busywaits for fences to complete; on my workload, this
> busywait consumes 10% of the available CPU time.
>
> Provide an ioctl so that userspace can wait for an EOP interrupt that
> corresponds to a previous EVENT_WR
https://bugs.freedesktop.org/show_bug.cgi?id=30502
aceman changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31423
--- Comment #2 from aceman 2012-01-31 10:17:34 PST ---
On R600g, Mesa 8.0rc2 the stars seem to have proper colors.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Y
https://bugs.freedesktop.org/show_bug.cgi?id=28905
aceman changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Some comments below.
> + struct radeon_device *rdev = dev->dev_private;
> + struct drm_gem_object *gobj;
> + struct radeon_bo *robj;
> + void *buffer_data;
> + uint32_t *fence_data;
> + int r = 0;
> + long timeout;
> + int ring = RADEON_RING_TYPE_GFX_INDEX;
> +
>
On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel D?nzer wrote:
> On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
> > Userspace currently busywaits for fences to complete; on my workload, this
> > busywait consumes 10% of the available CPU time.
> >
> > Provide an ioctl so that userspac
On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
>
>
> Some comments below.
>
> > + struct radeon_device *rdev = dev->dev_private;
> > + struct drm_gem_object *gobj;
> > + struct radeon_bo *robj;
> > + void *buffer_data;
> > + uint32_t *fence_data;
> > + int r = 0;
> > +
On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse wrote:
> On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
>>
>>
>> Some comments below.
>>
>> > + ? struct radeon_device *rdev = dev->dev_private;
>> > + ? struct drm_gem_object *gobj;
>> > + ? struct radeon_bo *robj;
>> > + ? void *buffe
On Tue, Jan 31, 2012 at 02:13:00PM -0500, Alex Deucher wrote:
> On Tue, Jan 31, 2012 at 2:07 PM, Jerome Glisse wrote:
> > On Tue, Jan 31, 2012 at 01:55:43PM -0500, David Airlie wrote:
> >>
> >>
> >> Some comments below.
> >>
> >> > + ? struct radeon_device *rdev = dev->dev_private;
> >> > + ? stru
2012/1/31 Jerome Glisse :
> On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel D?nzer wrote:
>> On Die, 2012-01-31 at 16:59 +, Simon Farnsworth wrote:
>> > Userspace currently busywaits for fences to complete; on my workload, this
>> > busywait consumes 10% of the available CPU time.
>> >
>> > Pr
was with me looking up information on these
variables before mailing last time. :(
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120131/c047449b/attachment.pgp>
On Jan 31, 2012, at 8:59 AM, Eric Anholt wrote:
> On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston freedesktop.org> wrote:
>> This fixes a failure in 'make check' found by the tinderbox when trying to
>> build this code on Linux/ppc. This code is only designed to run on
>> Intel platforms,
On Fri, Jan 20, 2012 at 05:08:31PM -0600, Seth Forshee wrote:
> > Can you track down who is calling the connector->detect() callbacks
> > during suspend and resume?
>
> I got two different stack traces, see below.
>
> And to slightly amend my statement above, I'm only seeing the wrong
> status re
Polling the outputs when the device is suspended can result in erroneous
status updates. Disable output polling during suspend to prevent this
from happening.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/radeon/radeon_device.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
dif
68 matches
Mail list logo
