drm-intel

The upstream i915 driver repository. Maintained by Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, and Tvrtko Ursulin, with a large pool of committers. Consists mostly of drivers/gpu/drm/i915 and include/drm/intel.

See the INTEL DRM I915 DRIVER and INTEL DRM DISPLAY FOR XE AND I915 DRIVERS MAINTAINERS entries for current information on maintainers, mailing lists, bug reporting, etc.

Repository and Branches

https://gitlab.freedesktop.org/drm/i915/kernel

drm-intel-next (aka “din”) and drm-intel-gt-next (aka “dign”)

These are the branches where all drm/i915 patches, both new features and fixes, are applied.

drm-intel-gt-next is for gem/gt code, and drm-intel-next is for everything else, including i915 driver core and display.

These branches “hide” the merge window from the drm/i915 developers; patches are applied here regardless of the development phase of Linus’ upstream kernel. Pull requests to drm-next are sent as needed between -rc1 of the current kernel and the drm feature deadline (-rc5/-rc6 of the current kernel).

Note that drm-intel-next may be cross-merged directly to drm-intel-gt-next, but not vice versa. Syncing drm-intel-gt-next changes back to drm-intel-next must happen via a pull request to drm-next and a backmerge to drm-intel-next.

drm-intel-next-fixes (aka “dinf”)

This branch contains drm/i915 specific fixes to drm-next after the drm/i915 features have been merged there. Fixes are first applied to drm-intel-next, and cherry-picked to drm-intel-next-fixes by maintainers. Valid from drm feature deadline (-rc5/-rc6 of the current kernel) to -rc1 of the next kernel.

Pull requests to drm-next are sent as needed, with no particular schedule.

drm-intel-fixes (aka “-fixes”)

This branch contains fixes to Linus’ tree after drm-next has been merged during the merge window. Fixes are first applied to drm-intel-next, and cherry-picked to drm-intel-fixes by maintainers. The fixes are then merged through drm-fixes. Valid from -rc1 to the kernel release.

Usually Linus releases each -rc on a Sunday, and drm-intel-fixes gets rebased on that the following Monday. Usually this is a fast-forward. The pull request to drm-fixes for new fixes is typically sent on the following Thursday. This is repeated until final release of the kernel.

This is the fastest path to getting fixes to Linus’ tree. It is generally for the regressions, cc:stable, black screens, GPU hangs only, and should pretty much follow the stable rules.

Patch and Merge Flow

This chart describes the flow of patches to drm-intel branches, and the merge flow of the commits to drm and Upstream.

#
# Copyright © 2014-2015 Intel Corporation
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice (including the next
# paragraph) shall be included in all copies or substantial portions of the
# Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
#
# Authors:
#	Jani Nikula <jani.nikula@intel.com>
#

strict digraph "drm-intel" {
       label="upstream, drm-core and drm-intel patch flow and process"

       # upstream
       mw1 [label="v4.X merge window" color=green]
       rc1 [label="v4.X-rc1" color=green]
       rcN [label="v4.X-rcN" color=green]
       release [label="v4.X" color=green]
       mw2 [label="v4.(X+1) merge window" color=green]
       mw3 [label="v4.(X+2) merge window" color=green style=dashed]

       mw1 -> rc1 [label="merge window close" color=green];
       rc1 -> rcN -> rcN [label="release candidate cycles" color=green];
       rcN -> release [label="release" color=green];
       release -> mw2 [label="merge window open" color=green];
       mw2 -> mw3 [label="another release cycle" color=green style=dashed];

       # drm-core
       "drm-next" [color=red]
       "drm-fixes" [color=red]
       "drm-next next" [color=red style=dashed]

       "drm-fixes" -> rcN [label="fixes for current" color=red]
       "drm-fixes" -> release [label="fixes for current" color=red]
       "drm-next" -> mw2 [label="features for next" color=red]
       "drm-next next" -> mw3 [color=red style=dashed]

       # drm-intel
       "drm-intel-fixes" [color=blue]
       "drm-intel-next" [color=blue]
       "drm-intel-next-fixes" [color=blue]
       "drm-intel-next-queued" [label="drm-intel-next-queued\ntopic/* branches" color=blue]
       "drm-intel-testing" [color=blue]
       "drm-intel-internal" [color=blue]

       "drm-intel-fixes" -> "drm-fixes" [label="weekly pulls\nrc1..release" color=blue]
       "drm-intel-next" -> "drm-next next" [label="after ~rc5 of current" color=blue style=dashed]
       "drm-intel-next" -> "drm-next" [label="up to ~rc5 of current" color=blue]
       "drm-intel-next-fixes" -> "drm-next" [label="discretionary pulls\n~rc5..release" color=blue]
       "drm-intel-next-queued" -> "drm-intel-next" [color=blue]
       "drm-intel-next-queued" -> "drm-next" [label="special topic/* branches" color=blue]
       "drm-tip" -> "drm-intel-testing" [label="snapshot for QA" color=blue]

       # other trees in nightly
       "sound/for-linus" [color=yellow style=dashed]
       "sound/for-next" [color=yellow style=dashed]

       # drm-tip
       "drm-tip" [color=yellow]

       # Intel contributions
       "drm-intel-fixes" -> "drm-tip" [label="rebuild" color=blue]
       "drm-intel-next-fixes" -> "drm-tip" [label="rebuild" color=blue]
       "drm-intel-next-queued" -> "drm-tip" [label="rebuild" color=blue]

       # external contributions
       "drm-next" -> "drm-tip" [label="rebuild" color=yellow]
       "drm-fixes" -> "drm-tip" [label="rebuild" color=yellow]
       "sound/for-next" -> "drm-tip" [label="rebuild" color=yellow]
       "sound/for-linus" -> "drm-tip" [label="rebuild" color=yellow]

       # patch flow
       "intel-gfx" [label="intel-gfx mailing list"]
       "internal" [label="internal mailing list"]

       "fixes" -> "intel-gfx"
       "feature patches" -> "intel-gfx"

       "embargoed patches" -> "internal"
       "drm-intel-internal" -> "feature patches" [label="feature release"]

       "internal" -> "drm-intel-internal" [label="maintainers pick\nalways open"]

       "intel-gfx" -> "drm-intel-next-queued" [label="committers/maintainers pick\nalways open"]
       "drm-intel-next-queued" -> "drm-intel-fixes" [label="maintainers cherry-pick\nrc1..rcN of current" color=blue]
       "drm-intel-next-queued" -> "drm-intel-next-fixes" [label="maintainers cherry-pick\n~rc5..release of current" color=blue]
}

Legend: Green = Linus. Red = drm-upstream. Blue = drm-intel. Black = patches. Yellow = Additional trees from/shared with other subsystems.

Features

Features are picked up and pushed to drm-intel-next by committers and maintainers. See drm-intel Committer Guidelines for details.

Fixes

Fixes are picked up and pushed to drm-intel-next by committers and maintainers, just like any other patches. This is to ensure fixes are pushed in a timely manner. Fixes that are relevant for stable, current development kernels, or drm-next, will be cherry-picked by maintainers to drm-intel-fixes or drm-intel-next-fixes.

To make this work, patches should be labeled as fixes (see XXX), and extra care should be put into making fixes the first patches in series, not depending on preparatory work or cleanup.

Merge Timeline

This chart describes the merge timelines for various branches in terms of one kernel release cycle. Worth noting is that we’re working on two or three kernel releases at the same time. Big features take a long time to hit a kernel release. There are no fast paths.

For predictions on the future merge windows and releases, see http://phb-crystal-ball.org/.