On Fri, Mar 16, 2012 at 18:41, Takashi Iwai wrote:
> 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.
>
> Signed-off-by: Tak
<#part sign=pgpmime>
On Fri, 16 Mar 2012 22:41:12 +0100, Takashi Iwai wrote:
> +/* read the initial LVDS register value for the given panel mode */
> +static unsigned int get_lvds_reg_val(const struct bdb_header *bdb,
> + const struct bdb_lvds_lfp_data_ptrs *ptrs,
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.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/i915_drv.c |6
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 the revised patch for fixing the wrong LVDS channel mode,
e.g. when booted while the lid is closed. Also, a new module option
to override the LVDS channel mode is added in the second patch.
v1->v2: Fix the register for gen<=4
v2->v3: Check the resolution of the entry to be sure
v3->v
How could this be implemented in a clean way? Of course forcing LVDS on
should become a parameter,
A patch for this was made some time ago, but it was not accepted in the
end. Concerns were that using those force-parameters could be advertised
in internet forums and people use them accidenta
At Fri, 16 Mar 2012 15:55:52 -0400,
Adam Jackson wrote:
>
> On 3/15/12 10:42 AM, Takashi Iwai wrote:
>
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index f851db7..314af26 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drive
On 3/15/12 10:42 AM, Takashi Iwai wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f851db7..314af26 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -356,6 +356,23 @@ static const intel_limit_t
On Fri, Mar 16, 2012 at 12:43:22PM -0400, Sean Paul wrote:
> I have seen a number of "blt ring initialization failed" messages
> where the ctl or start registers are not the correct value. Upon further
> inspection, if the code just waited a little bit, it would read the
> correct value. Adding the
I have seen a number of "blt ring initialization failed" messages
where the ctl or start registers are not the correct value. Upon further
inspection, if the code just waited a little bit, it would read the
correct value. Adding the wait_for to these reads should eliminate the
issue.
Signed-off-by
I have experienced a number of NULL pointer dereferences on
suspend/resume where ring->private is NULL. These come from failed
initialization of the ring buffer. Sincce this doesn't seem to be easily
recoverable, this patch adds a BUG_ON and a bread crumb pointer for
people who might encounter this
These two patches fix/mitigate an issue I was seeing during suspend/resume. I
would see a "blt ring initialization failed" error in the logs, followed by a
NULL dereference in gen6_render_ring_flush shortly after. The first patch adds
a BUG_ON to catch the NULL, and a bread crumb. The second patch
Reviewed-by: Rodrigo Vivi
On Thu, Mar 15, 2012 at 11:42 AM, Takashi Iwai wrote:
> At Thu, 15 Mar 2012 14:30:35 +0100,
> Takashi Iwai wrote:
>>
>> At Thu, 15 Mar 2012 13:25:08 +,
>> Chris Wilson wrote:
>> >
>> > On Thu, 15 Mar 2012 14:15:54 +0100, Takashi Iwai wrote:
>> > > +static bool is_d
13 matches
Mail list logo
