From: Alex Deucher
Compute cs support was actually added in 2.11.0 rather than
2.10.0, but the patch was written prior. Update comment
to match.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher wrote:
> On Tue, Jul 26, 2011 at 5:28 PM, ? wrote:
>> From: Jerome Glisse
>>
>> Some CP interrupt were left enabled when disabling interrupt.
>>
>
> Is there a specific issue this fixes? ?The bits are not interrupt
> sources per se but rather are rela
On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> Keith,
>
> first of all thanks for your prompt reply. Then...
>
> On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov
> > wrote:
> >
> > > And now after v3.0 is o
On Tue, Jul 26, 2011 at 5:28 PM, wrote:
> From: Jerome Glisse
>
> Some CP interrupt were left enabled when disabling interrupt.
>
Is there a specific issue this fixes? The bits are not interrupt
sources per se but rather are related to the internal state of the
interrupt controller and should
From: Jerome Glisse
Some CP interrupt were left enabled when disabling interrupt.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/e
On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher wrote:
> On Tue, Jul 26, 2011 at 5:28 PM, wrote:
>> From: Jerome Glisse
>>
>> Some CP interrupt were left enabled when disabling interrupt.
>>
>
> Is there a specific issue this fixes? The bits are not interrupt
> sources per se but rather are rela
The Dell OptiPlex FX170 claims to have LVDS, but doesn't.
Signed-off-by: Pieterjan Camerlynck
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index b28f7bd
application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/2993b7d6/attachment.pgp>
On Tue, Jul 26, 2011 at 5:28 PM, wrote:
> From: Jerome Glisse
>
> Some CP interrupt were left enabled when disabling interrupt.
>
Is there a specific issue this fixes? The bits are not interrupt
sources per se but rather are related to the internal state of the
interrupt controller and should
From: Jerome Glisse
Some CP interrupt were left enabled when disabling interrupt.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/e
On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote:
> On Wed, Jul 6, 2011 at 7:30 PM, ? wrote:
>> From: Thomas Reim
Guys I really still hate this :-)
Other OSes must deal with this sort of thing and I can't say they
don't do it like this but I can't say for certain this feels like the
right ans
https://bugs.freedesktop.org/show_bug.cgi?id=39572
Summary: Cogs: GPU hang
Product: Mesa
Version: git
Platform: Other
URL: http://www.humblebundle.com/
OS/Version: All
Status: NEW
Severity: normal
Pri
https://bugs.freedesktop.org/show_bug.cgi?id=39572
Summary: Cogs: GPU hang
Product: Mesa
Version: git
Platform: Other
URL: http://www.humblebundle.com/
OS/Version: All
Status: NEW
Severity: normal
Pri
2011/7/25 Rob Clark :
> On Mon, Jul 25, 2011 at 3:18 AM, Joonyoung Shim wrote:
>> 2011/7/22 Jesse Barnes :
>>> On Thu, 21 Jul 2011 19:30:00 +0900
>>> Joonyoung Shim wrote:
>>>
Hi,
simple questions :)
2011/6/21 Jesse Barnes :
> Planes are a bit like half-CRTCs. ?They
Hi Linus,
Main drm pull request for -rc1, main highlights,
Nouveau: open source fermi ucode, per-client gpu address spaces for nv50
and up.
Intel: FBC cleanups (on by default now), high color support, ring
frequency scaling, shared LLC support, and hangcheck module disabling.
radeon: initial c
On Tue, 26 Jul 2011 08:23:13 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> > Two things I've noticed:
>
> > - Why not dev->mode_config.mutex?
>
> You're right, of course. I noticed that just after posting that version
> and updated it; the updated vers
On Tue, 26 Jul 2011 08:23:13 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> > Two things I've noticed:
>
> > - Why not dev->mode_config.mutex?
>
> You're right, of course. I noticed that just after posting that version
> and updated it; the updated vers
On Mon, 2011-07-25 at 23:36 -0700, Keith Packard wrote:
> [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper
> [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to
> [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with
>
> These three are simple cleanups to centralize all
On Tue, Jul 26, 2011 at 10:52 AM, Alex Deucher wrote:
> On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote:
>> On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher
>> wrote:
>>> On Wed, Jul 6, 2011 at 7:30 PM, ? wrote:
From: Thomas Reim
>>
>> Guys I really still hate this :-)
>>
>> Other OSes mus
On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote:
> On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote:
>> On Wed, Jul 6, 2011 at 7:30 PM, ? wrote:
>>> From: Thomas Reim
>
> Guys I really still hate this :-)
>
> Other OSes must deal with this sort of thing and I can't say they
> don't do it li
On Mon, 25 Jul 2011 23:36:34 -0700
Keith Packard wrote:
> Display port pipe selection on CPT is not done with a bit in the
> output register, rather it is controlled by a couple of bits in the
> separate transcoder register which indicate which display port output
> is connected to the transcoder
On Mon, 25 Jul 2011 23:36:34 -0700
Keith Packard wrote:
> Display port pipe selection on CPT is not done with a bit in the
> output register, rather it is controlled by a couple of bits in the
> separate transcoder register which indicate which display port output
> is connected to the transcoder
queue_delayed_work? Plays nicer with other workqueue-items.
-Daniel
PS: Scrap my other mail, just noticed that the merged patched r-b'ed
by Jesse uses the mode_config mutex.
--
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
On Mon, 25 Jul 2011 23:36:30 -0700
Keith Packard wrote:
> This uses the common dpcd reading routine, i915_dp_detect_common,
> instead of open-coding a call to intel_dp_aux_native_read. Besides
> reducing duplicated code, this also gains the read retries which
> may be necessary when a cable is fi
On Mon, 25 Jul 2011 23:36:32 -0700
Keith Packard wrote:
> Eliminates an open-coded read and also gains the retry behaviour of
> intel_dp_get_dpcd, which seems like a good idea.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c |8 +++-
> 1 files changed, 3 insert
On Mon, 25 Jul 2011 23:36:32 -0700
Keith Packard wrote:
> Eliminates an open-coded read and also gains the retry behaviour of
> intel_dp_get_dpcd, which seems like a good idea.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c |8 +++-
> 1 files changed, 3 insert
On Mon, 25 Jul 2011 23:36:31 -0700
Keith Packard wrote:
> This describes the function better, allowing it to be used where the
> DPCD value is relevant.
>
> Signed-off-by: Keith Packard
> ---
Ah I see you've addressed my previous comment already. :)
You can add my
Reviewed-by: Jesse Barnes t
On Mon, 25 Jul 2011 23:36:31 -0700
Keith Packard wrote:
> This describes the function better, allowing it to be used where the
> DPCD value is relevant.
>
> Signed-off-by: Keith Packard
> ---
Ah I see you've addressed my previous comment already. :)
You can add my
Reviewed-by: Jesse Barnes t
On Mon, 25 Jul 2011 23:36:30 -0700
Keith Packard wrote:
> This uses the common dpcd reading routine, i915_dp_detect_common,
> instead of open-coding a call to intel_dp_aux_native_read. Besides
> reducing duplicated code, this also gains the read retries which
> may be necessary when a cable is fi
Two things I've noticed:
- Why not dev->mode_config.mutex? I was under the impression that
mode_config.mutex protects most of the modesetting state and
dev->struct_mutex protects things related to the gpu execution cores
(i.e. all things gem), with struct_mutex nested within
mode_config.mutex. It's
On Wed, Jul 20, 2011 at 4:34 AM, wrote:
> From: Thomas Reim
>
> ? ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
> ? for a DVI connector that is not implemented/existent on the board.
>
> ? Fix by applying extented DDC probing for this connector.
>
> ? Requires [PATCH] drm/radeon: Fix A
On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard wrote:
> From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001
> From: Keith Packard
> Date: Mon, 25 Jul 2011 22:37:51 -0700
> Subject: [PATCH] Revert and fix "drm/i915/dp: remove DPMS mode tracking from
> ?DP"
>
> This reverts commi
On Tue, 26 Jul 2011 09:44:32 +0200, Daniel Vetter wrote:
> queue_delayed_work? Plays nicer with other workqueue-items.
Yeah, I'll change this.
--
keith.pack...@intel.com
pgpifulG3hqfz.pgp
Description: PGP signature
___
dri-devel mailing list
dri-de
tion/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/8c274b70/attachment.pgp>
On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> Two things I've noticed:
> - Why not dev->mode_config.mutex?
You're right, of course. I noticed that just after posting that version
and updated it; the updated version is on my drm-intel-fixes branch
already (having been reviewed by Jes
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/1b607231/attachment-0001.pgp>
On Tue, Jul 26, 2011 at 10:52 AM, Alex Deucher wrote:
> On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote:
>> On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote:
>>> On Wed, Jul 6, 2011 at 7:30 PM, wrote:
From: Thomas Reim
>>
>> Guys I really still hate this :-)
>>
>> Other OSes must de
On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote:
> On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote:
>> On Wed, Jul 6, 2011 at 7:30 PM, wrote:
>>> From: Thomas Reim
>
> Guys I really still hate this :-)
>
> Other OSes must deal with this sort of thing and I can't say they
> don't do it li
On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote:
> On Wed, Jul 6, 2011 at 7:30 PM, wrote:
>> From: Thomas Reim
Guys I really still hate this :-)
Other OSes must deal with this sort of thing and I can't say they
don't do it like this but I can't say for certain this feels like the
right ans
On Sat, Jul 23, 2011 at 11:10:53AM -0400, Alex Deucher wrote:
> On Fri, Jul 22, 2011 at 5:31 PM, Kirill Smelkov wrote:
> > On Sat, Jul 23, 2011 at 01:08:14AM +0400, Kirill Smelkov wrote:
> >> On Fri, Jul 22, 2011 at 01:50:04PM -0700, Keith Packard wrote:
> >
> >> > You're right, of course -- UMS i
On Wed, Jul 20, 2011 at 4:34 AM, wrote:
> From: Thomas Reim
>
> ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
> for a DVI connector that is not implemented/existent on the board.
>
> Fix by applying extented DDC probing for this connector.
>
> Requires [PATCH] drm/radeon: Fix A
On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard wrote:
> From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001
> From: Keith Packard
> Date: Mon, 25 Jul 2011 22:37:51 -0700
> Subject: [PATCH] Revert and fix "drm/i915/dp: remove DPMS mode tracking from
> DP"
>
> This reverts commi
https://bugs.freedesktop.org/show_bug.cgi?id=35697
Nikos Chantziaras changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=35697
Nikos Chantziaras changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Hi Linus,
Main drm pull request for -rc1, main highlights,
Nouveau: open source fermi ucode, per-client gpu address spaces for nv50
and up.
Intel: FBC cleanups (on by default now), high color support, ring
frequency scaling, shared LLC support, and hangcheck module disabling.
radeon: initial c
queue_delayed_work? Plays nicer with other workqueue-items.
-Daniel
PS: Scrap my other mail, just noticed that the merged patched r-b'ed
by Jesse uses the mode_config mutex.
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
Two things I've noticed:
- Why not dev->mode_config.mutex? I was under the impression that
mode_config.mutex protects most of the modesetting state and
dev->struct_mutex protects things related to the gpu execution cores
(i.e. all things gem), with struct_mutex nested within
mode_config.mutex. It's
47 matches
Mail list logo
