[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: request ring to be pinned above GUC_WOPCM_TOP

== Series Details == Series: series starting with [v2,1/2] drm/i915: request ring to be pinned above GUC_WOPCM_TOP URL : https://patchwork.freedesktop.org/series/17195/ State : success == Summary == Series 17195v1 Series without cover letter

[Intel-gfx] [PATCH 2/2] drm/i915: re-use computed offset bias for context pin

From: Daniele Ceraolo Spurio The context has to obey the same offset requirements as the ring, so we can re-use the same bias value we computed for the ring instead of unconditionally using GUC_WOPCM_TOP. Suggested-by: Chris Wilson

[Intel-gfx] [PATCH v2 1/2] drm/i915: request ring to be pinned above GUC_WOPCM_TOP

From: Daniele Ceraolo Spurio GuC will validate the ring offset and fail if it is in the [0, GUC_WOPCM_TOP) range. The bias is conditionally applied only if GuC loading is enabled (we can't check for guc submission enabled as in other cases because HuC loading

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm: Wrap the check for atomic_commit implementation

== Series Details == Series: series starting with [v4,1/2] drm: Wrap the check for atomic_commit implementation URL : https://patchwork.freedesktop.org/series/17193/ State : success == Summary == Series 17193v1 Series without cover letter

[Intel-gfx] [PATCH v4 2/2] drm: Get atomic property value even if DRIVER_ATOMIC is not set

i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and atomic_commit. drm_object_property_get_value() does not read the correct value of atomic properties if DRIVER_ATOMIC is not set. Checking whether the driver uses atomic modeset is a better check instead as the property values

[Intel-gfx] [PATCH v4 1/2] drm: Wrap the check for atomic_commit implementation

This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool

Re: [Intel-gfx] [PATCH 4/5] drm/i915/guc: Extract param logic form guc_init

On 15/12/16 07:47, Arkadiusz Hiler wrote: Let intel_guc_init() focus on determining and fetching the correct firmware. This patch introduces intel_sanitize_uc_params() that is called from intel_uc_init(). Then, if we have GuC, we can call intel_guc_init() conditionally and we do not have to

Re: [Intel-gfx] [GLK MIPI DSI V2 2/9] drm/i915/glk: Program new MIPI DSI PHY registers for GLK

> -Original Message- > From: Nikula, Jani > Sent: Friday, December 23, 2016 7:27 PM > To: Chauhan, Madhav ; intel- > g...@lists.freedesktop.org > Cc: Conselvan De Oliveira, Ander ; > Saarinen, Jani ;

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

>-Original Message- >From: Hiler, Arkadiusz >Sent: Friday, December 23, 2016 6:22 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine > >Subject: Re: [Intel-gfx] [PATCH 2/8]

[Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format

PSR2 vsc revision number hb2( as per table 6-11)is updated to 4 or 5 based on Y cordinate and Colorimetry Format as below 04h = 3D stereo + PSR/PSR2 + Y-coordinate. 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry Format indication. A DP Source device is allowed to indicate

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: enable FBC on gen9+ too (rev2)

== Series Details == Series: series starting with [1/2] drm/i915: enable FBC on gen9+ too (rev2) URL : https://patchwork.freedesktop.org/series/17176/ State : failure == Summary == Series 17176v2 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Break after walking all GGTT vma in bump_inactive_ggtt

== Series Details == Series: series starting with [01/10] drm/i915: Break after walking all GGTT vma in bump_inactive_ggtt URL : https://patchwork.freedesktop.org/series/17178/ State : success == Summary == Series 17178v1 Series without cover letter

Re: [Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format

On Fri, 23 Dec 2016, "Nagaraju, Vathsala" wrote: > In DP V1.3 spec , Table 2-149 , page number-374 , for Register 0x2210 > , bit 7:4 is reserved. See DP 1.4. BR, Jani. > > -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: rewrite FBC's atomic CRTC-choosing code

Em Sex, 2016-12-23 às 13:29 -0200, Paulo Zanoni escreveu: > Ville pointed out that intel_fbc_choose_crtc() is iterating over all > planes instead of just the primary planes. There are no real > consequences of this problem for HSW+, and for the other platforms it > just means that in some obscure

[Intel-gfx] [PATCH 2/2] drm/i915: rewrite FBC's atomic CRTC-choosing code

Ville pointed out that intel_fbc_choose_crtc() is iterating over all planes instead of just the primary planes. There are no real consequences of this problem for HSW+, and for the other platforms it just means that in some obscure multi-screen cases we'll keep FBC disabled when we could have

[Intel-gfx] [PATCH 04/10] drm/i915: Silence allocation failure during sg_trim()

As trimming the sg table is merely an optimisation that gracefully fails if we cannot allocate a new table, we do not need to report the failure either. Fixes: 0c40ce130e38 ("drm/i915: Trim the object sg table") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 08/10] drm/i915: Eliminate superfluous i915_ggtt_view_normal

Since commit 058d88c4330f ("drm/i915: Track pinned VMA"), there is only one user of i915_ggtt_view_normal rodate. Just treat NULL as no special view in pin_to_display() like everywhere else. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH 09/10] drm/i915: Extact compute_partial_view()

In order to reuse the partial view for selftesting, extract the common function for computing the view. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 48

[Intel-gfx] [PATCH 02/10] drm/i915: Repeat flush of idle work during suspend

The idle work handler is self-arming - if it detects that it needs to run again it will queue itself from its work handler. Take greater care when trying to drain the idle work, and double check that it is flushed. The free worker has a similar issue where it is armed by an RCU task which may be

[Intel-gfx] [PATCH 10/10] drm/i915: Prevent timeline updates whilst performing reset

As the fence may be signaled concurrently from an interrupt on another device, it is possible for the list of requests on the timeline to be modified as we walk it. Take both (the context's timeline and the global timeline) locks to prevent such modifications. Fixes: 80b204bce8f2 ("drm/i915:

[Intel-gfx] [PATCH 05/10] drm/i915: Assert that the partial VMA fits within the object

When creating a partial VMA assert that it first fits with the parent object, and that if it covers the whole of the parent a normal view was created instead. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH 07/10] drm/i915: Eliminate superfluous i915_ggtt_view_rotated

It is only being used to clear a struct and set the type, after which it is overwritten. Since we no longer check the unset bits of the union, skipping the clear is permissible. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH 01/10] drm/i915: Break after walking all GGTT vma in bump_inactive_ggtt

Since commit db6c2b4151f2 ("drm/i915: Store the vma in an rbtree under the object") the vma are once again sorted into GGTT first, then ppGTT so that the typical case of walking the GGTT vma can stop as soon as we find a non-ppGTT. Apply that optimisation. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 03/10] drm/i915: Don't clflush before release phys object

When we teardown the backing storage for the phys object, we copy from the coherent contiguous block back to the shmemfs object, clflushing as we go. Trying to clflush the invalid sg beforehand just oops and would be redundant (due to it already being coherent, and clflushed afterwards).

[Intel-gfx] [PATCH 06/10] drm/i915: Convert i915_ggtt_view to use an anonymous union

Save a lot of characters by making the union anonymous, with the side-effect of ignoring unset bits when comparing views. v2: Roll up the memcmps back into one. Signed-off-by: Chris Wilson Cc: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c

Re: [Intel-gfx] [PATCH v2 11/11] drm/i915: Kill the 830 MI_OVERLAY_OFF workaround

On Thu, Dec 22, 2016 at 09:40:41PM +, Chris Wilson wrote: > On Thu, Dec 22, 2016 at 09:52:22PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Now that we're disabling L2 clock gating MI_OVERLAY_OFF actually works > > on 830, so

Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

On Thu, Dec 22, 2016 at 03:12:20PM -0800, Anusha Srivatsa wrote: > This patch adds the HuC Loading for the BXT by using > the updated file construction. > > Version 1.7 of the HuC firmware. > > v2: rebased. > v3: rebased on top of drm-tip > v4: rebased. > v5: rebased. Rename BXT_FW_MAJOR to

Re: [Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

On Thu, Dec 22, 2016 at 03:12:21PM -0800, Anusha Srivatsa wrote: > This patch adds the support to load HuC on KBL > Version 2.0 > > v2: rebased. > v3: rebased on top of drm-tip > v4: rebased. > v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_ > v6: rebased. Remove old checks. > > Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Thu, Dec 22, 2016 at 03:12:24PM -0800, Anusha Srivatsa wrote: > From: Peter Antoine > > This patch will allow for getparams to return the status of the HuC. > As the HuC has to be validated by the GuC this patch uses the validated > status to show when the HuC is

Re: [Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format

In DP V1.3 spec , Table 2-149 , page number-374 , for Register 0x2210 , bit 7:4 is reserved. -Original Message- From: Jani Nikula [mailto:jani.nik...@linux.intel.com] Sent: Friday, December 23, 2016 6:57 PM To: Nagaraju, Vathsala ;

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

On Thu, Dec 22, 2016 at 03:12:18PM -0800, Anusha Srivatsa wrote: > From: Peter Antoine > > HuC firmware css header has almost exactly same definition as GuC > firmware except for the sw_version. Also, add a new member fw_type > into intel_uc_fw to indicate what kind of

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

On Thu, Dec 22, 2016 at 03:12:17PM -0800, Anusha Srivatsa wrote: > From: Peter Antoine > > Rename some of the GuC fw loading code to make them more general. We > will utilise them for HuC loading as well. > s/intel_guc_fw/intel_uc_fw/g >

Re: [Intel-gfx] [GLK MIPI DSI V2 3/9] drm/i915/glk: Add MIPIIO Enable/disable sequence

On Thu, 15 Dec 2016, Madhav Chauhan wrote: > From: Deepak M > > v2: Addressed Jani's Review comments(renamed bit field macros) > > Signed-off-by: Deepak M > Signed-off-by: Madhav Chauhan > --- >

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Move PFI credit reprogramming into vlv/chv_set_cdclk()

On Fri, Dec 23, 2016 at 03:49:02PM +0200, Ander Conselvan De Oliveira wrote: > On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Move the vlv_program_pfi_credits() into vlv_set_cdclk() and > > chv_set_cdclk() so

Re: [Intel-gfx] [PATCH 14/14] drm/i915: Move ilk_pipe_pixel_rate() to intel_display.c

On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move ilk_pipe_pixel_rate() next to its only caller > (intel_crtc_compute_pixel_rate()). Assuming a rebased patch 1, Reviewed-by: Ander Conselvan de Oliveira

Re: [Intel-gfx] [PATCH v2 13/14] drm/i915: Replace the .modeset_commit_cdclk() hook with a more direct .set_cdclk() hook

On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > With the cdclk state, all the .modeset_commit_cdclk() hooks are > now pointless wrappers. Let's replace them with just a .set_cdclk() > function pointer. However let's

Re: [Intel-gfx] [PATCH i-g-t v2] igt_core: add igt_constructor

On Wed, Dec 21, 2016 at 03:50:18PM -0500, Lyude wrote: > This is a simple macro for executing a block of code at the beginning of > intel-gpu-tools, before any tests have been ran. Useful for > initialization of global resources used in IGT libraries. > > Signed-off-by: Lyude >

Re: [Intel-gfx] [GLK MIPI DSI V2 2/9] drm/i915/glk: Program new MIPI DSI PHY registers for GLK

On Thu, 15 Dec 2016, Madhav Chauhan wrote: > From: Deepak M > > Program the clk lane and tlpx time count registers > to configure DSI PHY. > > v2: Addressed Jani's Review comments(renamed bit field macros) > > Signed-off-by: Deepak M

Re: [Intel-gfx] [GLK MIPI DSI V2 1/9] drm/i915/glk: Add new bit fields in MIPI CTRL register

On Thu, 15 Dec 2016, Madhav Chauhan wrote: > From: Deepak M > > v2: Addressed Jani's Review comments (renamed bit field macros) > > Signed-off-by: Deepak M > Signed-off-by: Madhav Chauhan Pushed to

Re: [Intel-gfx] [PATCH 12/14] drm/i915: Nuke the VLV/CHV PFI programming power domain workaround

On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The hack to grab the pipe A power domain around VLV/CHV cdclk > programming has surely outlived its usefulness. We should be > hold sufficient power domains during any

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Move PFI credit reprogramming into vlv/chv_set_cdclk()

On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move the vlv_program_pfi_credits() into vlv_set_cdclk() and > chv_set_cdclk() so that we can neuter vlv_modeset_commit_cdclk(). > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2 10/14] drm/i915: Pass the cdclk state to the set_cdclk() functions

On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rather than passing all the different parameters (cdclk,vco so > far) sparately to the set_cdclk() functions, just pass the > entire cdclk state. > > v2: Deal with

Re: [Intel-gfx] [PATCH 2/2] drm/i915: rewrite FBC's atomic CRTC-choosing code

On Fri, Dec 23, 2016 at 11:23:56AM -0200, Paulo Zanoni wrote: > Em Sex, 2016-12-23 às 14:43 +0200, Ville Syrjälä escreveu: > > On Fri, Dec 23, 2016 at 10:23:59AM -0200, Paulo Zanoni wrote: > > > > > > Ville pointed out that intel_fbc_choose_crtc() is iterating over > > > all > > > planes instead

Re: [Intel-gfx] [PATCH 06/18] drm/i915/dsi: Move disable pll call outside of clear_device_ready()

On Thu, 01 Dec 2016, Hans de Goede wrote: > On enable intel_dsi_enable() directly calls intel_enable_dsi_pll(), > make intel_dsi_disable() also directly call intel_disable_dsi_pll(), > rather then hiding the call in intel_dsi_clear_device_ready(), > no functional changes. > >

Re: [Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format

On Thu, 22 Dec 2016, vathsala nagaraju wrote: > PSR2 vsc revision number hb2( as per table 6-11)is updated to > 4 or 5 based on Y cordinate and Colorimetry Format as below > 04h = 3D stereo + PSR/PSR2 + Y-coordinate. > 05h = -3D stereo- + PSR/PSR2 + Y-coordinate +

Re: [Intel-gfx] [PATCH 2/2] drm/i915: rewrite FBC's atomic CRTC-choosing code

Em Sex, 2016-12-23 às 14:43 +0200, Ville Syrjälä escreveu: > On Fri, Dec 23, 2016 at 10:23:59AM -0200, Paulo Zanoni wrote: > > > > Ville pointed out that intel_fbc_choose_crtc() is iterating over > > all > > planes instead of just the primary planes. There are no real > > consequences of this

Re: [Intel-gfx] [PATCH] drm/915: Parsing the missed out DTD fields from the VBT

On Thu, 22 Dec 2016, Madhav Chauhan wrote: > From: Vincente Tsou > > The upper bits of the vsync width, vsync offset and hsync width > were not parsed from the VBT. Parse these fields in this patch. > > V2: Renamed lvds dvo timing structure

Re: [Intel-gfx] [PATCH v2 07/14] drm/i915: Start moving the cdclk stuff into a distinct state structure

On Fri, 2016-12-23 at 14:27 +0200, Ville Syrjälä wrote: > On Fri, Dec 23, 2016 at 11:09:22AM +0200, Ander Conselvan De Oliveira wrote: > > > > On Thu, 2016-12-22 at 16:33 +0200, Ville Syrjälä wrote: > > > > > > On Thu, Dec 22, 2016 at 04:14:40PM +0200, Ander Conselvan De Oliveira > > > wrote: >

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: enable FBC on gen9+ too

== Series Details == Series: series starting with [1/2] drm/i915: enable FBC on gen9+ too URL : https://patchwork.freedesktop.org/series/17176/ State : warning == Summary == Series 17176v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/17176/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 2/2] drm/i915: rewrite FBC's atomic CRTC-choosing code

On Fri, Dec 23, 2016 at 10:23:59AM -0200, Paulo Zanoni wrote: > Ville pointed out that intel_fbc_choose_crtc() is iterating over all > planes instead of just the primary planes. There are no real > consequences of this problem for HSW+, and for the other platforms it > just means that in some

Re: [Intel-gfx] [PATCH v2 07/14] drm/i915: Start moving the cdclk stuff into a distinct state structure

On Fri, Dec 23, 2016 at 11:09:22AM +0200, Ander Conselvan De Oliveira wrote: > On Thu, 2016-12-22 at 16:33 +0200, Ville Syrjälä wrote: > > On Thu, Dec 22, 2016 at 04:14:40PM +0200, Ander Conselvan De Oliveira wrote: > > > > > > On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com

[Intel-gfx] [PATCH 2/2] drm/i915: rewrite FBC's atomic CRTC-choosing code

Ville pointed out that intel_fbc_choose_crtc() is iterating over all planes instead of just the primary planes. There are no real consequences of this problem for HSW+, and for the other platforms it just means that in some obscure multi-screen cases we'll keep FBC disabled when we could have

[Intel-gfx] [PATCH 1/2] drm/i915: enable FBC on gen9+ too

Gen9+ platforms have been seeing a lot of screen flickerings and underruns, so I never felt comfortable in enabling FBC on these platforms since I didn't want to throw yet another feature on top of the already complex problem. We now have code that automatically disables FBC if we ever get an

Re: [Intel-gfx] [PATCH v2 09/14] drm/i915: Pass dev_priv to remainder of the cdclk functions

On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Clean up the dev vs. dev_priv straggles that are making things > look inconsistentt. > > v2: Deal with churn > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2 08/14] drm/i915: Track full cdclk state for the logical and actual cdclk frequencies

On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The current dev_cdclk vs. cdclk vs. atomic_cdclk_freq is quite a mess. > So here I'm introducing the "actual" and "logical" naming for our > cdclk state. "actual" is

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check num_pipes before initializing or calling display hooks

== Series Details == Series: drm/i915: Check num_pipes before initializing or calling display hooks URL : https://patchwork.freedesktop.org/series/17173/ State : success == Summary == Series 17173v1 drm/i915: Check num_pipes before initializing or calling display hooks

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Respect num_pipes when install or reset display IRQ

HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Wang, Elaine > Sent: Friday, December 23, 2016 11:04 AM > To: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Respect num_pipes > when

Re: [Intel-gfx] [PATCH v2 07/14] drm/i915: Start moving the cdclk stuff into a distinct state structure

On Thu, 2016-12-22 at 16:33 +0200, Ville Syrjälä wrote: > On Thu, Dec 22, 2016 at 04:14:40PM +0200, Ander Conselvan De Oliveira wrote: > > > > On Mon, 2016-12-19 at 19:28 +0200, ville.syrj...@linux.intel.com wrote: > > > > > > From: Ville Syrjälä > > > > > >

[Intel-gfx] [PATCH] drm/i915: Check num_pipes before initializing or calling display hooks

From: Elaine Wang when num_pipes is zero, it indicates display doesn't exist, so there is no need to initialize display hooks. And to avoid calling these uninitialized display hooks, respect num_pipes at the beginning of intel_modeset_init_hw. intel_init_pm() calls FBC

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Respect num_pipes when install or reset display IRQ

This patch shouldn't impact on platforms that have non-zero num_pipes. The warning happened to snb, which has non-zero num_pipes according to dmesg log "[drm:intel_modeset_init [i915]] 2 display pipes available" in https://intel-gfx-ci.01.org/CI/Patchwork_3383/fi-snb-2520m/dmesg-before.log. So

Re: [Intel-gfx] [PATCH i-g-t v4] lib/debugfs: Support new generic ABI for CRC capture

On Mon, 05 Dec 2016, Tomeu Vizoso wrote: > The kernel has now a new debugfs ABI that can also allow capturing frame > CRCs for drivers other than i915. > > Add alternative codepaths so the new ABI is used if the kernel is recent > enough, and fall back to the legacy

[Intel-gfx] [i-g-t PATCH] README: add libkmod-dev and libprocps3-dev to dependencies

The list is perpetually out of date, but giving an idea of what the dependencies are is helpful. Signed-off-by: Jani Nikula --- README | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README b/README index d302af3f15dd..78a0a244d0ba 100644 --- a/README +++ b/README