On Mon, 26 Sep 2011 23:11:46 -0700, Keith Packard wrote:
> 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.
Ah, now I see
On Mon, 26 Sep 2011 23:11:45 -0700, Keith Packard wrote:
> 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
I think there exists a 100MHz test mode (certainly there is reference to
such in the diagra
On Mon, 26 Sep 2011 23:11:44 -0700, Keith Packard wrote:
> This eliminates VGA shimmer on some Ironlake machines which have a
> CK505 clock source.
>
> Signed-off-by: Keith Packard
References: https://bugzilla.kernel.org/show_bug.cgi?id=21742
References: https://bugs.freedesktop.org/show_bug.cgi
On Mon, 26 Sep 2011 23:11:43 -0700, Keith Packard wrote:
> 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
On Mon, 26 Sep 2011 23:11:42 -0700, Keith Packard wrote:
> Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
>
> Signed-off-by: Keith Packard
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, 26 Sep 2011 23:11:40 -0700, Keith Packard wrote:
> 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
Reviewed-by:
On Mon, 26 Sep 2011 23:11:39 -0700, Keith Packard wrote:
> These are all KMS related anyways, so don't hide them under other
> debug levels.
>
> Signed-off-by: Keith Packard
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, 27 Sep 2011 17:56:39 +0100, Chris Wilson
wrote:
> Ah, now I see why we moved from using the active configuration earlier. ;-)
My evil plan is revealed!
> Doesn't this prevent us from ever using SSC though, as virtually every
> single PCH machine has HDMI encoders that haven't been mask
ting code that I didn't get right?
--
keith.packard at intel.com
-- next part --
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-
On Tue, 27 Sep 2011 17:47:10 +0100, Chris Wilson
wrote:
> On Mon, 26 Sep 2011 23:11:43 -0700, Keith Packard wrote:
> > 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
g requests.
--
keith.packard at intel.com
-- next part --
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/20110927/1b2bebee/attachment.pgp>
> Well I think for this case the solution is simple: Tiling not allowed
> if userspace is too dumb to properly round the buffer up so it
> fulfills whatever odd requirement the hw has. I think hiding the fact
> that certain buffers need more backing storage than a naive userspace
> might assume is
On Mon, 26 Sep 2011 23:11:37 -0700, Keith Packard wrote:
> Ok, so I'd love to know where in any PCH reference matter someone has
> found a place where the reference clock for any of the PLLs is
> anything other than 120MHz. Can someone find a reference for other
> frequencies?
Oddly in the diagr
On Mon, 26 Sep 2011 23:11:46 -0700, Keith Packard wrote:
> 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.
Ah, now I see
On Tue, 27 Sep 2011 10:01:33 +0100, Chris Wilson
wrote:
> Oddly in the diagram SSC4 is given as a 100MHz clock that can be used for
> any output other than DP_A. However, the configuration register marks that
> as being a test-only mode.
Ok, it's all irrelevant -- the only configurations using
On Mon, 26 Sep 2011 23:11:45 -0700, Keith Packard wrote:
> 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
I think there exists a 100MHz test mode (certainly there is reference to
such in the diagra
ith.packard at intel.com
-- next part --
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/20110927/26719730/attachment.pgp>
On Mon, 26 Sep 2011 23:11:44 -0700, Keith Packard wrote:
> This eliminates VGA shimmer on some Ironlake machines which have a
> CK505 clock source.
>
> Signed-off-by: Keith Packard
References: https://bugzilla.kernel.org/show_bug.cgi?id=21742
References: https://bugs.freedesktop.org/show_bug.cgi
On Mon, 26 Sep 2011 23:11:43 -0700, Keith Packard wrote:
> 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
On Mon, 26 Sep 2011 23:11:42 -0700, Keith Packard wrote:
> Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
>
> Signed-off-by: Keith Packard
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Mon, 26 Sep 2011 23:11:40 -0700, Keith Packard wrote:
> 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
Reviewed-by:
On Mon, 26 Sep 2011 23:11:39 -0700, Keith Packard wrote:
> These are all KMS related anyways, so don't hide them under other
> debug levels.
>
> Signed-off-by: Keith Packard
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
https://bugs.freedesktop.org/show_bug.cgi?id=41265
Varban changed:
What|Removed |Added
Component|DRM/other |DRM/Radeon
--- Comment #1 from Varban 2011-09-
https://bugs.freedesktop.org/show_bug.cgi?id=41265
Varban changed:
What|Removed |Added
Component|DRM/other |DRM/Radeon
--- Comment #1 from Varban 2011-09-
https://bugs.freedesktop.org/show_bug.cgi?id=41265
Summary: KMS does not work on Radeon HD6700M
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority
https://bugs.freedesktop.org/show_bug.cgi?id=41265
Summary: KMS does not work on Radeon HD6700M
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority
https://bugs.freedesktop.org/show_bug.cgi?id=41263
--- Comment #1 from Simon Farnsworth 2011-09-27
08:31:26 PDT ---
Forgot to mention - I'm looking at Mesa git, as of:
commit 4c84fbea9d496567d706468113d63cd8f0faeb7f
Author: Brian Paul
Date: Mon Sep 26 20:44:09 2011 -0600
mesa: fix inden
https://bugs.freedesktop.org/show_bug.cgi?id=41263
--- Comment #1 from Simon Farnsworth
2011-09-27 08:31:26 PDT ---
Forgot to mention - I'm looking at Mesa git, as of:
commit 4c84fbea9d496567d706468113d63cd8f0faeb7f
Author: Brian Paul
Date: Mon Sep 26 20:44:09 2011 -0600
mesa: fix inden
https://bugs.freedesktop.org/show_bug.cgi?id=41263
Summary: [r600g] glCopyTexImage2D selects a texture format that
involves fallback to software
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=41263
Summary: [r600g] glCopyTexImage2D selects a texture format that
involves fallback to software
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
On Tue, Sep 27, 2011 at 4:35 AM, Alan Cox wrote:
>> Well I think for this case the solution is simple: Tiling not allowed
>> if userspace is too dumb to properly round the buffer up so it
>> fulfills whatever odd requirement the hw has. I think hiding the fact
>> that certain buffers need more bac
https://bugs.freedesktop.org/show_bug.cgi?id=8874
--- Comment #5 from Michal Suchanek 2011-09-27 07:41:41
PDT ---
isn't this bug 8191 ?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the b
https://bugs.freedesktop.org/show_bug.cgi?id=8874
--- Comment #5 from Michal Suchanek 2011-09-27 07:41:41
PDT ---
isn't this bug 8191 ?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the b
On Tue, Sep 27, 2011 at 4:35 AM, Alan Cox wrote:
>> Well I think for this case the solution is simple: Tiling not allowed
>> if userspace is too dumb to properly round the buffer up so it
>> fulfills whatever odd requirement the hw has. I think hiding the fact
>> that certain buffers need more bac
https://bugs.freedesktop.org/show_bug.cgi?id=39320
Michal Suchanek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=39320
Michal Suchanek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> Well I think for this case the solution is simple: Tiling not allowed
> if userspace is too dumb to properly round the buffer up so it
> fulfills whatever odd requirement the hw has. I think hiding the fact
> that certain buffers need more backing storage than a naive userspace
> might assume is
On Mon, 26 Sep 2011 23:11:37 -0700, Keith Packard wrote:
> Ok, so I'd love to know where in any PCH reference matter someone has
> found a place where the reference clock for any of the PLLs is
> anything other than 120MHz. Can someone find a reference for other
> frequencies?
Oddly in the diagr
38 matches
Mail list logo