drm_lock() does:
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
...
if (drm_lock_take(&master->lock, lock->context)) {
< schedule() here
master->lock.file_priv = file_priv;
Hi, Kaleb
From the git log I know that the two files of vesamodes/extramodes
are created by you. And the default modes will be generated by two
scripts. In the two files there define the parameters for the different
modelines. For example: hdisplay, vdisplay, htotal, vtotal, pclk.
My q
On Tue, 21 Apr 2009 19:48:39 -0700
Eric Anholt wrote:
> On Tue, 2009-04-14 at 15:22 -0700, Jesse Barnes wrote:
> > Add a new page flipping ioctl to the i915 driver, using KMS
> > functionality.
> >
> > Internally, the new flip ioctl will use the mode_set_base function,
> > which will simply upda
On Tue, 2009-04-14 at 15:22 -0700, Jesse Barnes wrote:
> Add a new page flipping ioctl to the i915 driver, using KMS
> functionality.
>
> Internally, the new flip ioctl will use the mode_set_base function,
> which will simply update the front buffer pointer, taking care to pin
> the new buffer and
On Wed, 2009-04-08 at 19:41 +0100, Chris Wilson wrote:
> On Wed, 2009-04-08 at 11:05 -0700, Eric Anholt wrote:
> > Here's the pair of patches I've got to make A17-afflicted machines do
> > tiling.
> > I've created regression tests for swapping tiled objects and for pread on
> > tiled objects, and
On Sat, 2009-04-18 at 10:43 +0800, Wu Fengguang wrote:
> Signed-off-by: Wu Fengguang
> ---
> drivers/gpu/drm/i915/i915_gem.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Fixed up commit message and applied.
> --- mm.orig/drivers/gpu/drm/i915/i915_gem.c
> +++ mm/drivers/gpu/drm/
hi,
i've attached a small patch that should fix a small memory allocation
issue when called without arguments.
a!
--
aszlig
Universaldilettant
RedMoonStudios
Don't deallocate the connector before reading props.
--- tests/modetest/modetest.c 2009-03-19 00:51:13.0 +0100
+++ tests/modetes
On Tue, 2009-04-21 at 09:29 +0200, Jonas Bonn wrote:
> It looks like some code got left behind while generalizing. This patch
> removes the old, non-general version and fixes up the generalized version
> so that it does what its supposed to.
NAK.
There is SDVOB, and SDVOC.
To detect SDVOB, you
http://bugs.freedesktop.org/show_bug.cgi?id=20935
--- Comment #1 from Maciej Cencora 2009-04-21 12:30:01
PST ---
This is probably the same bug as mentioned here
http://marc.info/?l=mesa3d-dev&m=124026675231694&w=2
Currently I'm trying to find a solution that doesn't lockup GPU.
--
Confi
http://bugs.freedesktop.org/show_bug.cgi?id=20954
--- Comment #5 from Rafael Antonio Porras Samaniego
2009-04-21 11:59:48 PST ---
Created an attachment (id=25010)
--> (http://bugs.freedesktop.org/attachment.cgi?id=25010)
Proposed patch to avoid null pointer use.
--
Configure bugmail: ht
http://bugzilla.kernel.org/show_bug.cgi?id=13130
--- Comment #7 from Andrew Morton 2009-04-21
17:05:34 ---
(In reply to comment #6)
> Is there a registry or something we should use instead?
powerpc put a comment into the main table in sysrq.c. That works nicely.
--
Configure bugmail: ht
http://bugzilla.kernel.org/show_bug.cgi?id=13130
--- Comment #6 from Jesse Barnes 2009-04-21
15:56:24 ---
(In reply to comment #5)
> well... _why_ do we want it to work? It's only a debug thing and shouldn't
> be needed at all once the driver is finished?
Oh not at all; it's also about de
http://bugs.freedesktop.org/show_bug.cgi?id=21241
--- Comment #7 from Alex Deucher 2009-04-21 07:54:52 PST ---
Also, can you attach the working log from this system with Ubuntu-8.10.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this m
http://bugs.freedesktop.org/show_bug.cgi?id=21241
Alex Deucher changed:
What|Removed |Added
Summary|Suse11: Cannot enable DRI, |Suse11: Blank screen
|A
http://bugs.freedesktop.org/show_bug.cgi?id=21241
--- Comment #5 from samit vats 2009-04-21 07:07:54 PST ---
1) on startx, screen goes blank (error message in Xorg0.log : AIGLX error:
Calling driver entry point failed) so unable to debug with LIBGL_DEBUG=verbose
glxinfo
2) For the same bui
Jerome Glisse wrote:
> On Tue, 2009-04-21 at 14:42 +0200, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> Hi Thomas,
>>>
>>> I am not sure of the correct solution for moving a bo from
>>> VRAM to SYSTEM when you need to go through TT, here are
>>> solution i thought of and why they
On Tue, 2009-04-21 at 14:42 +0200, Thomas Hellstrom wrote:
> Jerome Glisse wrote:
> > Hi Thomas,
> >
> > I am not sure of the correct solution for moving a bo from
> > VRAM to SYSTEM when you need to go through TT, here are
> > solution i thought of and why they are wrong:
> >
> > (in driver callba
Jerome Glisse wrote:
> Hi Thomas,
>
> I am not sure of the correct solution for moving a bo from
> VRAM to SYSTEM when you need to go through TT, here are
> solution i thought of and why they are wrong:
>
> (in driver callback move i get bo & newmem with bo being
> in vram and newmem being SYSTEM)
Hi Thomas,
I am not sure of the correct solution for moving a bo from
VRAM to SYSTEM when you need to go through TT, here are
solution i thought of and why they are wrong:
(in driver callback move i get bo & newmem with bo being
in vram and newmem being SYSTEM)
1) ttm_bo_move_buffer(bo, TT, ...)
It looks like some code got left behind while generalizing. This patch
removes the old, non-general version and fixes up the generalized version
so that it does what its supposed to.
Signed-off-by: Jonas Bonn
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 files changed, 2 inserti
drm_connector_init sets both the connector type and the connector type_id
on the newly initialised connector. As the connector type_id is coupled to
the connector type, the connector type cannot simply be modified on an
initialised connector.
This patch changes the order of operations on intel_sd
It looks like some code got left behind while generalizing. This patch
removes the old, non-general version and fixes up the generalized version
so that it does what its supposed to.
Signed-off-by: Jonas Bonn
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 files changed, 2 inserti
I sent these two patches last week, but I had the wrong subject line on them so
I am afraid that they may have gone unnoticed by the right people. This is a
resend of these two patches, just to make sure that they are not missed.
Sorry for the noise.
/Jonas
-
drm_connector_init sets both the connector type and the connector type_id
on the newly initialised connector. As the connector type_id is coupled to
the connector type, the connector type cannot simply be modified on an
initialised connector.
This patch changes the order of operations on intel_sd
I sent these patches last week, but as I had the wrong subject line on them
(DRM instead of DRM/i915), I'm afraid they may have gone unnoticed. Here's
a resend just to make sure that they're seen by the right people.
Regards,
Jonas Bonn
South Pole Consulting AB
www.southpoleconsulting.com
25 matches
Mail list logo
