[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#619019: [PATCH 1/2] i915: Remove pipe A force quirk for 855GM and 845G



On Tue, 22 Mar 2011 03:05:45 +0000
Ben Hutchings <ben@decadent.org.uk> wrote:

> On Mon, 2011-03-21 at 07:38 +0000, Chris Wilson wrote:
> > On Sun, 20 Mar 2011 23:07:04 +0000, Ben Hutchings <ben@decadent.org.uk> wrote:
> > > Applying this quirk to the 855GM in all systems causes regressions
> > > (Debian bugs #493096, #619019).  Instead, apply the quirk to specific
> > > models as listed in the old X driver.
> > > 
> > > I don't see any explanation for this quirk being applied to the 845G,
> > > except perhaps that VT switching used to hang if pipe A was turned
> > > off.  However, that seems to be a problem only when using UMS.  So
> > > remove the quirk for the 845G as well.
> > 
> > The quirk should only be required for 830M due to the numerous instances
> > where a unit on the second pipe is actually wired into the clock on the
> > first pipe. (And so it is easiest to keep the first pipe active at all
> > times.)
> 
> When you say 'wired into', is this part of the chip design or something
> done on the board?
> 
> Jesse, why did you add the quirk for other chips?

The DDX driver had an option to force enable pipe A, and we told people
to report bugs when they needed it.  So we got a bunch from Ubuntu and
elsewhere and added them without too much investigation into the root
cause (as you say below it could have been something else).

> > I'd prefer the quirk table to disappear and simply be replaced by
> > IS_830M(). However, that requires testing and so should only be done
> > piecemeal. And leaves some doubt as to why the other machines were in the
> > quirk table in the first place.
> 
> The commit messages referring to VT switching suggest that the problems
> related to disabling part A may actually have been related to handover
> to the console driver before KMS.

Yes, definitely possible.  We didn't have all the assertion checks we
have now, so we may have just been masking other problems without
knowing it.

-- 
Jesse Barnes, Intel Open Source Technology Center



Reply to: