Let's be optimistic that for future platforms memory management doesn't change
that much and reuse gen8 function for PPGTT init.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Let's be optimistic that for future platforms this will remain the same
and reorg a bit.
This reorg in if blocks instead of switch make life easier for future
platform support addition.

v2: Jani pointed out I was missing reg_830 for some gen3 platforms. So let's make
    this platforms subcases of Gen checks.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Many distro's have mechanism in place to collect and automatically file
bugs for failed WARN()s.  And since i915 has a lot of hw state sanity
checks which result in WARN(), it generates quite a lot of noise which
is somewhat disconcerting to the end user.

Separate out the internal hw-is-in-the-state-I-expected checks into
I915_STATE_WARN()s and allow configuration via i915.verbose_checks module
param about whether this will generate a full blown stacktrace or just
DRM_ERROR().  The new moduleparam defaults to true, so by default there
is no change in behavior.  And even when disabled, you will still get
an error message logged.

v2: paint the macro names blue, clarify that the default behavior
    remains the same as before
Signed-off-by: NRob Clark <robdclark@gmail.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Otherwise, new platforms without workarounds will hit this warning for
every new context created.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In Gen8+, full ppgtt needs execlist, otherwise the ctx switch can hang.

Also remove the current restriction, a user should be able to explicitly set
ppgtt=2.

Note, this patch considers that execlist support has been enabled by
default on Gen8.

v2: Remove non-default restriction and clarify commit message (Daniel)

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
[danvet: s/comment/commit message/ in the commit message since that's
what Michel meant as per our irc discussion.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With cherryview onwards, Gunit hardware itself save and restore all the
Gunit registers. Skipping the "vlv_save_gunit_s0ix_state" &
"vlv_restore_gunit_s0ix_state" for cherryview in S3/S0ix sequence.
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.

v2: Add comment about timeout threshold. (Tom)
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will allow us to read the number of dispatched compute threads
for GL_ARB_pipeline_statistics_query.
Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move it to a separate function since the main do_execbuffer function
already has so much going on.

v2:
- Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7
  feedback)

Issue: VIZ-4719
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-By: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By adding a new exec_entry flag, we cleanly mark the shadow objects
as purgeable after they are on the active list.

v2:
- Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get
  fnc (danvet, from v4 6/7 feedback)

v3:
- Remove duplicate 'madv = I915_MADV_WILLNEED' (danvet, from v6 4/5)

Issue: VIZ-4719
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-By: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Previously we couldn't trust the user-supplied batch length because
it came directly from userspace (i.e. untrusted code). It would have
affected what commands software parsed without regard to what hardware
would actually execute, leaving a potential hole.

With the parser now copying the user supplied batch buffer and writing
MI_NOP commands to any space after the copied region, we can safely use
the batch length input. This should be a performance win as the actual
batch length is frequently much smaller than the allocated object size.

v2: Fix handling of non-zero batch_start_offset

Issue: VIZ-4719
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-By: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch sets up all of the tracking and copying necessary to
use batch pools with the command parser and dispatches the copied
(shadow) batch to the hardware.

After this patch, the parser is in 'enabling' mode.

Note that performance takes a hit from the copy in some cases
and will likely need some work. At a rough pass, the memcpy
appears to be the bottleneck. Without having done a deeper
analysis, two ideas that come to mind are:
1) Copy sections of the batch at a time, as they are reached
   by parsing. Might improve cache locality.
2) Copy only up to the userspace-supplied batch length and
   memset the rest of the buffer. Reduces the number of reads.

v2:
- Remove setting the capacity of the pool
- One global pool instead of per-ring pools
- Replace batch_obj with shadow_batch_obj and hook into eb->vmas
- Memset any space in the shadow batch beyond what gets copied
- Rebased on execlist prep refactoring

v3:
- Rebase on chained batch handling
- Squash in setting the secure dispatch flag
- Add a note about the interaction w/secure dispatch pinning
- Check for request->batch_obj == NULL in i915_gem_free_request

v4:
- Fix read domains for shadow_batch_obj
- Remove the set_to_gtt_domain call from i915_parse_cmds
- ggtt_pin/unpin in the parser block to simplify error handling
- Check USES_FULL_PPGTT before setting DISPATCH_SECURE flag
- Remove i915_gem_batch_pool_put calls

v5:
- Move 'pending_read_domains |= I915_GEM_DOMAIN_COMMAND' after
  the parser (danvet, from v4 0/7 feedback)

Issue: VIZ-4719
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-By: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described
in the kerneldoc in the patch. The code is simple, but separating
it out makes it easier to change the underlying algorithms and to
extend to future use cases should they arise.

The interface is simple: init to create an empty pool, fini to
clean it up, get to obtain a new buffer. Note that all buffers are
expected to be inactive before cleaning up the pool.

Locking is currently based on the caller holding the struct_mutex.
We already do that in the places where we will use the batch pool
for the command parser.

v2:
- s/BUG_ON/WARN_ON/ for locking assertions
- Remove the cap on pool size
- Switch from alloc/free to init/fini

v3:
- Idiomatic looping structure in _fini
- Correct handling of purged objects
- Don't return a buffer that's too much larger than needed

v4:
- Rebased to latest -nightly

v5:
- Remove _put() function and clean up comments to match

v6:
- Move purged check inside the loop (danvet, from v4 1/7 feedback)

v7:
- Use single list instead of two. (Chris W)
- s/active_list/cache_list
- Squashed in debug patches (Chris W)
  drm/i915: Add a batch pool debugfs file

  It provides some useful information about the buffers in
  the global command parser batch pool.

  v2: rebase on global pool instead of per-ring pools
  v3: rebase

  drm/i915: Add batch pool details to i915_gem_objects debugfs

  To better account for the potentially large memory consumption
  of the batch pool.

v8:
- Keep cache in LRU order (danvet, from v6 1/5 feedback)

Issue: VIZ-4719
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-By: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

After

commit a18c0af1
uthor: Thierry Reding <treding@nvidia.com>
Date:   Wed Dec 10 11:38:49 2014 +0100

    drm: Zero out DRM object memory upon cleanup

we will use the eDP encoder during destroying it. Fix this by calling
drm_encoder_cleanup() at a point when the encoder is not used any more.
This caused a NULL pointer dereference in pps_lock(), I can't see that
it caused any other problem.

All the other encoders seem to call drm_encoder_cleanup() at a safe
place.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've checked that TRANS_DDI_MODE, DP_TP_CTL MST bits are identical to
HSW/BDW on SKL, as well as the long vs short HPD bits. So we have a good
chance to be working as well as prevous platforms.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

2 pieces of code need to read out the DDI clock: the DDI encoder and the
MST encoder .get_config() vfuncs.

Until now the SKL read out code was only in the former, so let's move
the pre and post SKL logic in intel_ddi_clock_get() and this this one
everywhere.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

LFP brighness control from the VBT block 43 indicates which
controller is used for brightness.
LFP1 brightness control method:
Bit 7-4 = This field controller number of the brightnes controller.
0 = Controller 0
1 = Controller 1
2 = Controller 2
3 = Controller 3
Others = Reserved
Bits 3-0 = This field specifies the brightness control pin to be used on the
platform.
0 = PMIC pin is used for brightness control
1 = LPSS PWM is used for brightness control
2 = Display DDI is used for brightness control
3 = CABC method to control brightness
Others = Reserved

Adding the above fields in dev_priv->vbt and corresponding changes in
parse_backlight()

v2: Jani's review comments addressed
	- Move PWM definitions to intel_bios.h
	- Moving vbt_version to intel_vbt_data
	- Rename brightness to bl_ctrl_data
	- Logging just control_pin instead of string
	- Avoid adding vbt_version in dev_priv
	- Since only DDI option is available as of now, let control pin DDI
	affect dev_priv->vbt.backlight.present

v3: Jani's review comments addressed
	- Drop control_pin
	- Use bdb->version
	- set controller to 0 instead of using control pin define
	- check controller bounds
	- remove superfluous changes in intel_parse_bios
Signed-off-by: NDeepak M <m.deepak@intel.com>
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We were incorreectly bypassing the flush everytime which led to fifo
underrun when more than one plane is enabled.
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Satheeshakrishna M<satheeshakrishna.m@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Execlist support in the i915 driver is now considered good enough for the
feature to be enabled by default on Gen8 and later and routinely tested.
Adjusted i915 parameters structure initialization to reflect this and updated
the comment in intel_sanitize_enable_execlists().

There's still work to do before we can let the wider massive onto it,
but there's still time left before the 3.20 cutoff.

v2: Update the MODULE_PARM_DESC too.

Issue: VIZ-2020
Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
[danvet: Add note that there's still some work left to do.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pipe wm parameters is not correctly updated with sprite parameters
because it copies them for each plane from plane_list to the sprite
offset in pipe wm parameters. Since plane_list also contains primary and
cursor planes, we end up updating wrong params for sprites.
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A short section describing background, implementation and intended usage.

v2:
    * Align section name between template and DOC comment. (Michel Thierry)

For: VIZ-4544
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
to map objects into the same address space multiple times.

Added a GGTT view concept and linked it with the VMA to distinguish between
multiple instances per address space.

New objects and GEM functions which do not take this new view as a parameter
assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the
previous behaviour.

This now means that objects can have multiple VMA entries so the code which
assumed there will only be one also had to be modified.

Alternative GGTT views are supposed to borrow DMA addresses from obj->pages
which is DMA mapped on first VMA instantiation and unmapped on the last one
going away.

v2:
    * Removed per view special casing in i915_gem_ggtt_prepare /
      finish_object in favour of creating and destroying DMA mappings
      on first VMA instantiation and last VMA destruction. (Daniel Vetter)
    * Simplified i915_vma_unbind which does not need to count the GGTT views.
      (Daniel Vetter)
    * Also moved obj->map_and_fenceable reset under the same check.
    * Checkpatch cleanups.

v3:
    * Only retire objects once the last VMA is unbound.

v4:
    * Keep scatter-gather table for alternative views persistent for the
      lifetime of the VMA.
    * Propagate binding errors to callers and handle appropriately.

v5:
    * Explicitly look for normal GGTT view in i915_gem_obj_bound to align
      usage in i915_gem_object_ggtt_unpin. (Michel Thierry)
    * Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry)
    * Removed stray semi-colon in i915_gem_object_set_cache_level.

For: VIZ-4544
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
[danvet: Drop hunk from i915_gem_shrink since it's just prettification
but upsets a __must_check warning.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to updated BSpec, Render/Common/media Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.

v2: Update media forcewake range (Ville)
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

From now on for both DSI Ports A & C, the seq_port value has been
set to 0. seq_port value is parsed from Sequence block#53 of VBT.
So, for packets that needs to be read/write for DSI single link on
Port A and Port C will now be based on the DVO port from VBT block 2,
instead of seq_port.
Signed-off-by: NGaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
Now reported by Imre.

v5: Chris suggested to add the case to MISSING_CASE for speedier
debug.

v6: Even some gcc 4.9 versions don't see through the maze, so give up
for now. Keep the skeleton and MISSING_CASE stuff though.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

We consistently use the _irq_handler postfix for functions called in
hardirq context. Especially when it's a non-static function hardirq is
a crazy enough calling context to warrant this level of ocd. So rename
it.

Cc: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: NThomas Daniel <thomas.daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

We already implement this workaround, but it was missing its name.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Stupid userspace (there is no evil userspace in debugfs by assumption)
might provoke a leak since we allocate the new array without holding
any locks. Drop in an unconditional kfree to deal with this - kfree
can handle NULL.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Currently i915_pipe_crc_read() will drop pipe_crc->lock for the entire
duration of the copy_to_user() loop, which means it'll access
pipe_crc->entries without any protection. If another thread sneaks in
and frees pipe_crc->entries the code will oops.

Reorganize the code to hold the lock around everything except
copy_to_user(). After the copy the lock is reacquired and the the number
of available entries is rechecked.

Since this is a debug feature simplify the error handling a bit by
consuming the crc entry even if copy_to_user() would fail.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

pipe_crc->entries[] is an array so allocate with kcalloc() instead of
kzalloc().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Set the pipe_crc->entries pointer while holding the relevant spinlock.
Doesn't matter too much since a spurious pipe crc interrupt would then
just update one entry but later that entry would get cleared when head
and tail are both set to 0. But being a bit more paranoid doesn't hurt.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add the missing CRC control register value for DP port D on CHV.
Untested as I don't have a CHV machine with DP on port D.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a check to only allow DP D on chv, not vlv.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To get stable CRCs from the DP CRC source we need to reset the
scrambler for each frame. Enable the reset feature when grabbing
CRCs for pipe C on CHV. Pipes A and B were already covered due
sharing the code with VLV.

We can safely extend PIPE_SCRAMBLE_RESET_MASK to deal with CHV since
the extra bit was MBZ on the older platforms.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

intel-gpu-tools now generates the render state with license headers and
the version of i-g-t that generated the files.

A similar patch was previously sent but wasn't actually generated with
the make target so was lacking the i-g-t revision. So here another
version before we totally forget about this.

Cc: Armin Reese <armin.c.reese@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No functional changes.

v2 (Paulo): Rebase.
v3: Accept Daniel's suggestions:
    * remove unclear and duplicated explanation.
    * remove marketing like doc and replace by a simple one.
    * remove bdw_fbc_sw_flush documentation.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Due to hardware limitations on BYT, MIPI Port C DPI Enable bit
does not get set. To check whether DSI Port C was enabled in BIOS,
check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C
is linked with Pipe B.

v2: Addressed review comments of Jani, Nikula
    - Used platform checks for this software workaround for BYT
Signed-off-by: NGaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Common bit to be used for both DSI Port A & DSI Port C.
Signed-off-by: NGaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DSI Pll1 is used for enabling DSI on Port C.

v2: Addressed review comments of Jani
    - Used & operator instead of == for intel_dsi->ports
Signed-off-by: NGaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Was missing.

Issue: VIZ-4701
Signed-off-by: NMichael H. Nguyen <michael.h.nguyen@intel.com>
Reviewed-by: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No functional changes. This is just the begin of a FBC rework.

v2 (Paulo):
  - Revert intel_fbc_init() changed parameter.
  - Revert set_no_fbc_reason() rename.
  - Rebase.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>