than 6 CRTCs, this is still OK because
higher numbers won't be looked at)
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_irq_kms.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon
the crtc check in radeon_get_vblank_timestamp_kms should be against
the num_crtc field in radeon_device not against num_crtcs in drm_device
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu
it's better that radeon_crtc_commit and radeon_crtc_prepare call
crtc-specific dpms functions instead of hard-coding them to
radeon_crtc_dpms.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions
The following three patches address various minor nits. They are all safe
and I have been running with them for several months on a wide variety
of AMD GPUs
The first patch:
[PATCH 1/3] drm/radeon/kms: use crtc-specific dpms functions in
does not change the functionality and affects the function
of
magnitude.
fix it, but making drm_wait_vblank DRM_UNLOCKED call and
then grabbing the mutex inside the drm_wait_vblank function
and only for the duration of the critical section (i.e.,
from first manipulation of vblank sequence number until
putting the task in the wait queue).
Signed-off-by: Ilija Hadzic
drm_getmap, drm_getclient and drm_getstats are all
protected with their own mutex (dev->struct_mutex)
no need to hold global mutex; make them DRM_UNLOCKED
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_drv.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --
drm_getcap and drm_version ioctls only reads static data,
there is no need to protect them with drm_global_mutex,
so make them DRM_UNLOCKED
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
The following three patches remove unecessary locks around ioctls
in drm module.
First two:
[PATCH 1/3] drm: no need to hold global mutex for static data
[PATCH 2/3] drm: make DRM_UNLOCKED ioctls with their own mutex
are rather trivial and straight forward and probably do not
need much
gpu driver can specify the limit on the number of connectors
that a given crtc can use. Add a check to make sure this limit
is honored when building a list of connectors associated
with a crtc.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fb_helper.c |5 +
1 files changed, 5
stop adding crtcs from dev->mode_config.crtc_list
to crtc_info array if gpu driver specifies (by mistake
or with a reason) fewer crtcs in crtc_count parameter
also, correct crtc_count value if gpu driver
specifies too many crtcs
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fb_helpe
The following two patches address potential problems that I
called "troubles waiting to happen" in this note
http://lists.freedesktop.org/archives/dri-devel/2011-October/015412.html
I didn't hear anyone take on my question, so I figured I would just send
the patches. I tested the patches on a
The following two patches address potential problems that I
called troubles waiting to happen in this note
http://lists.freedesktop.org/archives/dri-devel/2011-October/015412.html
I didn't hear anyone take on my question, so I figured I would just send
the patches. I tested the patches on a
stop adding crtcs from dev-mode_config.crtc_list
to crtc_info array if gpu driver specifies (by mistake
or with a reason) fewer crtcs in crtc_count parameter
also, correct crtc_count value if gpu driver
specifies too many crtcs
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
gpu driver can specify the limit on the number of connectors
that a given crtc can use. Add a check to make sure this limit
is honored when building a list of connectors associated
with a crtc.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_fb_helper.c |5
The following three patches remove unecessary locks around ioctls
in drm module.
First two:
[PATCH 1/3] drm: no need to hold global mutex for static data
[PATCH 2/3] drm: make DRM_UNLOCKED ioctls with their own mutex
are rather trivial and straight forward and probably do not
need much
drm_getmap, drm_getclient and drm_getstats are all
protected with their own mutex (dev-struct_mutex)
no need to hold global mutex; make them DRM_UNLOCKED
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/drm_drv.c |6 +++---
1 files changed, 3 insertions(+), 3
of
magnitude.
fix it, but making drm_wait_vblank DRM_UNLOCKED call and
then grabbing the mutex inside the drm_wait_vblank function
and only for the duration of the critical section (i.e.,
from first manipulation of vblank sequence number until
putting the task in the wait queue).
Signed-off-by: Ilija Hadzic
The following three patches address various minor nits. They are all safe
and I have been running with them for several months on a wide variety
of AMD GPUs
The first patch:
[PATCH 1/3] drm/radeon/kms: use crtc-specific dpms functions in
does not change the functionality and affects the function
it's better that radeon_crtc_commit and radeon_crtc_prepare call
crtc-specific dpms functions instead of hard-coding them to
radeon_crtc_dpms.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 14 ++
1 files changed, 10
than 6 CRTCs, this is still OK because
higher numbers won't be looked at)
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon_irq_kms.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b
the crtc check in radeon_get_vblank_timestamp_kms should be against
the num_crtc field in radeon_device not against num_crtcs in drm_device
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
Maybe you are looking at the wrong branch, but I see it in drm-next (it
has been there since Oct 10)
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=c245cb9e15055ed5dcf7eaf29232badb0059fdc1
On Mon, 24 Oct 2011, Michael Witten wrote:
> On Fri, Oct 7, 2011 at 19:20, Michael Witten
Maybe you are looking at the wrong branch, but I see it in drm-next (it
has been there since Oct 10)
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=c245cb9e15055ed5dcf7eaf29232badb0059fdc1
On Mon, 24 Oct 2011, Michael Witten wrote:
On Fri, Oct 7, 2011 at 19:20, Michael
While hacking something else, I stumbled upon two potential issues
in drm_fb_helper. Could someone who knows this better than me enlighten
whether the problem is realistic or whether I am overseeing something ?
If the problem is real (or a potential trouble waiting to happen), I have
cut some
While hacking something else, I stumbled upon two potential issues
in drm_fb_helper. Could someone who knows this better than me enlighten
whether the problem is realistic or whether I am overseeing something ?
If the problem is real (or a potential trouble waiting to happen), I have
cut some
On Fri, 14 Oct 2011 alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> r600-NI shared the same blit suspend code. Clean it up
> and make it a shared function.
>
> Signed-off-by: Alex Deucher
> Cc: Ilija Hadzic
Thanks, this one slipped my eye in my cleanu
On Fri, 14 Oct 2011 alexdeuc...@gmail.com wrote:
From: Alex Deucher alexander.deuc...@amd.com
r600-NI shared the same blit suspend code. Clean it up
and make it a shared function.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: Ilija Hadzic ihad...@research.bell-labs.com
Thanks
On Thu, 13 Oct 2011, Roland Scheidegger wrote:
> I guess it isn't possible to temporarily disable some RBEs or otherwise
> reconfigure the chip that you could get the same performance for the
> high-end chips?
According to the conversation I had with Alex, this *is* possible but
requires the
Dave,
Alex pointed to me that the patches I sent last night under this thread
may conflict with 003cefe0c238e683a29d2207dba945b508cd45b7 that currently
resides on drm-fixes branch (my patches are based on drm-next or
drm-core-next).
I'd like to make sure that the eventual merge goes
Frank,
I have found this text particularly useful when it comes to using MIT (or
BSD) code that resides in the GPL project (e.g. DRM in Linux)
http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
I think that sections 2.2 and 2.3 are the things to be careful about
blit copy functions deal with GPU pages, not CPU pages,
so rename the variables and parameters accordingly
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r600_blit_kms.c | 27 ++-
drivers/gpu/drm/radeon/radeon_asic.h |4 ++--
2 files changed, 16
factor out most of evergreen blit code and use the refactored code
from r600 that is now common for both r600 and evergreen
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c | 25 +---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 260
for r600 and evergreen parts
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r600_blit_kms.c | 94 +---
drivers/gpu/drm/radeon/radeon.h| 21 +++
2 files changed, 70 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/radeon
and (probably
more interesting) buffers sizes that correspond to common modes.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/radeon_benchmark.c | 91 +++--
drivers/gpu/drm/radeon/radeon_device.c|2 +-
3 files
, etc)
add #defines for some hard coded constants
besides "beautification" this reorg is done in preparation
for writing more elaborate benchmarks
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 156 -
1 files changed, 86 inserti
some 3d register bits look like magic in r600 blit functions
use predefined constants to make it more intuitive what they are
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r600_blit_kms.c | 30 +-
drivers/gpu/drm/radeon/r600d.h | 22
some bits in 3D registers used by blit functions look like
magic and this is hard to follow; change them to a little bit
more meaningful pre-defined constants
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 29 +--
drivers/gpu/drm/radeon
start with first-cut conceptual patch from Alex Deucher
(commit info below); turn on 1D tiling
make rectangular buffer always 2:1 or 1:2 ratio
make buffer dimenstions an integer multiple of unit
dimensionsmake sures that integral number of pages map
to the buffer fix a few bugs that resulted in
start with first-cut conceptual patch from Alex Deucher
(commit info below); turn on 1D tiling
make rectangular buffer always 2:1 or 1:2 ratio
make buffer dimenstions an integer multiple of unit dimensions
make sures that integral number of pages map to the buffer
fix a few bugs that resulted in
The following set of patches will improve the performance
of blit-copy functions for Radeon GPUs based on
R600, R700, Evergreen and NI ASICs.
The foundation for improvement is the use of tiled mode access
(which for copying bo's can be used regardless of whether the
content is tiled or not),
Frank,
I have found this text particularly useful when it comes to using MIT (or
BSD) code that resides in the GPL project (e.g. DRM in Linux)
http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
I think that sections 2.2 and 2.3 are the things to be careful about
with changes due to blit-copy improvements on drm-next
branch
substitutes the v2 patch that currently resides on drm-fixes
branch
Conflicts:
drivers/gpu/drm/radeon/evergreen.c
drivers/gpu/drm/radeon/r600.c
drivers/gpu/drm/radeon/radeon_asic.h
Signed-off-by: Ilija
On Thu, 13 Oct 2011, Roland Scheidegger wrote:
I guess it isn't possible to temporarily disable some RBEs or otherwise
reconfigure the chip that you could get the same performance for the
high-end chips?
According to the conversation I had with Alex, this *is* possible but
requires the
, Alex Deucher wrote:
> On Tue, Sep 20, 2011 at 10:22 AM, Ilija Hadzic
> wrote:
>> Enabling pcie gen2 speed was skipped for Northern Islands
>> AISCs, although it looks like it works just fine with the same
>> initialization sequence used for evergreen.
>>
>
2011, Alex Deucher wrote:
On Tue, Sep 20, 2011 at 10:22 AM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
Enabling pcie gen2 speed was skipped for Northern Islands
AISCs, although it looks like it works just fine with the same
initialization sequence used for evergreen.
According to Alex D
The following set of patches will improve the performance
of blit-copy functions for Radeon GPUs based on
R600, R700, Evergreen and NI ASICs.
The foundation for improvement is the use of tiled mode access
(which for copying bo's can be used regardless of whether the
content is tiled or not),
-0400
Subject: [PATCH 1/2] drm/radeon/kms: simplify evergreen blit code
Covert 4k pages to multiples of 64x64x4 tiles.
This is also more efficient than a scanline based
approach from the MC's perspective.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Ilija Hadzic ihad
Subject: [PATCH 2/2] drm/radeon/kms: simplify r6xx blit code
Covert 4k pages to multiples of 64x64x4 tiles.
This is also more efficient than a scanline based
approach from the MC's perspective.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Ilija Hadzic ihad...@research.bell
some bits in 3D registers used by blit functions look like
magic and this is hard to follow; change them to a little bit
more meaningful pre-defined constants
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 29
some 3d register bits look like magic in r600 blit functions
use predefined constants to make it more intuitive what they are
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/r600_blit_kms.c | 30 +-
drivers/gpu/drm/radeon
, etc)
add #defines for some hard coded constants
besides beautification this reorg is done in preparation
for writing more elaborate benchmarks
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 156 -
1 files
and (probably
more interesting) buffers sizes that correspond to common modes.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/radeon_benchmark.c | 91 +++--
drivers/gpu/drm/radeon
for r600 and evergreen parts
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/r600_blit_kms.c | 94 +---
drivers/gpu/drm/radeon/radeon.h| 21 +++
2 files changed, 70 insertions(+), 45 deletions(-)
diff --git a/drivers
factor out most of evergreen blit code and use the refactored code
from r600 that is now common for both r600 and evergreen
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen.c | 25 +---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 260
Looks like the same pcie gen2 speed initialization for
Evergreen also works on Cayman and seems to come up fine,
so enable it if the module parameter says so
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |4 ++--
drivers/gpu/drm/radeon/ni.c|4
2 files
in the meantime; so now it should be safe to enable it.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f09bace..208b59c 100644
in the meantime; so now it should be safe to enable it.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index
Looks like the same pcie gen2 speed initialization for
Evergreen also works on Cayman and seems to come up fine,
so enable it if the module parameter says so
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen.c |4 ++--
drivers/gpu/drm/radeon/ni.c
Related to this question, one thing that I noticed is that in some
instances, I would not see any interrupts at all. Instead, all signaled
fences would be taken care of next time somebody waits on one them
(through radeon_fence_wait, radeon_fence_signaled,
radeon_fence_poll_locked call
Related to this question, one thing that I noticed is that in some
instances, I would not see any interrupts at all. Instead, all signaled
fences would be taken care of next time somebody waits on one them
(through radeon_fence_wait, radeon_fence_signaled,
radeon_fence_poll_locked call
debug statement for GUI idle interrupt is wrong and incorrectly
reports CP EOP interrupt; trivial issue, but confusing for
someone trying to distinguish interrupt sources while debugging
... fixed
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm
debug statement for GUI idle interrupt is wrong and incorrectly
reports CP EOP interrupt; trivial issue, but confusing for
someone trying to distinguish interrupt sources while debugging
... fixed
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen.c
is not visible outside the
enum type, so #else was always taken in compilation type. This patch
fixes it by basing #ifdef on (pre-processor visible)
DRM_VBLANK_HIGH_CRTC_SHIFT constant
Signed-off-by: Ilija Hadzic
---
src/radeon_dri2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
is not visible outside the
enum type, so #else was always taken in compilation type. This patch
fixes it by basing #ifdef on (pre-processor visible)
DRM_VBLANK_HIGH_CRTC_SHIFT constant
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
src/radeon_dri2.c |2 +-
1 files changed, 1
the crtc check in radeon_get_vblank_timestamp_kms should be against
the num_crtc field in radeon_device not against num_crtcs in drm_device
like it's done in all other functions that handle crtc
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
1 files changed, 1
if object pin or object lookup in radeon_cursor_set fail, the function
could leave inconsistent mouse width and hight values in radeon_crtc
fixed by moving cursor width and height assignments after all
checks have passed
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon
if object pin or object lookup in radeon_cursor_set fail, the function
could leave inconsistent mouse width and hight values in radeon_crtc
fixed by moving cursor width and height assignments after all
checks have passed
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers
the crtc check in radeon_get_vblank_timestamp_kms should be against
the num_crtc field in radeon_device not against num_crtcs in drm_device
like it's done in all other functions that handle crtc
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon_kms.c
Are you by any chance working off a stale branch in git ?
Apparently the lines you are modifying now live in drm_platform_set_busid
function in drm_platform.c
-- Ilija
On Tue, 29 Mar 2011, Rob Clark wrote:
> From: Rob Clark
>
> Include the minor device id in the bus-id to give userspace a
Are you by any chance working off a stale branch in git ?
Apparently the lines you are modifying now live in drm_platform_set_busid
function in drm_platform.c
-- Ilija
On Tue, 29 Mar 2011, Rob Clark wrote:
From: Rob Clark robdcl...@gmail.com
Include the minor device id in the bus-id to
This thread turned into much more than what its scope is and I hoped I
would stay out of the "fight" (especially after the vocabulary got very
"liberal"). Yet, my code (as trivial as it is) has sparked up some old
issues and seems to be referred to over and over again, so I want to make
a few
This thread turned into much more than what its scope is and I hoped I
would stay out of the fight (especially after the vocabulary got very
liberal). Yet, my code (as trivial as it is) has sparked up some old
issues and seems to be referred to over and over again, so I want to make
a few
On Fri, 25 Mar 2011, Dave Airlie wrote:
> Michel raised his concern after that point, so no matter what it was
> already in a tree I'd pushed out to public so the only answer when he
> raised his concern was to revert or fix it.
Just to be fair to Michel (and prevent any unnecessary "fights"
, not as an incremental patch to the one sent previously).
Regards,
Ilija
Signed-off-by: Ilija Hadzic
---
src/radeon.h |3 +++
src/radeon_dri2.c | 53 +++--
2 files changed, 42 insertions(+), 14 deletions(-)
diff --git a/src/radeon.h b
that Dave
pushed this morning. It *supersedes* the previously sent patch (i.e.
apply it to the master branch as it exists at the time of this writing,
not as an incremental patch to the one sent previously).
Regards,
Ilija
Signed-off-by: Ilija Hadzic
---
include/drm/drm.h |1 +
xf86drm.h
On Thu, 24 Mar 2011, Linus Torvalds wrote:
>
> In other words: Why should I pull this at all?
>
You should pull it (eventually) because it fixes a problem that is real
and visible and does it in a way that is conservative enough to not risk
introducing new breakage.
Whether you should pull
OK, I'll update libdrm side to match this change and send the patch later
today
-- Ilija
On Thu, 24 Mar 2011, Dave Airlie wrote:
> 2011/3/23 Michel D?nzer :
>> On Mit, 2011-03-23 at 06:40 -0500, Ilija Hadzic wrote:
>>> On Wed, 23 Mar 2011, Dave Airlie wrote:
>>>
&
On Thu, 24 Mar 2011, Linus Torvalds wrote:
In other words: Why should I pull this at all?
You should pull it (eventually) because it fixes a problem that is real
and visible and does it in a way that is conservative enough to not risk
introducing new breakage.
Whether you should pull
, not as an incremental patch to the one sent previously).
Regards,
Ilija
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
src/radeon.h |3 +++
src/radeon_dri2.c | 53 +++--
2 files changed, 42 insertions(+), 14 deletions
On Fri, 25 Mar 2011, Dave Airlie wrote:
Michel raised his concern after that point, so no matter what it was
already in a tree I'd pushed out to public so the only answer when he
raised his concern was to revert or fix it.
Just to be fair to Michel (and prevent any unnecessary fights on
deon, 2 core fixes, and an interface update to allow for > 2 crtcs
>>>>> in vblank.
>>>>
>>>> [...]
>>>>
>>>>> Ilija Hadzic (1):
>>>>> ? ? ? drm/kernel: vblank wait on crtc > 1
>>>>
>>>> This p
to allow for 2 crtcs
in vblank.
[...]
Ilija Hadzic (1):
drm/kernel: vblank wait on crtc 1
This patch was still being debated yesterday, are you deliberately
pushing it regardless? Once it hits mainline, it'll be pretty much set
in stone.
From what I can see it was the userspace patches
the original
patch had been submitted. It *supersedes* the previous patch (i.e. apply
it to the master branch as it exists at the time of this writing, not
as an incremental patch to the one sent previously).
No new functionality has been introduced.
Regards,
Ilija
Signed-off-by: Ilija Hadzic
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
>
> Not calling the ioctl doesn't imply returning immediately.
>
> Your changes only fix the bug you found (the X radeon driver calls the
> ioctl when that doesn't make sense) when both the kernel and X driver
> are updated, but it would be
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
>
> In the post I referenced above, you said:
>
>> [...] I'll add a hook to the DDX to check the version and not issue
>> the ioctl at all if it is requested on a higher CRTC. I think that's
>> better than falling back to the old style and
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
> [ xf86-video-ati patches usually go to the xorg-driver-ati at lists.x.org
> list ]
>
I was told it should go to Alex and CC dri-devel. Next time I'll include
the other list.
>
> I'm still against this. At this point we know with
Sorry about overseeing additional comments. It definitely wasn't
intentional.
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
>>
>> If _DRM_VBLANK_HIGH_CRTC_MASK were included in _DRM_VBLANK_FLAGS_MASK
>> (or _DRM_VBLANK_TYPES_MASK, but that would make less sense), these
>> changes
-03-18 at 16:58 -0500, Ilija Hadzic wrote:
>>
>> This patch extends the interface to drm_wait_vblank ioctl so that crtc>1
>> can be represented. It also adds a new capability to drm_getcap ioctl so
>> that the user space can check whether the new interface to drm_wait_vb
-03-18 at 16:58 -0500, Ilija Hadzic wrote:
This patch extends the interface to drm_wait_vblank ioctl so that crtc1
can be represented. It also adds a new capability to drm_getcap ioctl so
that the user space can check whether the new interface to drm_wait_vblank
is supported (and fall back
Sorry about overseeing additional comments. It definitely wasn't
intentional.
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D�nzer wrote:
If _DRM_VBLANK_HIGH_CRTC_MASK were included in _DRM_VBLANK_FLAGS_MASK
(or _DRM_VBLANK_TYPES_MASK, but that would make less sense), these
changes shouldn't be
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D�nzer wrote:
[ xf86-video-ati patches usually go to the xorg-driver-...@lists.x.org
list ]
I was told it should go to Alex and CC dri-devel. Next time I'll include
the other list.
I'm still against this. At this point we know with certainty
On Tue, 22 Mar 2011, Michel [ISO-8859-1] D�nzer wrote:
In the post I referenced above, you said:
[...] I'll add a hook to the DDX to check the version and not issue
the ioctl at all if it is requested on a higher CRTC. I think that's
better than falling back to the old style and issuing
the original
patch had been submitted. It *supersedes* the previous patch (i.e. apply
it to the master branch as it exists at the time of this writing, not
as an incremental patch to the one sent previously).
No new functionality has been introduced.
Regards,
Ilija
Signed-off-by: Ilija Hadzic ihad
sorry about that, I use pine and thought that's as plain as it gets. I
guess next time I'll try just 'mail' from command line.
On Mon, 21 Mar 2011, Dave Airlie wrote:
> On Sat, Mar 19, 2011 at 7:58 AM, Ilija Hadzic
> wrote:
>>
>> Hi Dave,
>>
>> Below is a
On Sat, 19 Mar 2011, Alex Deucher wrote:
> On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
> wrote:
>>
>> Hi Alex,
>>
>> Below is a patch against the master branch of xf86-video-ati that adds
>> support for waits on vblank events on CRTCs that ar
On Sat, 19 Mar 2011, Alex Deucher wrote:
> On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
> wrote:
>>
>> Hi Alex,
>>
>> Below is a patch against the master branch of libdrm that adds support for
>> waits for vblank events on CRTCs that are greater than 1 (and
On Sat, 19 Mar 2011, Alex Deucher wrote:
> On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
> wrote:
>>
>> Hi Dave,
>>
>> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
>> capability to wait on vblank events for CRTCs that a
On Sat, 19 Mar 2011, Alex Deucher wrote:
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
Hi Dave,
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
capability to wait on vblank events for CRTCs that are greater than 1 and
thus
On Sat, 19 Mar 2011, Alex Deucher wrote:
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
Hi Alex,
Below is a patch against the master branch of libdrm that adds support for
waits for vblank events on CRTCs that are greater than 1 (and thus cannot
On Sat, 19 Mar 2011, Alex Deucher wrote:
On Fri, Mar 18, 2011 at 5:58 PM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
Hi Alex,
Below is a patch against the master branch of xf86-video-ati that adds
support for waits on vblank events on CRTCs that are greater than 1 (and
thus cannot
301 - 400 of 423 matches
Mail list logo
