https://bugs.freedesktop.org/show_bug.cgi?id=67187
--- Comment #4 from Harald Judt ---
There is some inconsistency in my testing. As one can deduce from dmesg.out, I
was using tuxonice hybrid suspend/resume (behold the alternating S4/S3 lines)
and that might have a bad influence on in-kernel susp
https://bugs.freedesktop.org/show_bug.cgi?id=66805
--- Comment #20 from Laurent carlier ---
(In reply to comment #18)
> Created attachment 82875 [details] [review]
> Mesa Patch #2 v3
>
> If you replace the v2 patch with this v3 patch, does it fix the crash?
Now portal (and it seems every games)
https://bugs.freedesktop.org/show_bug.cgi?id=67283
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > We could just unconditionally increase the alignement in
> > intel_pin_and_fence_fb_obj - we already have more strict requirements due
> > to a bunch of w/a in other places. So shouldn't hurt at all reall
https://bugzilla.kernel.org/show_bug.cgi?id=60527
--- Comment #8 from Fabio Erculiani ---
Created attachment 107015
--> https://bugzilla.kernel.org/attachment.cgi?id=107015&action=edit
dmesg from a broken kernel (3.10.2)
This is from the "broken" kernel (without the commit reverted)
--
You a
https://bugzilla.kernel.org/show_bug.cgi?id=60527
--- Comment #9 from Fabio Erculiani ---
Created attachment 107016
--> https://bugzilla.kernel.org/attachment.cgi?id=107016&action=edit
dmesg from a working kernel (3.10.1)
This is from a working kernel (with the commit reverted) and was capture
ext tree lost its build failure and gained a conflict
>>>>> against Linus' tree.
>>>>>
>>>>> The tty tree lost its build failure.
>>>>>
>>>>> The staging tree gained a build failure for which I disabled a driver
https://bugs.freedesktop.org/show_bug.cgi?id=67276
--- Comment #3 from Joshua Cov. ---
I have to say that I'm using kernel 3.10.3 with all radeon patches
(drm-next-3.11 and drm-fixes-3.11) applied to it. The prooblem started after
applying the fixes...
However I needed to fix commit 1b6e5fd5f4fc
This helper is used only once and just wraps a call to
drm_vma_offset_add(). Remove this unneeded indirection to safe 10 lines of
code.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/ttm/ttm_bo.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drive
https://bugs.freedesktop.org/show_bug.cgi?id=67276
--- Comment #4 from Alex Deucher ---
If you didn't pull in the drm reservation changes you don't need the fix. Do
you have this problem straight 3.11?
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=67276
--- Comment #5 from Joshua Cov. ---
(In reply to comment #4)
> If you didn't pull in the drm reservation changes you don't need the fix.
> Do you have this problem straight 3.11?
I pull everything from your git that you sent to dave for mainlin
https://bugs.freedesktop.org/show_bug.cgi?id=67276
--- Comment #6 from Joshua Cov. ---
(In reply to comment #4)
> If you didn't pull in the drm reservation changes you don't need the fix.
> Do you have this problem straight 3.11?
I didn't remember to have had this problem with the straight 3.11
https://bugs.freedesktop.org/show_bug.cgi?id=67276
--- Comment #7 from Alex Deucher ---
(In reply to comment #5)
>
> Can this commit be the culprit of the problem?
Yes, it could be. As I said, it was a fix for the new reservation code which
it sounds like you didn't pull in.
--
You are recei
gt;>
> >>>>>> The wireless-next tree lost its build failure and gained a conflict
> >>>>>> against Linus' tree.
> >>>>>>
> >>>>>> The tty tree lost its build failure.
> >>>>>>
> >>>>>> The staging tree gained a build failure for which
https://bugs.freedesktop.org/show_bug.cgi?id=67276
--- Comment #8 from Joshua Cov. ---
(In reply to comment #7)
> (In reply to comment #5)
> >
> > Can this commit be the culprit of the problem?
>
> Yes, it could be. As I said, it was a fix for the new reservation code
> which it sounds like yo
Hi
See patch 4/4 for a more detailed explanation of this series. I basically kill
off the whole drm_mm pre-alloc code as it really doesn't make any sense with
todays infrastructure. No drm_mm user runs in atomic context. We use pre-alloc
only to allow allocation while holding a spin-lock. But we c
Add a "best_match" argument similar to the drm_mm_search_*() helpers so we
can convert TTM to use them in follow up patches. We can also inline the
non-generic helpers and move them into the header to allow compile-time
optimizations.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_mm.c
Instead of calling drm_mm_pre_get() in a row, we now preallocate the node
and then use the atomic insertion functions. This has the exact same
semantics and there is no reason to use the racy pre-allocations.
Note that ttm_bo_man_get_node() does not run in atomic context. Nouveau already
uses GFP_
We used to pre-allocate drm_mm nodes and save them in a linked list for
later usage so we always have spare ones in atomic contexts. However, this
is really racy if multiple threads are in an atomic context at the same
time and we don't have enough spare nodes. Moreover, all remaining users
run in
i915 is the last user of the weird search+get_block drm_mm API. Convert it
to an explicit kmalloc()+insert_node(). This drops the last user of the
node-cache in drm_mm. We can remove it now in a follow-up patch.
Cc: Daniel Vetter
Signed-off-by: David Herrmann
---
drivers/gpu/drm/i915/i915_gem_s
On Thu, Jul 25, 2013 at 8:08 AM, David Herrmann wrote:
> This helper is used only once and just wraps a call to
> drm_vma_offset_add(). Remove this unneeded indirection to safe 10 lines of
> code.
>
> Signed-off-by: David Herrmann
Review-by: Jerome Glisse
> ---
> drivers/gpu/drm/ttm/ttm_bo.c
On Thu, Jul 25, 2013 at 03:55:59PM +0200, David Herrmann wrote:
> Add a "best_match" argument similar to the drm_mm_search_*() helpers so we
> can convert TTM to use them in follow up patches. We can also inline the
> non-generic helpers and move them into the header to allow compile-time
> optimiz
On Thu, Jul 25, 2013 at 03:56:01PM +0200, David Herrmann wrote:
> i915 is the last user of the weird search+get_block drm_mm API. Convert it
> to an explicit kmalloc()+insert_node(). This drops the last user of the
> node-cache in drm_mm. We can remove it now in a follow-up patch.
>
> Cc: Daniel V
https://bugs.freedesktop.org/show_bug.cgi?id=67276
--- Comment #9 from Alex Deucher ---
(In reply to comment #8)
> I'll take a look later if I can backport the reservation code back to 3.10
> (if it's worth). I see some commits (280cf2118675..8f262540e61c7, or
> especially ecff665f5e in git://peo
https://bugs.freedesktop.org/show_bug.cgi?id=66805
--- Comment #21 from Tom Stellard ---
(In reply to comment #20)
> (In reply to comment #18)
> > Created attachment 82875 [details] [review] [review]
> > Mesa Patch #2 v3
> >
> > If you replace the v2 patch with this v3 patch, does it fix the cra
https://bugs.freedesktop.org/show_bug.cgi?id=67276
--- Comment #10 from Joshua Cov. ---
(In reply to comment #9)
> (In reply to comment #8)
> > I'll take a look later if I can backport the reservation code back to 3.10
> > (if it's worth). I see some commits (280cf2118675..8f262540e61c7, or
> > e
On Thu, Jul 25, 2013 at 03:56:00PM +0200, David Herrmann wrote:
> Instead of calling drm_mm_pre_get() in a row, we now preallocate the node
> and then use the atomic insertion functions. This has the exact same
> semantics and there is no reason to use the racy pre-allocations.
>
> Note that ttm_b
lure and gained a conflict
> >> >>>>>> against Linus' tree.
> >> >>>>>>
> >> >>>>>> The tty tree lost its build failure.
> >> >>>>>>
> >> >>>>>> The staging tree gained
On Thu, Jul 25, 2013 at 03:56:02PM +0200, David Herrmann wrote:
> We used to pre-allocate drm_mm nodes and save them in a linked list for
> later usage so we always have spare ones in atomic contexts. However, this
> is really racy if multiple threads are in an atomic context at the same
> time and
https://bugzilla.kernel.org/show_bug.cgi?id=60623
Bug ID: 60623
Summary: White Screen on boot with radeon.dpm=1
Product: Drivers
Version: 2.5
Kernel Version: 3.11.0-999-generic
Hardware: x86-64
OS: Linux
Tree:
t;
>>> >> >>>>>> Removed tree:
>>> >> >>>>>> arm-dt (at maintainer's request)
>>> >> >>>>>>
>>> >> >>>>>> The wireless-next tree lost its build failure and gained a
>&
https://bugzilla.kernel.org/show_bug.cgi?id=60623
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 from
We need BUG_ON(), spinlock_t and standard kernel data-types so include the
right headers.
Signed-off-by: David Herrmann
---
include/drm/drm_mm.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index a30c9aa..d3f0aa1 100644
--- a/include/drm/drm_
This was meant as response to:
Subject: [drm-intel:drm-intel-nightly 154/166] include/drm/drm_mm.h:67:2:
error: unknown type name 'spinlock_t'
Message-ID: <51f14693.g5hgdcuw2v3m8fod%fengguang...@intel.com>
In case it didn't link to it correctly. Somehow this bug doesn't occur
here on my machine,
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #8 from John ---
Same issue, with 3.11 RC2 and radeon.dpm=1 on a Lenovo T500 with a AMD 3650.
Though my screen goes black and then gradually goes white when enabled. Without
the option pc boots normally.
Graphics: Switchable (disable
On Thu, Jul 25, 2013 at 06:11:18PM +0200, Sedat Dilek wrote:
> Might be OT, but I cannot use my X graphics stack containing
> libdrm-2.4.46, mesa-9.1.5 and intel-ddx 2.21.12-git (tried also
> v2.21.11).
> Switching back to the one from Ubuntu/precise lets my X start.
>
>
> [40.379] (II) AIGLX
VT switch
> >> [ 40.396] ddxSigGiveUp: Closing log
> >> [40.398] Server terminated with error (1). Closing log file.
> >
> > Please attach the full Xorg.0.log so that I can make a few guesses.
>
> Linux-kernel: This happens with drm-intel-nightly pulled int
https://bugs.freedesktop.org/show_bug.cgi?id=66805
--- Comment #22 from Vladimir Ysikov ---
Portal also stopped falling with the latest patches.
It remains to fix the bug 66974, and life will be a little better.:-)
--
You are receiving this mail because:
You are the assignee for the bug.
__
From: Tom Cooksey
Please find below the current state of our pl111 DRM/KMS driver. This
is lightly tested on a Versatile Express using X running the
xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
as of ~last week. To actually see anything on the DVI output, you
must also app
On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson
> wrote:
> > Basically boils down to either an object allocation failure or mmaping
> > failure. I think dmesg with drm.debug=7 is the next step.
>
> Attached! Thanks for taking care.
Hm
On Thu, Jul 25, 2013 at 07:52:22PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson
> wrote:
> > On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
> >> On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson
> >> wrote:
> >> > Basically boils down to either an object a
Daniel Vetter writes:
> On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote:
>> Daniel Vetter writes:
>>
>> > We could just unconditionally increase the alignement in
>> > intel_pin_and_fence_fb_obj - we already have more strict requirements due
>> > to a bunch of w/a in other places.
On Thu, Jul 25, 2013 at 1:17 PM, wrote:
> From: Tom Cooksey
>
> Please find below the current state of our pl111 DRM/KMS driver. This
> is lightly tested on a Versatile Express using X running the
> xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
> as of ~last week. To actua
On Thu, Jul 25, 2013 at 08:03:06PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:55 PM, Sedat Dilek wrote:
> > F*ck. Wrong patch refreshed.
> >
>
> New dmesg attached.
Hmm, not seeing any difference, so let's add a couple more lines just to
be sure:
(apologies I didn't stash the previou
Russell King and Sebastian Hasselbarth had proposed some very good changes
for the tda998x HDMI encoder driver. But when those changes were tested
on BeagleBone Black against the tilcdc driver many modes would no longer
display correctly. After analyzing the sync signals from the TI lcd contoller
Add necessary support for flipping the hsync signal and shifting
the display to the right by a certain number of pixels. Changes
only take effect if adjusted_mode is changed in fixup function.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/i2c/tda998x_drv.c | 10 ++
1 files chang
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: Darren Etheridge
---
drivers
On Thu, Jul 25, 2013 at 08:50:59PM +0200, Sedat Dilek wrote:
> Against what tree is this applicable? It is definitely not drm-intel-nightly.
Applied cleanly to nightly here, but just in case here's a rebased version:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
i
On Thu, Jul 25, 2013 at 8:13 PM, Keith Packard wrote:
> Daniel Vetter writes:
>
>> On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote:
>>> Daniel Vetter writes:
>>>
>>> > We could just unconditionally increase the alignement in
>>> > intel_pin_and_fence_fb_obj - we already have more s
On Thu, Jul 25, 2013 at 09:12:41PM +0200, Sedat Dilek wrote:
> New -3 dmesg.
That puts the ball back in the ddx's court. Next debugging patch:
diff --git a/src/intel_driver.c b/src/intel_driver.c
index f4d76bb..1f4f299 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -170,6 +170,7 @@ s
On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge wrote:
> Russell King and Sebastian Hasselbarth had proposed some very good changes
> for the tda998x HDMI encoder driver. But when those changes were tested
> on BeagleBone Black against the tilcdc driver many modes would no longer
> display corr
Hi Dave,
Brown-paper-bag pull request here. The snb rc6 fix from the last pull
broke forcewake BIOS dirt cleanup, which with fixed. But that fix broke
the spinlock init sequence, which results in an ugly BUG when spinlock
debugging is enabled :( So I get to throw another patch at cc: stable to
fix
Hello,
While looking at pipe_loader_drm.c in Mesa, I see that udev is used on
Linux to get the PCI ID of the device. I understand that getting this
information is a general need in libdrm, Mesa, and so on.
Is there a portable way to obtain this?
If not, what do you think about adding an ioct
On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
> What means the bang line?
>
> [54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
> [54.565] bang: 1159
> [54.565]
> Fatal server error:
> [54.565] failed to create screen resources
That means between the kern
> Generally I think checking our current sw state instead of reading hw
> registers would be safer, e.g. in case we start to queue up more than
> one pageflip. For async pageflips in benchmark mode "flip as fast as
> you can queue" would be a sensible mode.
Ok, I've moved the tiling checks to the
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 37 +
Just copies the IVB code
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 166aa2c..4a118c3 100644
--- a/d
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #23 from wojtek ---
(In reply to comment #13)
> Try comparing the following registers between fglrx and radeon:
>
difference:
left (fglrx) right(rad)
GB_ADDR_CONFIG
-0x98F8 0x02010002 (33619970)
+0x98F8 0x02010001 (33619969)
CGTS_
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #24 from wojtek ---
> left (fglrx) right(rad)
> GB_ADDR_CONFIG
> -0x98F8 0x02010002 (33619970)
> +0x98F8 0x02010001 (33619969)
my mistake
- (left - radeon)
+ (right -fglrx)
--
You are receiving this mail because:
You are the assi
On Fri, Jul 26, 2013 at 01:21:07AM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson
> wrote:
> > On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
> >> What means the bang line?
> >>
> >> [54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
> >> [
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #9 from Alex Deucher ---
I pushed a few bug fixes here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=rv6xx-dpm-fixes
--
You are receiving this mail because:
You are the assignee for the bug.
__
> -Original Message-
> From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
> Sent: Wednesday, July 24, 2013 1:43 PM
> To: dri-devel@lists.freedesktop.org
> Cc: inki@samsung.com; jy0922.s...@samsung.com;
sachin.ka...@linaro.org;
> patc...@linaro.org
> Subject: [PATCH 1/1] drm/exynos: R
From: Alex Deucher
Hi Dave,
Just a few more patches to fix some issues with dpm on rv6xx.
The following changes since commit cef1d00cd56f600121ad121875655ad410a001b8:
drm/radeon: fix combios tables on older cards (2013-07-22 15:57:14 -0400)
are available in the git repository at:
git://
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit 14c5cec5d0cd ("drm/i915:
initialize gt_lock early with other spin locks") from the drm-intel-fixes
tree and commit 907b28c56ea4 ("drm/i915: Colocate all GT access routines
in the
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_pm.c between commit 14c5cec5d0cd ("drm/i915:
initialize gt_lock early with other spin locks") from the drm-intel-fixes
tree and commit 907b28c56ea4 ("drm/i915: Colocate all GT access routines
in the
https://bugs.freedesktop.org/show_bug.cgi?id=67283
--- Comment #9 from Martin Peres ---
@Hohahiu: Do you also have to minimize and maximize the video in order to see
an image?
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=67283
Aaron Plattner changed:
What|Removed |Added
CC||aplatt...@nvidia.com
--- Comment #10 fr
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #10 from Sergey ---
Tried last 4 patches from Alex. Didn't work for me. The issue remains.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing l
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/05c52c53/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/d6aa395b/attachment.html>
Okay as I warned, the qxl driver was running a bit free and loose with its
ttm object reservations and the new lockdep enabled reservation tracking
shone a bright light into it, it also with the new reservations mutexes
hits a possible deadlock during boot.
the first patch is a real fix to rende
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/a01704c5/attachment-0001.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/7db084fc/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/432ab423/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/fcb663e8/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/b877df7b/attachment.html>
achments/20130725/bf638761/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/d71a282f/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/90c857e2/attachment-0001.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/e93b9d0b/attachment.html>
On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > We could just unconditionally increase the alignement in
> > intel_pin_and_fence_fb_obj - we already have more strict requirements due
> > to a bunch of w/a in other places. So shouldn't hurt at all reall
https://bugzilla.kernel.org/show_bug.cgi?id=60527
--- Comment #8 from Fabio Erculiani ---
Created attachment 107015
--> https://bugzilla.kernel.org/attachment.cgi?id=107015&action=edit
dmesg from a broken kernel (3.10.2)
This is from the "broken" kernel (without the commit reverted)
--
You a
https://bugzilla.kernel.org/show_bug.cgi?id=60527
--- Comment #9 from Fabio Erculiani ---
Created attachment 107016
--> https://bugzilla.kernel.org/attachment.cgi?id=107016&action=edit
dmesg from a working kernel (3.10.1)
This is from a working kernel (with the commit reverted) and was capture
ree lost its build failure and gained a conflict
>> against Linus' tree.
>>
>> The tty tree lost its build failure.
>>
>> The staging tree gained a build failure for which I disabled a driver.
>>
>> ----
gt; The wireless-next tree lost its build failure and gained a conflict
>>>>> against Linus' tree.
>>>>>
>>>>> The tty tree lost its build failure.
>>>>>
>>>>> The staging tree gained a build failure for which I disabl
t;
> The tty tree lost its build failure.
>
> The staging tree gained a build failure for which I disabled a driver.
>
>
>
[ CCing drm and drm-intel folks ]
With today's next-20130725 I see the following:
;>> The tty tree lost its build failure.
>>>
>>> The staging tree gained a build failure for which I disabled a driver.
>>>
>>>
>>>
>>
>> [ CCing drm and drm-intel folks ]
>>
>> With today's next-20130725 I see the following:
>
> Use of d
nst Linus' tree.
>>>>
>>>> The tty tree lost its build failure.
>>>>
>>>> The staging tree gained a build failure for which I disabled a driver.
>>>>
>>>>
>>>
tree lost its build failure.
>>>>>>
>>>>>> The staging tree gained a build failure for which I disabled a driver.
>>>>>>
>>>>>>
>>&
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/b9bee1f6/attachment.html>
This helper is used only once and just wraps a call to
drm_vma_offset_add(). Remove this unneeded indirection to safe 10 lines of
code.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/ttm/ttm_bo.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drive
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/e59db041/attachment.html>
iving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/d3b3cf8b/attachment.html>
es/dri-devel/attachments/20130725/05b893b8/attachment.html>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/fc4104ac/attachment.html>
gt;>
> >>>>>> The wireless-next tree lost its build failure and gained a conflict
> >>>>>> against Linus' tree.
> >>>>>>
> >>>>>> The tty tree lost its build failure.
> >>>>>>
> >>>>>> The staging tree gained a bu
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/234292d0/attachment.html>
Hi
See patch 4/4 for a more detailed explanation of this series. I basically kill
off the whole drm_mm pre-alloc code as it really doesn't make any sense with
todays infrastructure. No drm_mm user runs in atomic context. We use pre-alloc
only to allow allocation while holding a spin-lock. But we c
Add a "best_match" argument similar to the drm_mm_search_*() helpers so we
can convert TTM to use them in follow up patches. We can also inline the
non-generic helpers and move them into the header to allow compile-time
optimizations.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_mm.c
Instead of calling drm_mm_pre_get() in a row, we now preallocate the node
and then use the atomic insertion functions. This has the exact same
semantics and there is no reason to use the racy pre-allocations.
Note that ttm_bo_man_get_node() does not run in atomic context. Nouveau already
uses GFP_
1 - 100 of 143 matches
Mail list logo
