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
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 ioctl
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/515854f4/attachment.html>
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
2 (194)
--
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/2223a8de/attachment.html>
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=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.
_
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 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
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
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
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
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 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 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
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://
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 >> chris-wilson.co.uk> wrote:
> >> > Basically boils down to e
> -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
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
From: Tom Cooksey
This is a mode-setting driver for the pl111 CLCD display controller
found on various ARM reference platforms such as the Versatile
Express. The driver supports setting of a single mode (640x480) and
has only been tested on Versatile Express with a Cortex-A9 core tile.
Known iss
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
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.wu at intel.com>
In case it didn't link to it correctly. Somehow this bug doesn't occur
here on my machi
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_
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 into next-20130725.
Basically boils down to either an object allocation failure or mmaping
failure. I think dmesg with drm.debug=7 is the next step.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
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
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.
__
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/13777155/attachment.html>
;>>>
>>> >> >>>>>> Removed tree:
>>> >> >>>>>> arm-dt (at maintainer's request)
>>> >> >>>>>>
>>> >> >>>>>> The wireless-next tree l
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
> >> [
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
st its build failure and gained a conflict
> >> >>>>>> against Linus' tree.
> >> >>>>>>
> >> >>>>>> The tty tree lost its build failure.
> >> >>>>>>
> >> >>>>&
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
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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130725/179ecbc5/attachment.html>
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
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
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_
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
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
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_
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
https://bugzilla.kernel.org/show_bug.cgi?id=60623
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
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
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
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 +
> 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
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
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 +
> 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
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://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:
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
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/602079c3/attachment.html>
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
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/e723215a/attachment.html>
reservation code doesn't
provide any advantages at this point.
--
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/5d9a175a/attachment.html>
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
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
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/234292d0/attachment.html>
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
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
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
--
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 build failure for which I disabl
es/dri-devel/attachments/20130725/05b893b8/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>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/e59db041/attachment.html>
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
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.
>>
>> ----
tree lost its build failure.
>>>>>>
>>>>>> The staging tree gained a build failure for which I disabled a driver.
>>>>>>
>>>>>>
>>&
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
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 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 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
nst Linus' tree.
>>>>
>>>> The tty tree lost its build failure.
>>>>
>>>> The staging tree gained a build failure for which I disabled a driver.
>>>>
>>>>
>>>
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
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
;>> 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
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130725/b9bee1f6/attachment.html>
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
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
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
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.
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 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
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:
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
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
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.
__
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
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
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
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
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
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
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
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,
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_
https://bugzilla.kernel.org/show_bug.cgi?id=60623
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 from
1 - 100 of 143 matches
Mail list logo
