radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from vram BO.
Cc: stable at vger.kernel.org
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_test.c | 8
1 file changed, 4
radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from destination BO.
Cc: stable at vger.kernel.org
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 13 -
1 file
inode argument is no longer in use (cf. f4aede2e3).
Remove it.
Signed-off-by: Ilija Hadzic
Cc: David Herrmann
---
drivers/gpu/drm/drm_fops.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index a0ce39c
.data field that belongs to wrong
device.
This patch fixes the problem by moving the mem_types
list into the radeon_device structure instead of using
static declarations.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon.h | 6 ++
drivers/gpu/drm/radeon/radeon_ttm.c | 43
-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 7cb178a..0c7b8c6 100644
--- a/drivers/gpu/drm/radeon
npinning
code. Consequently, the buffer that has been NULL-ified in
drm_helper_disable_unused_functions will never be unpinned
causing a leak in VRAM.
This patch plugs the leak by unpinning the frame buffer
in crtc_disable function.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/atombio
The following patches will plug the VRAM leak that can be provoked in the
radeon driver by changing the mode. The mechanism that causes the leak is
described in the commit message associated with the first patch.
The way I have caused it (and tested the fix) was temporarily hack up debug
counters
On Tue, 29 Oct 2013, Daniel Vetter wrote:
> Oh right, I've forgotten that between the review and writing the mail
> ;-) I guess we could try to bend the stable rules a bit and just
> submit all 6. It's a regression fix after all, and at least personally
> I prefer the most minimal backports to
On Tue, 29 Oct 2013, Daniel Vetter wrote:
> Aside: The horribly ad-hoc calling convetions with some of the (x, y, fb,
> mode) parameters being set before calling a lower-level functions, some
> being restored, some of them being the old backup value and some of them
> being expected to be
restoration. The elimination is possible because previous
patches have cleaned up the resoration path so that only
the fields touched by the drm_crtc_helper_set_config function
are saved and restored if necessary.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_helper.c | 33
off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_helper.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9e536b1..a1322af 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/
There is no need to save or restore hwmode field, because by
the time this function sets this field, it cannot fail any more.
However, we should save old enabled field because if
the function fails, we want to return with unchanged CRTC.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b06a6c4..65f3658 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm
Old framebuffer is stored in save_set.fb and it is
the same value that is later stored in old_fb.
This makes old_fb redundant so we can replace
it with save_set.fb.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_helper.c | 12
1 file changed, 4 insertions(+), 8 deletions
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_helper.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index dbcd687..d0ac595 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu
The following patch series fixes the mutex corruption problem
due to bit-copying of drm_crtc structure that happens when
drm_crtc_helper_set_config function takes the error-recovery
path. The patch series is the alternative solution for the
patch that was proposed and NACK-ed two weeks ago [1].
(dropping stable at ... until we get the fix we can agree on)
While looking through that function (drm_crtc_helper_set_config) to
figure out what we really need to save and restore, I came across a
piece of code that you added in 25f397a4. The 'if (connector->dpms !=
DRM_MODE_DPMS_ON)' (line 719
> Can't we instead just copy the few things we need to restore back?
> This wholesale structure copying has rather tricky semantics and is
> bound to trick up someone else in the future. And indeed we seem to
> have a similar (but less catastrophic) thing going on with crtc->fb I
> think.
Sure,
structure
and allocating it separately from the drm_crtc structure
when the CRTC is initialized. The bit-copying in
drm_crtc_helper_set_config helper will now overwrite the pointer
which is never modified during the CRTC's lifetime, thus
avoiding corruption.
Signed-off-by: Ilija Hadzic
Cc: stable
On Fri, 12 Jul 2013, Christian K?nig wrote:
> Hi Ilija,
>
> well that's very interesting and no it's quite unlikely that this is cause by
> the DMA ring because the radeon_sa_bo structure should be allocated on system
> memory and the GPU can usually only access it if you map it through GART.
Alex,
Can you please share some details about the nature or symptom of the
"instability". One problem that I have been seeing on my end is that when
I use the DMA ring intensively (by intensively I mean, calling the copy
function every frame), combined with some 3D rendering that causes a lot
Alex,
Can you please share some details about the nature or symptom of the
instability. One problem that I have been seeing on my end is that when
I use the DMA ring intensively (by intensively I mean, calling the copy
function every frame), combined with some 3D rendering that causes a lot
> I certainly don't pull patches in from others to it very often, and
> modetest I generally blame on jbarnes.
>
Speaking of forgotten patches, could someone with the commit access please
pick up this one:
http://lists.freedesktop.org/archives/dri-devel/2012-November/030852.html
ATI DDX already
On Thu, 18 Apr 2013, David Herrmann wrote:
> Hi
>
> On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek
> wrote:
>> David,
>>
>> I'm developing a small application that uses libdrm (DRM ioctls) to change
>> the
>> resolution of a single graphics display and show a framebuffer. I've run
>> into
On Thu, 18 Apr 2013, David Herrmann wrote:
Hi
On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek gand...@winds.org wrote:
David,
I'm developing a small application that uses libdrm (DRM ioctls) to change
the
resolution of a single graphics display and show a framebuffer. I've run
into
two
at the function entry.
Fix spelling mistakes in commit message.
v3: Add reference to the original bug report.
Reported-by: Marco Munderloh
Tested-by: Marco Munderloh
Signed-off-by: Ilija Hadzic
Cc: Michal Hocko
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_fops.c | 6 --
1 file
t; attachment.
>
> Best, Marco
>
> On 02.04.2013 13:23, Ilija Hadzic wrote:
>>
>> -- Ilija
>>
>> On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh
>> mailto:munderl at tnt.uni-hannover.de>>
>> wrote:
>>
>> Attached is
Thanks for testing. Other issues are probably unrelated, so I'll send the
last version of the patch to Dave.
-- Ilija
On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh wrote:
> Attached is a v2 of the patch, for reference. I would appreciate if the
>> original reporter or you tested it in lieu
Thanks for testing. Other issues are probably unrelated, so I'll send the
last version of the patch to Dave.
-- Ilija
On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh mund...@tnt.uni-hannover.de
wrote:
Attached is a v2 of the patch, for reference. I would appreciate if the
original reporter
On 02.04.2013 13:23, Ilija Hadzic wrote:
-- Ilija
On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh
mund...@tnt.uni-hannover.de mailto:mund...@tnt.uni-hannover.de wrote:
Attached is a v2 of the patch, for reference. I would appreciate if
the original reporter or you tested it in lieu of your
at the function entry.
Fix spelling mistakes in commit message.
v3: Add reference to the original bug report.
Reported-by: Marco Munderloh mund...@tnt.uni-hannover.de
Tested-by: Marco Munderloh mund...@tnt.uni-hannover.de
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
Cc: Michal Hocko
On Sun, 31 Mar 2013, Michal Hocko wrote:
> On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
>> This looks a bit like a hack and it doesn't look right,
>> conceptually. If the call fails, it should restore things as if
>> nothing has ever happened and overwriting old_mapping
On Sun, 31 Mar 2013, Michal Hocko wrote:
On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
This looks a bit like a hack and it doesn't look right,
conceptually. If the call fails, it should restore things as if
nothing has ever happened and overwriting old_mapping is not going to
do the trick
This looks a bit like a hack and it doesn't look right, conceptually. If
the call fails, it should restore things as if nothing has ever happened
and overwriting old_mapping is not going to do the trick.
I think the right way to fix it would be to separately store the
original mapping for
://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html
v2: use one variable to store file and inode mapping
since they are the same at the function entry; also
fix spelling mistakes in commit message.
Reported-by: Marco Munderloh
Signed-off-by: Ilija Hadzic
Cc: Michal Hocko
Cc
This looks a bit like a hack and it doesn't look right, conceptually. If
the call fails, it should restore things as if nothing has ever happened
and overwriting old_mapping is not going to do the trick.
I think the right way to fix it would be to separately store the
original mapping for
xes 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
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
&
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: Ilija
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
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
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, gregkh at linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
>drm: Add
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
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
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
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 --
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
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
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
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
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
In UMS mode parser-rdev is NULL, so dereferencing
will cause an oops.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
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
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm
Index into chunks[] array doesn't look right.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
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
On Mon, Jan 7, 2013 at 7:21 PM, Marek Olšák mar...@gmail.com 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
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
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
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.
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.
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/radeon
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
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 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
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
and 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
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
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
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
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
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
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
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
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
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/radeon_cs.c | 5 +
1 file changed, 1
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/r100.c | 45 +--
1 file changed, 22
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 ihad
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen_cs.c | 57 +++--
drivers/gpu/drm/radeon
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen_cs.c
and call into the common function.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
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
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen_cs.c | 3 +++
drivers/gpu/drm/radeon/r600_cs.c | 8
2 files
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/r100.c | 52 ++---
drivers/gpu
This patch eliminates ASIC-specific ***_cs_packet_next_reloc
functions and hooks up the new common function.
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen_cs.c | 129 +--
drivers/gpu/drm/radeon/r100.c | 76
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 ihad...@research.bell-labs.com
---
drivers/gpu/drm/radeon/evergreen_cs.c | 18 +-
drivers/gpu/drm/radeon/evergreend.h | 13
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
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
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: sta
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
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 ihad...@research.bell-labs.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_fops.c | 5 -
1 file changed, 4 insertions(+), 1 deletion
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 ihad...@research.bell-labs.com
Reported-by: Thomas
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
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
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
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
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
On Thu, Oct 25, 2012 at 11:10 AM, Thomas Hellström
thellst...@vmware.com wrote:
On 10/25/12 4:41 PM, Jerome Glisse wrote:
On Thu, Oct 25, 2012 at 04:02:25PM +0200, Thomas Hellstrom wrote:
Hi,
This commit
From 949c4a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
From: Ilija
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
,
-- Ilija
From 18a489e7415f495c7ba48cc61733d6c7d8f3fd68 Mon Sep 17 00:00:00 2001
From: Ilija Hadzic ihad...@research.bell-labs.com
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
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
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 =
1 - 100 of 423 matches
Mail list logo
