Re: [PATCH 00/62] Broadwell kernel driver support

[Jani Nikula <jani.nikula@linux.intel.com>]

On Sun, 03 Nov 2013, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sat, Nov 02, 2013 at 09:06:58PM -0700, Ben Widawsky wrote:
>> It is my honor and privilege to submit basic Broadwell support on behalf
>> of Intel.
>> 
>> The patch series includes support for Broadwell which should bring it up
>> to feature parity with Haswell. As you'll note, the patches have
>> received some revisions and review already. This is due to our new
>> process (more on this below). We will be rolling out the new Broadwell
>> goodness over time.
>> 
>> Broadwell represents the next generation (GEN8) in Intel graphics
>> processing hardware. Broadwell graphics bring some of the biggest
>> changes we've seen on the execution and memory management side of the
>> GPU. (There are equally large and exciting changes for the userspace
>> drivers.)
>> 
>> My request to reviewers is: I haven't touched these much at all since
>> submitting to the internal mailing list. Most changes are due to rebase.
>> Try to keep bikesheds to a minimum. We want to try to get this code in
>> the 3.13 kernel, so we have a nice base to actually stabilize and
>> improve features for the 3.14 release. Remember, we have that handy
>> 'preliminary hardware support' to allow people to opt-in to this early
>> enabling code. So I'm shooting for stable "end-userable" BDW code in
>> 3.14.
>> 
>> Note that the last few workarounds likely won't be needed, but I think
>> we can include them until we know for sure otherwise.
>> 
>> Aside from the usual set of things we need to update when simply
>> enabling a new platform, What follows are some of the major changes from
>> HSW->BDW:
>> 
>> * There is no longer a forcewake write FIFO. *Most* writes must explicitly
>> wake the GPU.
>> 
>> * Interrupt registers have been completely reorganized.
>> 
>> * PTEs format and cachability settings have changed to more resemble x86
>> PTEs, and PAT
>>   * Address space increases, and as such many commands require changing
>> 
>> * Page table structures have changed for the Per Process GTT. The new
>> structure more resembles traditional page tables with registers defining
>> page directory base.
>> 
>> The latter two changes were the real challenge in enabling the platform
>> and getting things to actually work - though in hindsight, they seem so
>> trivial :-)
>> 
>> You may find these patches here:
>> http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=broadwell
>> 
>> I'll be posting patches for libdrm, and intel-gpu-tools in the next day
>> or two.  They are also ready to go, I just need to do a quick once over.
>> At this point, feel free to stop reading.
>
> Also note that we've spent a decent amount of time refactoring the
> relevant areas in upstream, so now the massive changes for bdw mostly just
> plug in ...
>
> Anyway, review plan. Like Ben said this is still hidden behind the
> preliminary hw support knob. Also I want to get this all merged, final
> testing done and pull request sent by the end of the week. That way we can
> easily get it into 3.13 and that should also reduce the mess I currently
> have with the -internal branch. So
> - Please check register defines really through-roughly.
> - Check for erregious logic fumbles (e.g. in cleanup paths).
> - For everything else which can't be fixed quickly please just propose a
>   FIXME comment.
>
> I've just grabbed a bunch of names from our team and then tried to not
> come up with a too bad split for reviewing:
> Mika: Patches 1-6
> Chris: Patches 7-12
> Paulo: Patches 13-17
> Imre: Patches 18-23
> Damien: Patches 24-29
> Rodrigo: Patches 30-35
> Ville: Patches 36-42
> Ben: Patches 43-47
> Jani: Patches 48-53

I admit defeat with patch 51, maybe someone who's looked at ring
frequencies before could have a peek?

Jani.


> Jesse: Patches 54-58
> Daniel: Patche 59-62
>
> If the patches already has an r-b and hasn't been rebased like crazy since
> then you're lucky ;-)
>
> Please do the all the review on Mon/Tue so that I can spend Wed
> merging (and if needed, fixing up patches) and then we'll have 2 days or
> so for a bit of final integration testing.
>
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center