a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
>>> From: Ilija Hadzic
>>> Date: Tue, 15 May 2012 16:40:10 -0400
>>> Subject: [PATCH] drm: track dev_mapping in more robust and flexible way
>>>
>>> Setting dev_mapping (pointer to the address_s
Or could the driver that causes the problem be vmwgfx ? I now looked at
the code and I notice that indeed vmwgfx sets its private dev_mapping in
the open hook, while all other TTM-based drivers (radeon and nouveau) do
it when they create an object.
-- Ilija
Can you give the attached patch a whirl and let me know if it fixes the
problem?
As I indicated in my previous note, vmwgfx should be the only affected
driver because it looks at dev_mapping in the open hook (others do it when
they create an object, so they are not affected).
I'll probably re
Some drivers (specifically vmwgfx) look at dev_mapping
in their open hook, so we have to set dev->dev_mapping
earlier in the process.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_fops.c | 43 +--
1 files changed, 29 insertions(+), 14 deleti
On Fri, 26 Oct 2012, Thomas Hellstrom wrote:
> Hi,
>
> On 10/25/2012 11:27 PM, Ilija Hadzic wrote:
>>
>> Can you give the attached patch a whirl and let me know if it fixes the
>> problem?
>>
>> As I indicated in my previous note, vmwgfx should be
If drm_setup (called at first open) fails, the whole
open call has failed, so we should not keep the
open_count incremented.
Signed-off-by: Ilija Hadzic
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_fops.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers
Some drivers (specifically vmwgfx) look at dev_mapping
in their open hook, so we have to set dev->dev_mapping
earlier in the process.
Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-October/029420.html
Signed-off-by: Ilija Hadzic
Reported-by: Thomas Hellstrom
Cc: stable
Hi everyone,
With relatively recent versions of AMD/ATI DDX (xf86-video-ati library), I
have noticed a behavior related to DPMS that looks incorrect to me.
Namely, if I run glxgears, the reported frame rate is equal to that of the
monitor refresh rate, which is correct. Now if I enter DPMS "
The following set of patches refactor the CS-parser logic
in an effort to consolidate the code that is repeated across
ASIC-specific files. All patches except #8 are function-neutral,
that is they preserve the existing functionality of the driver.
Patch #8 adds one extra check for WAIT_REG_MEM pack
length_dw field was assigned twice. While at it, move user_ptr
assignment together with all other assignments to p->chunks[i]
structure to make the code more readable.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_cs.c | 5 +
1 file changed, 1 insertion(+), 4 deleti
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_cs.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 4be64e0..8b03f1c 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon
Preparatory patch: patches to follow will touch a piece of code
that had broken indentication, so fix it before touching it.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r100.c | 45 +--
1 file changed, 22 insertions(+), 23 deletions(-)
diff
CS packet parse functions have a lot of in common across
all ASICs. Implement a common function and take care of
small differences between families inside the function.
This patch is a prep for major refactoring and consolidation
of CS parsing code.
Signed-off-by: Ilija Hadzic
---
drivers/gpu
We now have a common radeon_cs_packet_parse function
that is good for all ASICs. Hook it up and eliminate
ASIC-specific versions.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen_cs.c | 57 +++--
drivers/gpu/drm/radeon/r100.c | 55
Once we factored out radeon_cs_packet_parse function,
evergreen_cs_next_is_pkt3_nop and r600_cs_next_is_pkt3_nop
functions became identical, so they can be factored out
into a common function.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen_cs.c | 23
call into the common function.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen_cs.c | 120 +++---
drivers/gpu/drm/radeon/r600_cs.c | 61 +++--
drivers/gpu/drm/radeon/radeon.h | 4 +-
drivers/gpu/drm/radeon/radeon_reg.h | 2
WAIT_REG_MEM on register does not allow the use of PFP.
Enforce this restriction when checking packets sent from
userland.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen_cs.c | 3 +++
drivers/gpu/drm/radeon/r600_cs.c | 8
2 files changed, 11 insertions(+)
diff
This function is not limited to r100, but it can dump a
(raw) packet for any ASIC. Rename it accordingly and move
its declaration to radeon.h
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r100.c | 52 ++---
drivers/gpu/drm/radeon/r100_track.h | 2
next_reloc function does the same thing in all ASICs with
the exception of R600 which has a special case in legacy mode.
Pull out the common function in preparation for refactoring.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon.h| 3 +++
drivers/gpu/drm/radeon/radeon_cs.c
This patch eliminates ASIC-specific ***_cs_packet_next_reloc
functions and hooks up the new common function.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen_cs.c | 129 +--
drivers/gpu/drm/radeon/r100.c | 76 +++-
drivers/gpu/drm
After refactoring the _cs logic, we ended up with many
macros and constants that #define the same thing.
Clean'em up.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen_cs.c | 18 +-
drivers/gpu/drm/radeon/evergreend.h | 13 ++---
drivers/gpu/drm/r
On Fri, 4 Jan 2013, Dave Airlie wrote:
Did you run these with pre-kms userspace etc to make sure it doesn't
cause regressions there?
No, I didn't, but I can give it a quick whirl. I think I still have one or
two machines with 6.14.x DDX that I can put in UMS mode and see what
happens.
H
On Fri, 4 Jan 2013, Dave Airlie wrote:
Did you run these with pre-kms userspace etc to make sure it doesn't
cause regressions there?
I did some tests with UMS and shuffled a number of cards. As I feared, I
ran into a number of unrelated problems, but in each case I have seen
identical beah
On Fri, 4 Jan 2013, Alex Deucher wrote:
R6xx and r7xx are really all you need to worry about in this case.
R1xx-r5xx UMS uses a different kernel interface for command submission
and evergreen and later don't have UMS drm support. UMS r6xx/r7xx
support used the same kernel interface for comman
At Dave's request I ran some regression tests on my CS-refactoring
patches [1] against old UMS userspace. The tests have revealed
that the current kernel can be provoked into crashing in UMS mode
(and the problem is unrelated to refactoring of CS code; it has
been here before).
The following patch
In UMS mode parser->rdev is NULL, so dereferencing
will cause an oops.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_cs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
in
parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.
This patch fixes a kernel oops that can be provoked
in UMS mode.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r600_cs.c | 6 +
Index into chunks[] array doesn't look right.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 45151c4..469661f 100644
On Mon, Jan 7, 2013 at 7:21 PM, Marek Olšák wrote:
>
> IIRC, the radeon gallium drivers call abort() if they encounter an
> unsupported DRM version (that is UMS).
>
I am not familiar enough to comment, but my observation was that as
soon as I backed out to classic, the segfault went away. So I as
I thought I saw a revert for that patch on the mailing list yesterday:
http://lists.freedesktop.org/archives/dri-devel/2013-January/033322.html
On Tue, 15 Jan 2013, gre...@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
drm: Add EDID_QUIRK
Actually, the code path affected by your patch is not executed in UMS mode
at all. Notice that radeon_cs_parser_fini is only called from
radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
The equivalent of the fix you are trying to do is in
a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e
On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski
wrote:
> On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
>> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
>> > Actually, the code path affected by your patch is not executed in UMS mode
>&g
the issue by forcing both pointers to NULL
after kfree in the error path.
The circumstances under which the problem happens are very
rare. The card must be AGP and the system must run out of
kmalloc area just at the right time so that one allocation
succeeds, while the other fails.
Signed-off-by: Il
I am getting this kind of error when I try to do 'git fetch' from
git://people.freedesktop.org/~airlied/linux.git
remote: error: Could not read ec862f894f7870430e4ff5a9249eaa94d368d220
remote: fatal: bad tree object ec862f894f7870430e4ff5a9249eaa94d368d220
remote: aborting due to possible reposito
On Fri, 28 Sep 2012, Alex Deucher wrote:
I haven't read through your patches yet, but Dave and Ilija already
did something similar a while back:
http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html
Actually, there is a, a newer series of patches here (applied few comments
On Fri, 28 Sep 2012, Kristian Høgsberg wrote:
if (type == DRM_MINOR_CONTROL) {
base += 64;
-limit = base + 127;
+limit = base + 64;
} else if (type == DRM_MINOR_RENDER) {
base += 128;
-limit = ba
On Fri, 28 Sep 2012, Daniel Vetter wrote:
On a quick look the rendernode Kristian propose and your work seem to
attack slightly different issues. Your/Dave's patch series seems to
put large efforts into (dynamically) splitting up the resources of a
drm device, including the modeset stuff.
Co
a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
>>> From: Ilija Hadzic
>>> Date: Tue, 15 May 2012 16:40:10 -0400
>>> Subject: [PATCH] drm: track dev_mapping in more robust and flexible way
>>>
>>> Setting dev_mapping (pointer to the address_s
Or could the driver that causes the problem be vmwgfx ? I now looked at
the code and I notice that indeed vmwgfx sets its private dev_mapping in
the open hook, while all other TTM-based drivers (radeon and nouveau) do
it when they create an object.
-- Ilija
m.
thanks,
-- Ilija
From 18a489e7415f495c7ba48cc61733d6c7d8f3fd68 Mon Sep 17 00:00:00 2001
From: Ilija Hadzic
Date: Thu, 25 Oct 2012 15:28:05 -0400
Subject: [PATCH] drm: set dev_mapping before calling drm_open_helper
Some drivers (specifically vmwgfx) look at dev_mapping
in their open hook, so we have
On Fri, 26 Oct 2012, Thomas Hellstrom wrote:
Hi,
On 10/25/2012 11:27 PM, Ilija Hadzic wrote:
Can you give the attached patch a whirl and let me know if it fixes the
problem?
As I indicated in my previous note, vmwgfx should be the only affected
driver because it looks at dev_mapping in
If drm_setup (called at first open) fails, the whole
open call has failed, so we should not keep the
open_count incremented.
Signed-off-by: Ilija Hadzic
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_fops.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu
Some drivers (specifically vmwgfx) look at dev_mapping
in their open hook, so we have to set dev->dev_mapping
earlier in the process.
Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-October/029420.html
Signed-off-by: Ilija Hadzic
Reported-by: Thomas Hellstrom
Cc:
2011, 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.
According to Alex D. gen2 init was skipped to
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), and
bject: [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
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen
ect: [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
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r600.c
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
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
, 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
(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
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
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
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
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
be
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 Hadzic
---
drivers/gpu/drm/radeon/r100.c| 12
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 pipe
On Fri, 14 Oct 2011 alexdeuc...@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 cleanup. Correctness should be
obvious, so as
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 p
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&id=c245cb9e15055ed5dcf7eaf29232badb0059fdc1
On Mon, 24 Oct 2011, Michael Witten wrote:
On Fri, Oct 7, 2011 at 19:20, Michael Wit
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 var
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
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
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 explanati
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
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 --gi
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 t
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 dele
fewer 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/
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
On Wed, 26 Oct 2011, Daniel Vetter wrote:
Just to check before I dig into reviewing this: Have you check all the
other users of these data structure that these functions touch whether
they don't accidentally rely on the global lock being taken?
I did and thought it was safe. I re-checked th
On Wed, 26 Oct 2011, Daniel Vetter wrote:
I've quickly checked current callsites of drm_fb_helper_init and I think
you can just kill the two arguments crtc_count and max_conn_count.
It is a usable functionality (i.e. allows the driver to select which
connectors or CRTCs is fbcon allowed to
On Wed, 26 Oct 2011, Michel [ISO-8859-1] D�nzer wrote:
On Die, 2011-10-25 at 22:40 -0400, Ilija Hadzic wrote:
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.
Is it really better? If it
count, maximum HPD pins count
and maximum HDMI blocks count (per FIXME in radeon_irq structure)
and correct the loops in radeon_driver_irq_preinstall_kms and
radeon_driver_irq_uninstall_kms
v2: take care of goofs pointed out by Alex Deucher
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon
On Wed, 26 Oct 2011, Alex Deucher wrote:
This is actually not quite right. The number of HPD (Hot Plug Detect)
pins is not equal to the number of crtcs. Radeons have supported 6
HPD pins long before we supported 6 crtcs (e.g., cards with more
connectors than crtcs). The logic should probab
On Wed, 26 Oct 2011, Daniel Vetter wrote:
While you mess around with this code, please use the standard linux
wait_event_* infrastructure.
Right now the order of entering the queue is guaranteed to be the same as
the order of entering the ioctl, which reflects the order of progressing
vbl
On Wed, 26 Oct 2011, Michel [ISO-8859-1] D�nzer wrote:
Does it really need drm_global_mutex at all, as opposed to e.g.
dev->struct_mutex?
It doesn't. Actually, it would probably suffice to have a mutex that is
one-per-CRTC, because vlbank waits on different CRTCs don't step on each
othe
On Thu, 27 Oct 2011, Alan Coopersmith wrote:
I think the idea of sharing kernel drm code is pretty much dead, yeah.
We are still trying to keep it alive, despite what some may think.
In the context of this patch (in progress), it's probably a moot topic
because per comments that Daniel
On Thu, 27 Oct 2011, Daniel Vetter wrote:
On a quick glance
- drm_vblank functions call by wait_vblank seem to do correct locking
already using various spinlocks and atomic ops.
- linux waitqueues have their own locking
- dev->last_vblank_wait is only used for a procfs file. I don't think it
On Thu, 27 Oct 2011, Ilija Hadzic wrote:
While locking at the code I also noticed that wait_vblank calls
drm_vblank_get, but not always drm_vblank_put. The code is correct, the
missing vblank_put is hidden in drm_queue_vblank_event. Can you also write
the patch to move that around to not
On Fri, 28 Oct 2011, Daniel Vetter wrote:
On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel Dänzer wrote:
On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
On Thu, 27 Oct 2011, Daniel Vetter wrote:
So I think the right thing to do is
- Kill dev->last_vblank_wait (in a prep pa
the lock.
v2: incorporate comments received from Daniel Vetter and
Michel Daenzer.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_drv.c |2 +-
drivers/gpu/drm/drm_irq.c | 14 +-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.
ly
encompass real critical sections, rather than some
random code around them
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_context.c |5 +++--
drivers/gpu/drm/drm_drv.c |6 +++---
drivers/gpu/drm/drm_ioctl.c | 15 ---
3 files changed, 10 insertions(+),
flows in the code,
to prevent "false alarms" in the future
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_irq.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c8b4da8..e9dd19d 100644
--- a/d
On Sat, 29 Oct 2011, Daniel Vetter wrote:
+ /* the lock protects this section from itself executed in */
+ /* the context of another PID, ensuring that the process that */
+ /* wrote dev->last_vblank_wait is really the last process */
+ /* that was here; processes waitin
On Sat, 29 Oct 2011, Daniel Vetter wrote:
Ok, and here's why your locking (or any locking that drops the lock before
calling schedule) won't work: [SNIP]
You just came full circle. Recall that in my v1 patch I went all the way
to enqueuing the process in the wait queue before dropping the
locking, within drm_wait_vblank
function so this patch becomes a rather trivial removal
of drm_global_mutex from drm_wait_vblank
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b
flows in the code,
to prevent "false alarms" in the future
v2: incorporate comments received from Daniel Vetter
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_irq.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drive
OK, v4 coming up and your suggestion will be copied verbatim. Hopefully
that does it.
This patch is probably going to become a record-holder in comment/code
lines ratio ;-)
-- Ilija
On Mon, 31 Oct 2011, Daniel Vetter wrote:
On Mon, Oct 31, 2011 at 01:10:21PM -0400, Ilija Hadzic wrote
ly took the drm_global_mutex.
Given all this, it's not worth bothering to try to fix
the locks at this time.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv
Hi everyone,
I would like to bring to the attention of dri-devel and linux-fbdev
community a set of hopefully useful and interesting patches that
I (and a few other colleagues) have been working on during the past
few months. Here, I will provide a short abstract, so that you can
decide whether th
On Thu, 3 Nov 2011, Roland Scheidegger wrote:
Am I right in assuming this could also be used for making muxless hybrid
GPUs work (i.e. radeon/intel igp)?
Yes, this is actually one of the scenarios on my wish list too. In the
terminology that I defined with the introduction of VCRTCM, IGP w
On Thu, 3 Nov 2011, David Airlie wrote:
Well the current plan I had for this was to do it in userspace, I don't think
the kernel
has any business doing it and I think for the simple USB case its fine but will
fallover
when you get to the non-trivial cases where some sort of acceleration is
tream. Hence we need a notification when the cursor image has changed.
Could we *require* that a cursor image change needs to be followed by an
ioctl call with the flag
DRM_MODE_CURSOR_BO?
Thanks,
Thomas
FWIW, Acked-by: Ilija Hadzic
I have a few places where I could use such an ioctl.
BTW, Thoma
On Mon, 7 Nov 2011, Dave Airlie wrote:
So I expect the way I'd like this to work, is that we have full blown drm
drivers for all the devices and then some sort of linkage layer between them,
so one driver can export crtcs from another, instead of having special case
ctd drivers.
I agree and
On Wed, 23 Nov 2011, Dave Airlie wrote:
So another question I have is how you would intend this to work from a
user POV, like how it would integrate with a desktop environment, X or
wayland, i.e. with little or no configuration.
First thing to understand is that when a virtual CRTC is creat
On Thu, 24 Nov 2011, Dave Airlie wrote:
Okay so thats pretty much how I expected it to work, I don't think
Virtual makes sense for a displaylink attached device though,
again if you were using a real driver you would just re-use whatever
output type it uses, though I'm not sure how well that w
So I think we do have enough people interested in this and should be able
to cobble together something that does The Right Thing.
We indeed have a non-trivial set of people interested in the same set of
problems and each of us has partial and maybe competing solution. I want
to make it cle
Dave & Alan:
Maybe I am goofing up something on my end, but gma500 driver on drm-next branch
won't compile for me. I have to apply the two patches that follow this
note to make it work.
The first is a trivial oversight, but the second makes me wonder whether
a stale driver was merged.
-- Ilija
1 - 100 of 445 matches
Mail list logo
