Hack for Ben.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 60e4b9e..ce045a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -62,7 +62,7 @@ module_param_named(semaph
On Wed, Feb 15, 2012 at 11:10:08PM +, Chris Wilson wrote:
> On Wed, 15 Feb 2012 23:50:23 +0100, Daniel Vetter
> wrote:
> > + /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
> > +* pipe_control writes because the gpu doesn't properly redirect them
> > +* through
On Tue, 20 Mar 2012 19:43:04 +0100
Daniel Vetter wrote:
> > new, range specific i915_read/write routines, e.g. i915_read_gt,
> > i915_read_display to make forcewake and register block moves easier
> > to handle
>
> I'm not convinced whether this is a great idea if applied all over the
>
On Tue, Mar 20, 2012 at 11:13:57AM -0700, Jesse Barnes wrote:
> I've been talking with some people offline about potential changes to
> our source structure to make it easier to add support for new chipsets,
> prevent breaking chipsets one doesn't intend to affect, and generally
> make the code mor
Altough Keith's idea is very good I tested here with many systems that
are already working nowadays and it didn't break anything. Including
atom at 945gme, ironlake, sandybridge and ivybridge... including
single and dual channel modes...
Tested-by: Rodrigo Vivi
On Tue, Mar 20, 2012 at 11:57 AM,
I've been talking with some people offline about potential changes to
our source structure to make it easier to add support for new chipsets,
prevent breaking chipsets one doesn't intend to affect, and generally
make the code more readable and maintainable.
I've got some new chipset code ready tha
This was missed when we converted the source values to 16.16 fixed point.
Cc: sta...@vger.kernel.org
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_sprite.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/d
<#part sign=pgpmime>
On Tue, 20 Mar 2012 13:04:41 +0100, Takashi Iwai wrote:
> Since checking the lid state is tricky and unreliable, the practical
> check would be simply reading the first LVDS reg and seeing whether it
> was initialized or not. It seems that it reads to 0x02 when booted
> with
On Tue, 20 Mar 2012 14:38:51 +0100, Daniel Vetter wrote:
> On Fri, Feb 24, 2012 at 09:30:33PM +, Chris Wilson wrote:
> I haven't looked much at the patch, but the deferred-free looks more bogus
> the more I stare at it. As long as an object is active, we /should/ have a
> reference on it, so w
On Fri, Feb 24, 2012 at 09:30:33PM +, Chris Wilson wrote:
> On Fri, 24 Feb 2012 21:13:41 +, Chris Wilson
> wrote:
> > The use of the mm_list by deferred-free breaks the following patches to
> > extend the range of objects tracked. We can simplify things if we just
> > make the unbind duri
Add a new module optoin lvds_channel to specify the LVDS channel mode
explicitly instead of probing the LVDS register value set by BIOS.
This will be helpful when VBT is broken or incompatible with the
current code.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42842
Reviewed-by: Eugeni D
Currently i915 driver checks [PCH_]LVDS register bits to decide
whether to set up the dual-link or the single-link mode. This relies
implicitly on that BIOS initializes the register properly at boot.
However, BIOS doesn't initialize it always. When the machine is
booted with the closed lid, BIOS
Hi,
this is yet another respin of the previous LVDS channel mode fix patches.
v1->v2: Fix the register for gen<=4
v2->v3: Check the resolution of the entry to be sure
v3->v4: Optimize the register reference; add a module option
v4->v5:
Check whether the data points within lvds_fp_data block pro
At Tue, 20 Mar 2012 11:01:22 +0100,
Daniel Vetter wrote:
>
> On Mon, Mar 19, 2012 at 12:07:36PM +0100, Takashi Iwai wrote:
> > Currently i915 driver checks [PCH_]LVDS register bits to decide
> > whether to set up the dual-link or the single-link mode. This relies
> > implicitly on that BIOS initi
On Mon, Mar 19, 2012 at 12:07:36PM +0100, Takashi Iwai wrote:
> Currently i915 driver checks [PCH_]LVDS register bits to decide
> whether to set up the dual-link or the single-link mode. This relies
> implicitly on that BIOS initializes the register properly at boot.
> However, BIOS doesn't initia
15 matches
Mail list logo
