On Wed, Sep 21, 2011 at 8:52 PM, Michael Witten wrote:
> Because my hardware does appear to be malfunctioning due to a corrupt
> video BIOS, it seems prudent to salvage as much as possible from
> its output, so that it is possible to figure out which other values
> need to be hardcoded in case of f
On Mon, Sep 26, 2011 at 21:51, Tormod Volden wrote:
> On Wed, Sep 21, 2011 at 8:52 PM, Michael Witten wrote:
>> Because my hardware does appear to be malfunctioning due to a corrupt
>> video BIOS, it seems prudent to salvage as much as possible from
>> its output, so that it is possible to figure
This eliminates VGA shimmer on some Ironlake machines which have a
CK505 clock source.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm
The PCH refclk settings are global, so we need to look at all of the
encoders, not just the current encoder when deciding how to configure
it. Also, handle systems with more than one panel (any combination of
PCH/non-PCH eDP and LVDS).
Disable SSC clocks when no panels are connected.
Signed-off-b
I can't find any reference clocks which run at 96MHz as seems to be
indicated from the comments in this code.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_di
The reference clock configuration must be done before any mode setting
can occur as all outputs must be disabled to change
anything. Initialize the clocks after turning everything off during
the initialization process.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 10
These are all KMS related anyways, so don't hide them under other
debug levels.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_bios.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios
This includes whether an eDP panel is present, and whether that should
use SSC (and at what frequency)
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_bios.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/
Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915/intel_display.c |4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
This tells the driver whether a CK505 clock source is available on
pre-PCH hardware. If so, it should be used as the non-SSC source,
leaving the internal clock for use as the SSC source.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_bios.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_bios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 61abef8..4c530fa 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/g
Here's a patch sequence which cleans up a bunch of PCH refclk related
bits. There are a couple of questionable patches that I'd like to see
people look at:
[PATCH 6/9] drm/i915: Fix PCH SSC reference clock settings
[PATCH 9/9] drm/i915: Initialize PCH refclks at modeset init time
Here's the mai
The reference clock configuration must be done before any mode setting
can occur as all outputs must be disabled to change
anything. Initialize the clocks after turning everything off during
the initialization process.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 10
I can't find any reference clocks which run at 96MHz as seems to be
indicated from the comments in this code.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_di
This eliminates VGA shimmer on some Ironlake machines which have a
CK505 clock source.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm
The PCH refclk settings are global, so we need to look at all of the
encoders, not just the current encoder when deciding how to configure
it. Also, handle systems with more than one panel (any combination of
PCH/non-PCH eDP and LVDS).
Disable SSC clocks when no panels are connected.
Signed-off-b
Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915/intel_display.c |4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
This includes whether an eDP panel is present, and whether that should
use SSC (and at what frequency)
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_bios.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/
This tells the driver whether a CK505 clock source is available on
pre-PCH hardware. If so, it should be used as the non-SSC source,
leaving the internal clock for use as the SSC source.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_bios.
These are all KMS related anyways, so don't hide them under other
debug levels.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_bios.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_bios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 61abef8..4c530fa 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/g
Here's a patch sequence which cleans up a bunch of PCH refclk related
bits. There are a couple of questionable patches that I'd like to see
people look at:
[PATCH 6/9] drm/i915: Fix PCH SSC reference clock settings
[PATCH 9/9] drm/i915: Initialize PCH refclks at modeset init time
Here's the mai
On Mon, Sep 26, 2011 at 21:56, Rob Clark wrote:
> On Mon, Sep 26, 2011 at 2:43 PM, Daniel Vetter wrote:
>> On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
>>> On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
>>> > +/**
>>> > + * drm_gem_get_pages - helper to allocate backing pages fo
On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
> On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
> > +/**
> > + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
> > + * @obj: obj in question
> > + * @gfpmask: gfp mask of requested pages
> > + */
> > +struct pag
On Wed, 21 Sep 2011 22:50:57 -, Michael Witten wrote:
> Whilst working on my failing Radeon GPU:
>
> Subject: Re: Curious experiences with a Radeon on the fritz
> Date: Wed, 21 Sep 2011 18:52:19 -
> Message-ID:
> http://lists.freedesktop.org/archives/dri-devel/2011-September/01450
On Mon, Sep 26, 2011 at 21:51, Tormod Volden wrote:
> On Wed, Sep 21, 2011 at 8:52 PM, Michael Witten wrote:
>> Because my hardware does appear to be malfunctioning due to a corrupt
>> video BIOS, it seems prudent to salvage as much as possible from
>> its output, so that it is possible to figure
On Mon, Sep 26, 2011 at 3:22 PM, Daniel Vetter wrote:
> On Mon, Sep 26, 2011 at 21:56, Rob Clark wrote:
>> On Mon, Sep 26, 2011 at 2:43 PM, Daniel Vetter wrote:
>>> On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
> +/**
On Mon, Sep 26, 2011 at 09:55:44AM -0400, Konrad Rzeszutek Wilk wrote:
> > >> + ? ? commit(crtc);
> > >
> > > So no checking of its return value.. Should you at least wrap
> > > it with WARN_ON(?)
> >
> > Is it safe to rely on the "payload" of the WARN_ON() always being
> > evaluated, or is there
On Mon, Sep 26, 2011 at 2:43 PM, Daniel Vetter wrote:
> On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
>> On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
>> > +/**
>> > + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
>> > + * @obj: obj in question
>> > + *
On Wed, Sep 21, 2011 at 8:52 PM, Michael Witten wrote:
> Because my hardware does appear to be malfunctioning due to a corrupt
> video BIOS, it seems prudent to salvage as much as possible from
> its output, so that it is possible to figure out which other values
> need to be hardcoded in case of f
On Mon, Sep 26, 2011 at 3:22 PM, Daniel Vetter wrote:
> On Mon, Sep 26, 2011 at 21:56, Rob Clark wrote:
>> On Mon, Sep 26, 2011 at 2:43 PM, Daniel Vetter wrote:
>>> On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
> +/**
On Wed, 21 Sep 2011 22:50:57 -, Michael Witten wrote:
> Whilst working on my failing Radeon GPU:
>
> Subject: Re: Curious experiences with a Radeon on the fritz
> Date: Wed, 21 Sep 2011 18:52:19 -
> Message-ID:
> http://lists.freedesktop.org/archives/dri-devel/2011-September/01450
On Mon, Sep 26, 2011 at 21:56, Rob Clark wrote:
> On Mon, Sep 26, 2011 at 2:43 PM, Daniel Vetter wrote:
>> On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
>>> On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
>>> > +/**
>>> > + * drm_gem_get_pages - helper to allocate backing pages fo
On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
> +/**
> + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
> + * @obj: obj in question
> + * @gfpmask: gfp mask of requested pages
> + */
> +struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
> +{
On Mon, Sep 26, 2011 at 2:43 PM, Daniel Vetter wrote:
> On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
>> On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
>> > +/**
>> > + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
>> > + * @obj: obj in question
>> > + *
https://bugs.freedesktop.org/show_bug.cgi?id=38452
--- Comment #7 from Benjamin Bellec 2011-09-26 12:53:56
PDT ---
Yes I guess.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=38452
--- Comment #7 from Benjamin Bellec 2011-09-26 12:53:56
PDT ---
Yes I guess.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
On Mon, Sep 26, 2011 at 01:18:40PM -0500, Rob Clark wrote:
> On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
> > +/**
> > + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
> > + * @obj: obj in question
> > + * @gfpmask: gfp mask of requested pages
> > + */
> > +struct pag
On Mon, Sep 26, 2011 at 09:55:44AM -0400, Konrad Rzeszutek Wilk wrote:
> > >> + commit(crtc);
> > >
> > > So no checking of its return value.. Should you at least wrap
> > > it with WARN_ON(?)
> >
> > Is it safe to rely on the "payload" of the WARN_ON() always being
> > evaluated, or is there
On Thu, Sep 15, 2011 at 5:47 PM, Rob Clark wrote:
> +/**
> + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
> + * @obj: obj in question
> + * @gfpmask: gfp mask of requested pages
> + */
> +struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
> +{
> >> + ? ? commit(crtc);
> >
> > So no checking of its return value.. Should you at least wrap
> > it with WARN_ON(?)
>
> Is it safe to rely on the "payload" of the WARN_ON() always being
> evaluated, or is there any scenario that you could have something like
Hmm, good question. I assumed so, bu
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #12 from Marek Olšák 2011-09-26 09:13:55 PDT ---
The trace helped me to identify and fix the bug. Mesa master should work now.
Could you test it?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=39320
--- Comment #12 from Marek Ol??k 2011-09-26 09:13:55 PDT
---
The trace helped me to identify and fix the bug. Mesa master should work now.
Could you test it?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=41231
Summary: GL_INVALID_ENUM when using glxinfo -l
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: med
https://bugs.freedesktop.org/show_bug.cgi?id=41231
Summary: GL_INVALID_ENUM when using glxinfo -l
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: med
> >> + commit(crtc);
> >
> > So no checking of its return value.. Should you at least wrap
> > it with WARN_ON(?)
>
> Is it safe to rely on the "payload" of the WARN_ON() always being
> evaluated, or is there any scenario that you could have something like
Hmm, good question. I assumed so, bu
https://bugs.freedesktop.org/show_bug.cgi?id=40931
--- Comment #8 from Andy Furniss 2011-09-26
03:18:16 PDT ---
(In reply to comment #7)
> Without attachment 51268 [details] applied, I see the grey area described in
> comment #0
> but when I run
> $ VDPAU_DRIVER=r600 mplayer -fs -aid 0x82 -sid
https://bugs.freedesktop.org/show_bug.cgi?id=40931
--- Comment #8 from Andy Furniss 2011-09-26
03:18:16 PDT ---
(In reply to comment #7)
> Without attachment 51268 [details] applied, I see the grey area described in
> comment #0
> but when I run
> $ VDPAU_DRIVER=r600 mplayer -fs -aid 0x82 -sid
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #20 from chrisdh...@googlemail.com 2011-09-26 03:00:53 PDT ---
(In reply to comment #18)
> Does:
>
> Option "ColorTiling" "false"
>
> in the device section of your xorg.conf help? If so, you may have an old
> version of the 32 bit 3
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #20 from chrisdhaag at googlemail.com 2011-09-26 03:00:53 PDT ---
(In reply to comment #18)
> Does:
>
> Option "ColorTiling" "false"
>
> in the device section of your xorg.conf help? If so, you may have an old
> version of the 32 bi
50 matches
Mail list logo
