[Quantal][SRU] Updated i915 driver for HSW support

Leann Ogasawara leann.ogasawara at canonical.com
Mon Dec 3 15:20:28 UTC 2012

On 12/03/2012 06:36 AM, Tim Gardner wrote:
> On 12/01/2012 12:13 AM, Leann Ogasawara wrote:
>> BugLink: http://bugs.launchpad.net/bugs/1085245
> <snip>
>> Given this set of patches should be well contained and really only
>> affect Haswell hardware, I propose we try and pull it in for the
>> upcoming Quantal kernel SRU cycle.  It will allow us to ensure we see no
>> regressions on non-Haswell hardware but also allow us to start more
>> widespread testing against the Haswell hardware we do have access to.
>> Thanks,
>> Leann
> Initially I was quite conflicted about this patch set because its a
> bit difficult to asses the impact on existing platforms. Obviously we
> can't regress Haswell GPUs (because they currently don't work at all),
> but I was a bit concerned about regression potential for non-Haswell
> GPUs. I think the best way to look at this patch set is from the
> perspective of what has been changed in the core kernel, e.g., simply
> ignore Haswell specific code. You can see what has changed in the main
> kernel by looking at it thus (after applying all of the Haswell
> patches on top of 'Linux' :
> git log --reverse -p d45afedb9671c093e8c185da7dc84a0dc9697e91..HEAD --
> drivers/gpu/
> With the exception of the patch that creates
> drivers/gpu/drm/drm_mm_hsw.c, everything else is a (mostly) benign
> addition or a bonafide bug fix. Perhaps for clarity drm_mm_hsw.c could
> be moved under the ubuntu directory?
> In general, maintenance of the drm patches are going to be a giant
> pain in the ass simply because _anything_ having to do with Haswell
> won't be considered stable material by upstream (patches from 3.8), so
> we're gonna have to keep an eye out for drm patches that are
> applicable to our bastardized pile.
> Have you considered dropping the whole drm stack from hsw-backport-3.6
> into the ubuntu directory with name space isolation ? Since its pretty
> close to what'll end up in 3.8, it might make maintenance simpler
> since we can relatively easily groom drm and Haswell GPU patches from
> 3.8 and subsequent stable updates. We could also isolate changes from
> LTS Quantal by turning off the config option.

I didn't initially consider pulling a new drm stack as I wanted to keep
the churn to a minimum.  However, if we could keep it cleanly separated
and only affecting Haswell, I don't see any reason why we shouldn't.  I
do think it would make maintenance easier going forward as you've
noted.  I'll take a stab at this and see if it quickly becomes a nightmare.


More information about the kernel-team mailing list