On Wed, 28 Sep 2011 15:22:48 -0300, Paulo Zanoni przan...@gmail.com wrote:
I also tested the patch you sent today 1 hour ago (inline in one of
the emails) and things still work with it. I'll keep using these
patches since they fix my laptop. Any problem will be reported.
Thanks. I think we're
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.
Also, re-initialize the refclk at resume time.
Signed-off-by: Keith Packard
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
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
> >
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
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
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
-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 96 +-
1 files changed, 59 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6039496..f35 100644
--- a/drivers/gpu/drm
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
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
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
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
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
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
Signed-off-by: Keith Packard kei...@keithp.com
---
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
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 kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu
Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
Signed-off-by: Keith Packard kei...@keithp.com
---
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
This includes whether an eDP panel is present, and whether that should
use SSC (and at what frequency)
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_bios.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915
These are all KMS related anyways, so don't hide them under other
debug levels.
Signed-off-by: Keith Packard kei...@keithp.com
---
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
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 kei...@keithp.com
---
drivers/gpu/drm/i915
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 kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu
-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 96 +-
1 files changed, 59 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6039496..f35 100644
This eliminates VGA shimmer on some Ironlake machines which have a
CK505 clock source.
Signed-off-by: Keith Packard kei...@keithp.com
---
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
On Tue, 27 Sep 2011 10:01:33 +0100, Chris Wilson ch...@chris-wilson.co.uk
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
On Tue, 27 Sep 2011 17:47:10 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Mon, 26 Sep 2011 23:11:43 -0700, Keith Packard kei...@keithp.com 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
On Fri, 23 Sep 2011 08:25:13 +0530, Jesse Barnes
wrote:
> Yeah that sounds good. (2) and (3) are ok cleanups, but it would be
> best if they were a separate patch just in case the subtle timing
> change breaks the panel power sequencing state machine.
Ok, I'll split things up into tiny
On Fri, 23 Sep 2011 08:25:13 +0530, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yeah that sounds good. (2) and (3) are ok cleanups, but it would be
best if they were a separate patch just in case the subtle timing
change breaks the panel power sequencing state machine.
Ok, I'll split
On Wed, 21 Sep 2011 16:56:12 -0400, Akshay Joshi wrote:
> Have we reached a consensus on this? Just curious.
Your patch was merged to Dave Airlie's drm-core-next branch.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not
On Wed, 21 Sep 2011 16:56:12 -0400, Akshay Joshi m...@akshayjoshi.com wrote:
Have we reached a consensus on this? Just curious.
Your patch was merged to Dave Airlie's drm-core-next branch.
--
keith.pack...@intel.com
pgpDbfVeNrjh4.pgp
Description: PGP signature
On Wed, 21 Sep 2011 09:47:59 +0530, Jesse Barnes
wrote:
> I'm worried this makes our PPS even more complex and hard to follow.
> I'd rather see VDD AUX applied only when we need it (dpms, mode set and
> detect; for hotplug we can assume the panel is alive) and that we
> carefully disable it
On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes
wrote:
> This one mixes up lots of cleanups plus the EDID read with the power
> changes.
I think the cleanups are;
1) edp checks inside vdd_on and vdd_off to make the other code a bit
easier to read.
2) Hold VDD on until the end of
On Tue, 20 Sep 2011 17:24:21 +0100, Chris Wilson
wrote:
> On Tue, 20 Sep 2011 08:47:21 -0700, Keith Packard
> wrote:
> > We were relying on the BIOS to set these bits, which doesn't always
> > happen.
>
> Do we need to clear IRQ bits on uninstall, for example to
On Tue, 20 Sep 2011 10:29:23 +0200, Patrik Jakobsson wrote:
> It would be nice to have a model that fits both DSI and SDVO, and the option
> to configure some of it from userspace.
> I thought the purpose of drm_encoder was to abstract hardware like this?
SDVO is entirely hidden by the
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
v2: set the hotplug bits in the irq post-install hook, just
like we do for pre-PCH hardware.
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard kei...@keithp.com
---
v2: set the hotplug bits in the irq post-install hook, just
like we do for pre-PCH hardware.
drivers/gpu/drm/i915/i915_irq.c | 24
drivers
On Tue, 20 Sep 2011 10:29:23 +0200, Patrik Jakobsson
patrik.r.jakobs...@gmail.com wrote:
It would be nice to have a model that fits both DSI and SDVO, and the option
to configure some of it from userspace.
I thought the purpose of drm_encoder was to abstract hardware like this?
SDVO is
On Tue, 20 Sep 2011 17:24:21 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, 20 Sep 2011 08:47:21 -0700, Keith Packard kei...@keithp.com wrote:
We were relying on the BIOS to set these bits, which doesn't always
happen.
Do we need to clear IRQ bits on uninstall, for example
On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This one mixes up lots of cleanups plus the EDID read with the power
changes.
I think the cleanups are;
1) edp checks inside vdd_on and vdd_off to make the other code a bit
easier to read.
2) Hold VDD on
On Wed, 21 Sep 2011 09:47:59 +0530, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I'm worried this makes our PPS even more complex and hard to follow.
I'd rather see VDD AUX applied only when we need it (dpms, mode set and
detect; for hotplug we can assume the panel is alive) and that we
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for everything except Ironlake where it has been
seen to cause trouble with screen updates.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915
I've created a (temporary?) git repository for the drm/i915 driver at
git://people.freedesktop.org/~keithp/linux
This has the drm-intel-next and drm-intel-fixes branches, and may also
have occasional temporary branches with code which has not been merged yet.
--
keith.packard at intel.com
This is a single patch which cleans up almost all of the whitespace
errors in the i915 driver. It currently merges cleanly with your fdo
drm-core-next tree.
I've checked this patch quite carefully, examining the .o files with
objdump -s to make sure nothing significant changed. The only thing
is respected before trying to turn it back on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 93 +-
1 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5bc30f9
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the
turning power on and off to ensure that the
panel is keeping up.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 84 +-
1 files changed, 64 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu
Here's a sequence of eDP patches which are necessary to make the
driver work on the Sandybridge MacBook Air
The key trick was to make sure that the eDP power was applied before
trying to communicate with the device.
On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
wrote:
> I think it's a bit more complex than that. True, there are MIPI
> standards, for the video there are DPI, DBI, DSI, and for the commands
> there is DCS. And, as you mentioned, many panels need custom
> initialization, or support only
On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I think it's a bit more complex than that. True, there are MIPI
standards, for the video there are DPI, DBI, DSI, and for the commands
there is DCS. And, as you mentioned, many panels need custom
initialization,
Here's a sequence of eDP patches which are necessary to make the
driver work on the Sandybridge MacBook Air
The key trick was to make sure that the eDP power was applied before
trying to communicate with the device.
___
dri-devel mailing list
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16
turning power on and off to ensure that the
panel is keeping up.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 84 +-
1 files changed, 64 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers
an awfully long time.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 56 --
2 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers
is respected before trying to turn it back on.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 93 +-
1 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
This is a single patch which cleans up almost all of the whitespace
errors in the i915 driver. It currently merges cleanly with your fdo
drm-core-next tree.
I've checked this patch quite carefully, examining the .o files with
objdump -s to make sure nothing significant changed. The only thing
I've created a (temporary?) git repository for the drm/i915 driver at
git://people.freedesktop.org/~keithp/linux
This has the drm-intel-next and drm-intel-fixes branches, and may also
have occasional temporary branches with code which has not been merged yet.
--
keith.pack...@intel.com
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for everything except Ironlake where it has been
seen to cause trouble with screen updates.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm
On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat
wrote:
> Well, I'm not against sharing the code and not against taking DRM's current
> implementation as a base but the steps required to make it generally
> acceptable
> would be to split it of, probably as a standalone module and
On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen
wrote:
> 2) panel drivers, handles panel specific things. Each panel may support
> custom commands and features, for which we need a dedicated driver. And
> this driver is not platform specific, but should work with any platform
> which has the
I've got this nice patch from Akshay Joshi that removes almost all of
the checkpatch.pl warnings from drm/i915. If I don't merge it now, it's
going to go stale and be useless; if I merge it only to drm-intel-next,
it will be the source of endless conflicts.
However, it's a huge patch (yes, the
On Thu, 15 Sep 2011 17:12:43 +, Florian Tobias Schandinat
wrote:
> Interesting that this comes from the people that pushed the latest mode
> setting
> code into the kernel. But I don't think that this will happen, the exposed
> user
> interfaces will be around for decades and the
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
wrote:
> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> the plan is to make DRM the core Linux display framework, upon which
> everything else is built, and fb and v4l2 are changed to use DRM.
I'd like to think we
On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen
wrote:
> This was a very rough and quite short proposal, but I'm happy to improve
> and extend it if it's not totally shot down.
Jesse Barnes has put together a proposal much like this to work within
the existing DRM environment. This is
On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault wrote:
> At home only. At work, with a different VGA screen, I'm still getting
> the issue.
You're still having a problem with the LVDS screen at work with FBC
disabled? Can you send along a kernel log with drm.debug=5?
--
keith.packard at
On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault wrote:
Non-text part: multipart/mixed
> Hello,
>
> I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
> E6420, but dual head is broken. Here is the scenario:
>
> - Turn computer on with VGA1 connected. Both LVDS1 and VGA1
On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault
samuel.thiba...@ens-lyon.org wrote:
At home only. At work, with a different VGA screen, I'm still getting
the issue.
You're still having a problem with the LVDS screen at work with FBC
disabled? Can you send along a kernel log with
On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
This was a very rough and quite short proposal, but I'm happy to improve
and extend it if it's not totally shot down.
Jesse Barnes has put together a proposal much like this to work within
the existing DRM
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon which
everything else is built, and fb and v4l2 are changed to use DRM.
I'd
On Thu, 15 Sep 2011 17:12:43 +, Florian Tobias Schandinat
florianschandi...@gmx.de wrote:
Interesting that this comes from the people that pushed the latest mode
setting
code into the kernel. But I don't think that this will happen, the exposed
user
interfaces will be around for
I've got this nice patch from Akshay Joshi that removes almost all of
the checkpatch.pl warnings from drm/i915. If I don't merge it now, it's
going to go stale and be useless; if I merge it only to drm-intel-next,
it will be the source of endless conflicts.
However, it's a huge patch (yes, the
On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
2) panel drivers, handles panel specific things. Each panel may support
custom commands and features, for which we need a dedicated driver. And
this driver is not platform specific, but should work with any
On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat
florianschandi...@gmx.de wrote:
Well, I'm not against sharing the code and not against taking DRM's current
implementation as a base but the steps required to make it generally
acceptable
would be to split it of, probably as a
On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault
samuel.thiba...@ens-lyon.org wrote:
Non-text part: multipart/mixed
Hello,
I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
E6420, but dual head is broken. Here is the scenario:
- Turn computer on with VGA1 connected.
be larger than the display bpc.
Signed-off-by: Keith Packard
Reported-by: Oliver Hartkopp
Tested-by: Oliver Hartkopp
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
This is all I've seen since rc3; a couple of tiny fixes, but one has
seen several complaints on the list, so I figured I'd send them in now.
The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)
are available in the git
This is all I've seen since rc3; a couple of tiny fixes, but one has
seen several complaints on the list, so I figured I'd send them in now.
The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)
are available in the git
On Mon, 22 Aug 2011 12:47:49 +0300, Dan Carpenter wrote:
> In linux-next 3.1.0-rc2-next-20110819+ when the screen goes to sleep
> then the screen doesn't refresh properly until I switch to a
> non-graphical TTY and then come back. It does this every time.
> The gnome tool bar at the top of my
On Mon, 22 Aug 2011 12:47:49 +0300, Dan Carpenter erro...@gmail.com wrote:
In linux-next 3.1.0-rc2-next-20110819+ when the screen goes to sleep
then the screen doesn't refresh properly until I switch to a
non-graphical TTY and then come back. It does this every time.
The gnome tool bar at
PCH refclk update code
Keith Packard (6):
drm/i915: Wait for LVDS panel power sequence
drm/i915: Leave LVDS registers unlocked
drm/i915: Fix PCH port pipe select in CPT disable paths
drm/i915: Remove unused 'reg' argument to dp_pipe_enabled
drm/i915: Can't do accurate
On Thu, 14 Jul 2011 19:00:26 +0200, Francesco Allertsen wrote:
> I have tried to boot with the latest git with the commit
> 05bd42688dbc066d4e2689b6f73c0470601f788b reverted (so I have the 'Idling
> fix' and the rc6 enabled), but I have the same freeze.
Can you send me your kernel .config file?
On Wed, 10 Aug 2011 12:20:14 -0400, Andy Lutomirski wrote:
> Can you ack at least this one:
>
> >Revert and fix "drm/i915/dp: remove DPMS mode tracking from DP"
> (i.e. d2b996ac698aebb28557355857927b8b934bb4f9)
>
> for -stable? It fixes an annoying regression in 3.0.
I'm working on a
On Wed, 10 Aug 2011 12:20:14 -0400, Andy Lutomirski l...@mit.edu wrote:
Can you ack at least this one:
Revert and fix drm/i915/dp: remove DPMS mode tracking from DP
(i.e. d2b996ac698aebb28557355857927b8b934bb4f9)
for -stable? It fixes an annoying regression in 3.0.
I'm working
On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes
wrote:
> On Mon, 08 Aug 2011 12:53:31 -0700
> Keith Packard wrote:
>
> > On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes > virtuousgeek.org> wrote:
> >
> > > Yep, it's safe and possible to do on pre-PCH as
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
wrote:
> Yep, it's safe and possible to do on pre-PCH as well. For panel
> fitting we do need to do an actual power cycle when going from
> non-native back to native iirc, but we can still leave them unlocked so
> we don't have to worry about the
On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
wrote:
> Yep, looks fine. The only think we might want to sprinkle about are
> checks for panel off so we can avoid visible corruption if we whack
> timing or fb stuff while the panel is on.
So, I'd like to know if we could unlock the panel
On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes
wrote:
> ...to catch places like this where the wrong register gets used. :)
Ouch! There are only two places we *should* have these loops, one when
turning it off, another when turning it on. There's a couple of loops
which just need to be
On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
wrote:
> Yep, looks fine. The only think we might want to sprinkle about are
> checks for panel off so we can avoid visible corruption if we whack
> timing or fb stuff while the panel is on.
Yeah, could do. Would be nice to somehow get the LVDS
On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yep, looks fine. The only think we might want to sprinkle about are
checks for panel off so we can avoid visible corruption if we whack
timing or fb stuff while the panel is on.
Yeah, could do. Would be nice to
just need to be removed.
Here's a replacement patch:
From 436f2b19cf17c43e4d5ad55b47aeb3660c2af9b9 Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Sat, 6 Aug 2011 10:30:45 -0700
Subject: [PATCH] drm/i915: Wait for LVDS panel power sequence
During mode setting, check to make
701 - 800 of 1027 matches
Mail list logo
