Apparently there are Apple laptops with magic smoke for a VBIOS, which
we fail to find and use. Default to having and setting up backlight in
this case.

This fixes a regression introduced by
commit c675949e
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Apr 9 11:31:37 2014 +0300

    drm/i915: do not setup backlight if not available according to VBT

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77831Reported-and-tested-by: NMatteo Cypriani <mcy@lm7.fr>
Cc: stable@vger.kernel.org # 3.15+
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually there is eDP. Fix this by looking
into general definition block which will have device configurations. From here
we can figure out what is the LFP type and initialize MIPI only if MIPI
is found.

v2: Addressed review comments by Damien
    - Moved PORT definitions to intel_bios.h and renamed as DVO_PORT_MIPIA
    - renamed is_mipi to has_mipi and moved definition as suggested
    - Check has_mipi inside parse_mipi and intel_dsi_init insted of outside

v3: Make has_mipi as a bitfield as suggested
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: fold in conditions to pack everything neatly below 80 chars.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use defines, do not set anything if VBT has values unknown to us.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Be we read and chase pointers from the VBT, it is prudent to make sure
that those accesses are wholly contained within the MMIO region, or else
we may cause a kernel panic during boot.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make sure that the whole BDB section is within the MMIO region prior to
accessing it contents. That we don't read outside of the secion is left
up to the individual section parsers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This cleans up the checkpatch errors for the merged commit -

commit d3b542fc
Author: Shobhit Kumar <shobhit.kumar@intel.com>
Date:   Mon Apr 14 11:00:34 2014 +0530

    drm/i915: Add parsing support for new MIPI blocks in VBT
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.

v2: Address review comments by Jani
    - adjust code for the structure changes for bdb_mipi_config
    - add boundry and buffer overflow checks as suggested
    - use kmemdup instead of kmalloc and memcpy

v3: More strict check while parsing VBT
    - Ensure that at anytime we do not go beyond sequence block
      while parsing
    - On unknown element fail the whole parsing

v4: Style changes and spell check mostly as suggested by Jani
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The only supported types are none and PWM. Other values are obsolete or
reserved, don't add them.
Tested-by: NKamal Mostafa <kamal@canonical.com>
Tested-by: NMartin <bugs@mrvanes.com>
Tested-by: jrg.otte@gmail.com
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
This information helps us decide if seamless DRRS can be done
at runtime to support certain power saving features. This patch
was tested by setting necessary bit in VBT struct and merging
the new VBT with system BIOS so that we can read the value.

v2: Incorporated review comments from Chris Wilson
Removed "intel_" as a prefix for DRRS specific declarations.

v3: Incorporated Jani's review comments
Removed function which deducts drrs mode from panel_type. Modified some
print statements. Made changes to use DRRS_NOT_SUPPORTED as 0 instead of -1.

v4: Incorporated Jani's review comments.
Modifications around setting vbt drrs_type.
Signed-off-by: NPradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
[danvet: Drop the misleading/redundant comment about the added drrs
field in the vbt struct as discussed with Jani on irc.]
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

MIPI Block #52 which provides configuration details for the MIPI panel
including dphy settings as per panel and tcon specs

Block #53 gives information on panel enable sequences

v2: Address review comemnts from Jani
    - Move panel ids from intel_dsi.h to intel_bios.h
    - bdb_mipi_config structure improvements for cleaner code
    - Adding units for the pps delays, all in ms
    - change data structure to be more cleaner and simple

v3: Corrected the unit for pps delays as 100us
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.

Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".

The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:

$ git grep "i915\." -- drivers/gpu/drm/i915

v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't actually do anything with the information yet, but parse and
log what's in the VBT.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Store the SSC refclock frequency in kHz to get more accuracy. Currently
we're pretending that 66 MHz is ~66000 kHz, when in fact it is actually
~66667 kHz. By storing the less rounded kHz value we get a much better
accuracy for out pixel clock calculations.

Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We had been using a DMI table workaround to select the right
frequency for devices, but this is fragile and must be updated
with every new platform.

Instead the default case when VBT is missing is changed to use
120MHz clock for LVDS SSC for these generations.

The docs for 2010-Core, SandyBridge, and IvyBridge all indicate
that the reference frequency for LVDS is 120MHz:

"2010 Core"
http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf
page 38
Reference Frequency: 120MHz for CRT and LVDS.  100MHz for the FDI.

"2011 SandyBridge"
http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf
page 33
Reference Frequency: 120MHz for CRT, HDMI, LVDS.  100MHz for the FDI.

"2012 IvyBridge"
http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf
page 27
Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI.
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
[olof: Fixup for recent base, switched from if/else to single call]
Signed-off-by: NOlof Johansson <olof@lixom.net>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It only controls the setting of the vbt.edp_support variable, which in
turn only controls one debug output plus can also force-disable the
lvds output.

Since the value only restricted this logic to mobile ilk there's the
slight risk that this will break lvds on desktop ilk or on snb/ivb
platforms. But with the vbt it's better when we know what's going on
here, so let's rip it out and see what happens.

Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's no reason to init a DP connector if the encoder just supports
HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
AUX transactions to detect if there's something there. Same goes for a
DP connector that doesn't support HDMI, but I'm not sure these
actually exist.

v2: - Use bit fields
    - Remove useless identation level
    - Replace DRM_ERROR with DRM_DEBUG_KMS
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Our code makes a lot of assumptions regarding what each DDI port
actually supports, and the VBT should tell us what is really happening
in the hardware. So parse the information provided by the VBT and
check if any of our assumptions is wrong.

Our driver also has a history of not really trusting the VBT, so a
WARN here could mean that:
 a) our coding assumptions are wrong
 b) the VBT is wrong
 c) we're incorrectly parsing the VBT
 d) the checks are wrong

But I really hope we won't ever trigger any of those WARNs.

v2: Don't check the redundant "Capabilities" field from byte 24 since
    it doesn't seem to be used.
v3: Rebase
v4: Replace WARN with DRM_DEBUG_KMS
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Our code currently assumes that port X will use the DP AUX channel X
and the DDC pin X. The VBT should tell us how things are mapped, so
add some WARNs in case we discover our assumptions are wrong (or in
case the VBT is just wrong, which is also perfectly possible).

Why would someone wire port B to AUX C and DDC D?

v2: Rebase
v3: Convert WARNs to DRM_DEBUG_KMS
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We currently use the recommended values from BSpec, but the VBT
specifies the correct value to use for the hardware we have, so use
it. We also fall back to the recommended value in case we can't find
the VBT.

In addition, this code also provides some infrastructure to parse more
information about the DDI ports. There's a lot more information we
could extract and use in the future.

v2: - Move some code to init_vbt_defaults.
v3: - Rebase
    - Clarify the "DVO Port" matching code
v4: - Use I915_MAX_PORTS
    - Change the HAS_DDI checks
    - Replace DRM_ERROR with DRM_DEBUG_KMS
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We currently treat the child_device_config as a simple struct, but
this is not correct: new BDB versions change the meaning of some
offsets, so the struct needs to be adjusted for each version.

Since there are too many changes (today we're in version 170!), making
a big versioned union would be too complicated, so child_device_config
is now a union of 3 things: (i) a "raw" byte array that's safe to use
anywhere; (ii)  an "old" structure that's the one we've been using and
should be safe to keep in the SDVO and TV code; and (iii) a "common"
structure that should contain only fields that are common for all the
known VBT versions.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Initial parsing of the VBT MIPI block. For now, just store the panel id
if found.

Note: Again there seems to be no documentation for this piece of lore.
The doc situation for byt+ is just a bad joke :(
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_i915_private is getting bigger and bigger when adding new vbt stuff.
So, the better way of getting drm_i915_private organized is to create
a special structure for vbt stuff.

v2: Basically conflicts fixes
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Check the VBT to see if the machine has inverted FDI RX polarity on
CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
registers.

This should fix some machines that were showing black screens on all
outputs.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will
be bad for CPU" range when we have PCH_NOP.

There is a bit of a hack in init clock gating. We want to do most of the
clock gating, but the part we skip will hang the system. It could
probably be abstracted a bit better, but I don't feel it's too
unsightly.

v2: Use inverse HAS_PCH_NOP check (Jani)

v3: Actually do what I claimed in v2 (spotted by Daniel)
Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel)
Move LVDS bail into this patch (Ben)

v4: logical rebase conflict resolution with SDEIIR (Ben)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

Brush up patch a bit and resolve conflicts:
- Adjust PCH_NOP checks due to Egbert's hpd handling rework.
- Addd a PCH_NOP check in the irq uninstall code.
- Resolve conflicts with Paulo's SDE irq handling race fix.

v5: Drop the added hunks in the ilk irq handler again, they're bogus.
OOps.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

commit 500a8cc4
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Wed Jan 13 11:19:52 2010 +0800

    drm/i915: parse eDP panel color depth from VBT block

originally introduced parsing bpp for eDP from VBT, with a default of 18
bpp if the eDP BIOS data block is not present. Turns out that default seems
to break the Macbook Pro with retina display, as noted in

commit 4344b813
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Aug 10 11:10:20 2012 +0200

    drm/i915: ignore eDP bpc settings from vbt

Since we can't ignore bpc settings from VBT completely after all, get rid
of the default. Do not clamp eDP to 18 bpp by default if the eDP BDB is
missing from VBT.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NHenrik Rydberg <rydberg@euromail.se>
[danvet: paste in the updated commit message from irc.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

ILK+ have this register on the PCH. This check was triggering unclaimed
writes.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Remove redundant DRM UAPI header #inclusions from drivers/gpu/.

Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and
drm_sarea.h).  They are now #included via drmP.h and drm_crtc.h via a preceding
patch.

Without this patch and the patch to make include the UAPI headers from the core
headers, after the UAPI split, the DRM C sources cannot find these UAPI headers
because the DRM code relies on specific -I flags to make #include "..."  work
on headers in include/drm/ - but that does not work after the UAPI split without
adding more -I flags.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

These are unintuitive.  These are type bool and return -1 casted to true
on failure.  Let's just make it return an int.  The callers don't care,
but let's change this as a cleanup.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Somehow the BIOS manages to screw things up when copying the VBT
around, because the one we scrap from the VBIOS rom actually works.

Cc: stable@kernel.org
Tested-by: NMarkus Heinz <markus.heinz@uni-dortmund.de>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of letting other modules directly access the ->gmbus array,
introduce intel_gmbus_get_adapter() for looking up an i2c_adapter
for a given gmbus port identifier.  This will enable later refactoring
of the gmbus port list.

Note: Before requesting an adapter for a given gmbus port number, the
driver must first check its validity using i2c_intel_gmbus_is_port_valid().
If this check fails, a call to intel_gmbus_get_adapter() will WARN_ON and
return NULL.  This is relevant for parts of the driver that read a port
from VBIOS, which might be improperly initialized and contain an invalid
port.  In these cases, the driver must fall back to using a safer default
port.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently i915 driver checks [PCH_]LVDS register bits to decide
whether to set up the dual-link or the single-link mode.  This relies
implicitly on that BIOS initializes the register properly at boot.
However, BIOS doesn't initialize it always.  When the machine is
booted with the closed lid, BIOS skips the LVDS reg initialization.
This ends up in blank output on a machine with a dual-link LVDS when
you open the lid after the boot.

This patch adds a workaround for that problem by checking the initial
LVDS register value in VBT.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37742Tested-By: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This change enables the use of displays where the vbt table just
contains inappropriate values, but either the vesa defaults or
the video=... modes do something sensible with the attached display.

The problem happens with an embedded board that contains vbt bios
tables that do not match the attached display.  Using this change and
the appropriate kernel boot command line they are able to use an
otherwise completely unusable secondary display on that embedded
board.
Reviewed-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NMathias Froehlich <Mathias.Froehlich@web.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As we warn the user later that we cannot find or load the VBIOS,
explaining why is an exercise in debugging. Shouting *ERROR* upsets
people and produces bug reports.
Reported-by: NMichael Rieder <mr@student.ethz.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43751Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.

The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I have no evidence for this byte being used this way, and lots of
counterexamples.  Restore the struct to its empirical definition and
patch up gmbus setup to match.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This tells the driver whether a CK505 clock source is available on
pre-PCH hardware. If so, it should be used as the non-SSC source,
leaving the internal clock for use as the SSC source.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NChris Wison <chris@chris-wilson.co.uk>

These are all KMS related anyways, so don't hide them under other
debug levels.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NKeith Packard <keithp@keithp.com>