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 for Android: free password hash cracker in your pocket

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

Message-ID: <20100111083825.4c2bb7b3@jbarnes-piketon>
Date:	Mon, 11 Jan 2010 08:38:25 -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 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.

> We do have ppl who run latest kernels on RHEL5 userspace and I'd
> rather not have that break badly, I'm guessing more than 3D will
> break if we remove this, since we need the DRM to allocate memory for
> 2D stuff, and will probably find the fallback to AGP is broken. Again
> Intel ppl would have to do a lot of testing on the fallback before
> removing anything, which is time I don't see anyone willing to spend.

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.

-- 
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/