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

[Leann Ogasawara]

On 12/03/2012 07:20 AM, Leann Ogasawara wrote:
> 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 3.5.7.1' :
>>
>> 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.

So as I began to dive into this, I had some conversations with the HWE
folks as well as some of the members on our stable maintenance team. 
I'm not convinced now that providing a new drm stack is going to ease
our maintenance burden but rather make it more difficult.  In chatting
with HWE, Intel has already moved onto targeting v3.9 for future changes
to the drm stack.  We will not likely see any further Haswell specific
drm changes for v3.8, ie what we have now won't change much going
forward.  With that in mind, if we took an updated drm snapshot
specifically trying to ease our maintenance burden for Haswell, I think
we would find ourselves actually complicating our maintenance effort. 
We won't be seeing Haswell specific drm changes coming in, but we'll
have to update two different drm stacks for any non-haswell changes.  I
don't think supporting two separate drm stacks is really going to
benefit us.  Additionally, I'm hearing that if we do provide an updated
drm, it will potentially impact to both the versions of udev and
plymouth in Precise which would then need updated and testing as well. 
I think with the improved support we are seeing with the updated
i915_hsw driver I've proposed, we have put ourselves in a much better
position already for supporting Haswell systems in the 12.04.2 point
release via the 12.10 enablement stack.  I think with this improved
support we can afford to table providing an updated drm stack for
Haswell until we have an actual use case to justify us needing to
provide it.

Thanks,
Leann