linux-kernel - Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Jan 2010 12:22:01 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Dave Airlie <airlied@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jerome Glisse <glisse@...edesktop.org>,
	Dave Airlie <airlied@...ux.ie>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	dri-devel@...ts.sourceforge.net
Subject: Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o
  KMS

On Tue, 12 Jan 2010 06:12:37 +1000
Dave Airlie <airlied@...il.com> wrote:

> On Tue, Jan 12, 2010 at 2:38 AM, Jesse Barnes
> <jbarnes@...tuousgeek.org> wrote:
> > On Sun, 10 Jan 2010 07:32:30 +1000
> > Dave Airlie <airlied@...il.com> wrote:
> >> I'm in the 2-3 years at a minimum, with at least one kernel with no
> >> serious regressions in Intel KMS, which we haven't gotten close to
> >> yet. I'm not even sure the Intel guys are taking stable seriously
> >> enough yet. So far I don't think there is one kernel release (even
> >> stable) that works on all Intel chipsets without
> >> backporting patches. 2.6.32 needs the changes to remove the messed
> >> up render clock hacks which should really have been reverted a lot
> >> earlier since we had a lot of regression reports. The number of
> >> users using powersave=0 to get anything approaching useable is
> >> growing etc.
> >
> > But you could apply that argument to the existing DRM code (not just
> > Intel) as well; lots of things are broken or unimplemented and never
> > get fixed.  I'd say the right metric isn't whether regressions are
> > introduced (usually due to new features) but whether the driver is
> > better than the old userspace code.  For Intel at least, I think
> > we're already there.  The quality of the kernel driver is higher
> > and it has many more features than the userspace implementation
> > ever did.  That's just my subjective opinion, but I've done a *lot*
> > of work on our bugs both in userspace and in the kernel, so I think
> > it's an accurate statement.
> 
> The problem is at any single point in time I'm not sure a kms kernel
> exists that works across all the Intel hw, which from a distro POV is
> a real pain in the ass, a regression gets fixed on one piece of hw
> just as another on a different piece gets introduced.
> 
> I'd really like if Intel devs could either slow it down and do more
> testing before pushing to Linus, or be a lot quicker with the reverts
> when stuff is identified. The main thing is the render reclocking
> lately, thats been a nightmare and as far as I can see 2.6.32.3 still
> has all the issues,

Yeah, it may have been better to just revert that early on, but some
users really wanted the power saving features too, so it wasn't totally
clear cut (btw stable has a revert patch queued up now that fixes things
for several people).

> > It doesn't have to happen anytime soon, I was just thinking that
> > removing the old, pre-KMS code would make it easier to avoid
> > introducing regressions since we'd have one less config (a bit one
> > atthat) to worry about.
> 
> Maybe in 3-4 years.

Ouch, it just went from 2-3 to 3-4.  But really the other drm drivers
have to get converted anyway before we can really start killing code.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/