Daniel Vetter wrote
First pull request for 3.5-next, slightly large than usual because new
things kept coming in since the last pull for 3.4.
Highlights:
- first batch of hw enablement for vlv (Jesse et al) and hsw (Eugeni). pci
ids are not yet added, and there's still quite a few patches to merge
(mostly modesetting). To make QA easier I've decided to merge this stuff
in pieces.
- loads of cleanups and prep patches spurred by the above. Especially vlv
is a real frankenstein chip, but also hsw is stretching our driver's
code design. Expect more to come in this area for 3.5.
- more gmbus fixes, cleanups and improvements by Daniel Kurtz. Again,
there are more patches needed (and some already queued up), but I wanted
to split this a bit for better testing.
- pwrite/pread rework and retuning. This series has been in the works for
a few months already and a lot of i-g-t tests have been created for it.
Now it's finally ready to be merged. Note that one patch in this series
touches include/pagemap.h, that patch is acked-by akpm.
- reduce mappable pressure and relocation throughput improvements from
Chris.
- mmap offset exhaustion mitigation by Chris Wilson.
- a start at figuring out which codepaths in our messy dri1/ums+gem/kms
driver we actually need to support by bailing out of unsupported case.
The driver now refuses to load without kms on gen6+ and disallows a few
ioctls that userspace never used in certain cases. More of this will
definitely come.
- More decoupling of global gtt and ppgtt.
- Improved dual-link lvds detection by Takashi Iwai.
- Shut up the compiler + plus fix the fallout (Ben)
- Inverted panel brightness handling (mostly Acer manages to break things
in this way).
- Small fixlets and adjustements and some minor things to help debugging.
Regression-wise QA reported quite a few issues on ivb, but all of them
turned out to be hw stability issues which are already fixed in
drm-intel-fixes (QA runs the nightly regression tests on -next alone,
without -fixes automatically merged in). There's still one issue open on
snb, it looks like occlusion query writes are not quite as cache coherent
as we've expected. With some of the pwrite adjustements we can now
reliably hit this. Kernel workaround for it is in the works."
* 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel: (101 commits)
drm/i915: VCS is not the last ring
drm/i915: Add a dual link lvds quirk for MacBook Pro 8,2
drm/i915: make quirks more verbose
drm/i915: dump the DMA fetch addr register on pre-gen6
drm/i915/sdvo: Include YRPB as an additional TV output type
drm/i915: disallow gem init ioctl on ilk
drm/i915: refuse to load on gen6+ without kms
drm/i915: extract gt interrupt handler
drm/i915: use render gen to switch ring irq functions
drm/i915: rip out old HWSTAM missed irq WA for vlv
drm/i915: open code gen6+ ring irqs
drm/i915: ring irq cleanups
drm/i915: add SFUSE_STRAP registers for digital port detection
drm/i915: add WM_LINETIME registers
drm/i915: add WRPLL clocks
drm/i915: add LCPLL control registers
drm/i915: add SSC offsets for SBI access
drm/i915: add port clock selection support for HSW
drm/i915: add S PLL control
drm/i915: add PIXCLK_GATE register
...
Conflicts:
drivers/char/agp/intel-agp.h
drivers/char/agp/intel-gtt.c
drivers/gpu/drm/i915/i915_debugfs.c
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: Markus Heinz <markus.heinz@uni-dortmund.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
Signed-Off-by: Daniel 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: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Daniel 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=37742
Tested-By: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel 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: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Mathias Froehlich <Mathias.Froehlich@web.de>
Signed-off-by: Daniel 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: Michael Rieder <mr@student.ethz.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43751
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel 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/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Daniel 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: Adam Jackson <ajax@redhat.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith 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: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wison <chris@chris-wilson.co.uk>
These are all KMS related anyways, so don't hide them under other
debug levels.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Various issues involved with the space character were generating
warnings in the checkpatch.pl file. This patch removes most of those
warnings.
Signed-off-by: Akshay Joshi <me@akshayjoshi.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Alan Cox reported a missing check on the kmalloc return value for the
allocation of a temporary mode used for searching for the LVDS downlock
frequency. This allocation is roughly 200 bytes, a little too large to
friviously place on the stack. However, we can simply use the few bytes
we need stored within the original DVO timing data, skip the translation
and do the compare directly between the timing data rather than on a
mode, thus avoiding the need for any temporary allocations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
and fix fallout.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 633f2ea266 and the
attempted fix dcbe6f2b3d.
There is a single clock source used for both SSC (some LVDS and DP) and
non-SSC (VGA, DVI) outputs. So we need to be careful to only enable SSC
as necessary. However, fiddling with DREFCLK was causing DP links to be
dropped and we do not have a fix ready, so revert.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Judging by comments in the BIOS, if the SDVO LVDS option h40 is enabled,
then we are supposed to query the real panel type via Int15. We don't do
this and so for the Sony Vaio VGC-JS210J which has otherwise default
values, we choose the wrong mode.
This patch adds a driver option, i915.vbt_sdvo_panel_type, which can be
used to override the value in the VBT.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33691
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For CRT and SDVO/HDMI, we need to use a normal, non-SSC, clock and so we
must clear any enabling bits left-over from earlier outputs. And also
seems to correct the LVDS panel on the Lenovo U160.
However, at one point, it did cause an "ERROR failed to disable
trancoder". So prolonged testing on top of Jesse's refactored and
error-checking CRTC logic is desired.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The i915 driver normally assumes the video bios has configured several
of the LVDS panel registers, and it just inherits the values. If the
vbios has not run, several of these will need to be setup.
If these are not correct then although the panel looks ok, output from an
HDMI encoder (eg, Chrontel CH7036) will be incorrect.
Signed-off-by: Mark Hayter <mdhayter@chromium.org>
[ickle: minor adjustments]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to workaround the issue with LVDS not working on the Lenovo
U160 apparently due to using the wrong SSC frequency, add an option to
disable SSC.
Suggested-by: Lukács, Árpád <lukacs.arpad@gmail.com>
Bugzillla: https://bugs.freedesktop.org/show_bug.cgi?id=32748
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Fixes the lack of output on the LVDS panel of the Lenovo U160.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31596
Reported-and-tested-by: Dirk Gouders <gouders@et.bocholt.fh-gelsenkirchen.de>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The time between start of the pixel clock and backlight enable is a basic
panel timing constraint. If the Panel Power On/Off registers are found
to be 0, assume we are booting without VBIOS initialization and set these
registers to something reasonable.
Change-Id: Ibed6cc10d46bf52fd92e0beb25ae3525b5eef99d
Signed-off-by: Bryan Freed <bfreed@chromium.org>
[ickle: rearranged into a separate function to distinguish its role from
simply parsing the VBIOS tables.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to use some of these values in eDP configurations, so be sure to
fetch them and store them in the i915 private structure.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Added a function that sets the LVDS values to default settings. This
will be called by intel_init_bios before checking for the VBT (video BIOS
table). The default values are thus loaded regardless of whether a VBT
is found.
The default settings in each parse function have been moved to the new
function. This consolidates all the default settings into one place.
The default dither bit value has been changed from 0 to 1. We can
assume that display devices will want dithering enabled.
Signed-off-by: Simon Que <sque@chromium.org>
Acked-by: Olof Johansson <olof@lixom.net>
[ickle: fixup for -next]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Besides a couple of bugs when writing more than a single byte along the
GMBUS, SDVO was completely failing whilst trying to use GMBUS, so use
bit banging instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
First step, lets have a look at the values for troublesome panels and
see if they may be used to improve our link training.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Previously when converting the GMBUS pin to the GPIO reg, we would
offset the pin by one and then use the look-up table. Now that we first
try to use the GMBUS pin, we no longer need the offset and can use the
value from the VBIOS directly.
Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC (and for other forms of auxiliary communication with external
display controllers). The hope is that this method will be much faster
and more reliable than bit banging for fetching EDIDs from buggy monitors
or through switches, though we still preserve the bit banging as a
fallback in case GMBUS fails.
Based on an original patch by Jesse Barnes.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It is recommended that we use the Video BIOS tables that were copied
into the OpRegion during POST when initialising the driver. This saves
us from having to furtle around inside the ROM ourselves and possibly
allows the vBIOS to adjust the tables prior to initialisation.
On some systems, such as the Samsung N210, there is no accessible VBIOS
and the only means of finding the VBT is through the OpRegion.
v2: Rearrange the code so that ASLE is enabled along with ACPI
v3: Enable OpRegion parsing even without ACPI
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
I'm actually kind of shocked that it works at all otherwise.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Multifunction SDVO cards stopped working after 14571b4, and would report
something that looked remarkably like an ADD2 SPD ROM instead of EDID.
This appears to be because DDC bus selection was utterly horked by that
commit; controlled_output was no longer always a single bit, so
intel_sdvo_select_ddc_bus would pick bus 0, which is (unsurprisingly)
the SPD ROM bus, not a DDC bus.
So, instead of that, let's just use the DDC bus the child device table
tells us to use. I'm guessing at the bitmask and shifting from VBIOS
dumps, but it can't possibly be worse.
cf. https://bugzilla.redhat.com/584229
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
String constants that are continued on subsequent lines with \ will cause
spurious whitespace in the resulting output.
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Eric Anholt <eric@anholt.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[anholt: whacked it to wrap to 80 columns instead]
Signed-off-by: Eric Anholt <eric@anholt.net>
Many platform support this feature, and it can provide significant
power savings when the reduced refresh rate is low. However, on some
platforms a secondary (reduced) timing is provided but not actually
supported by the hardware. This results in undesirable flicker at
runtime.
So disable the feature by default, but allow users to opt-in to the
reduced clock behavior with a new module parameter, lvds_downclock,
that can be set to 1 to enable the feature.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
IGD* isn't a useful name. Replace with the codenames, as sourced from
pci.ids.
Signed-off-by: Adam Jackson <ajax@redhat.com>
[anholt: Fixed up for merge with pineview/ironlake changes]
Signed-off-by: Eric Anholt <eric@anholt.net>
On some laptops there is no HDMI/DP. But the xrandr still reports
several disconnected HDMI/display ports. In such case the user will be
confused.
>DVI1 disconnected (normal left inverted right x axis y axis)
>DP1 disconnected (normal left inverted right x axis y axis)
>DVI2 disconnected (normal left inverted right x axis y axis)
>DP2 disconnected (normal left inverted right x axis y axis)
>DP3 disconnected (normal left inverted right x axis y axis)
This patch set is to use the child device parsed in VBT to decide whether
the HDMI/DP/LVDS/TV should be initialized.
Parse the child device from VBT.
The device class type is also added for LFP, TV, HDMI, DP output.
https://bugs.freedesktop.org/show_bug.cgi?id=22785
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
if no VBT is present, crt_ddc_bus will be left at 0, and cause us
to use that for the GPIO register offset. That's never a valid register
offset, so let the "undefined" value be 0 instead of -1.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
[anholt: clarified the commit message a bit]
Enumerate the LVDS panel timing info entry list in VBT to check whether
the LVDS downclock is found. If found, the downclock is also used to switch
dynamically between low and high frequency for LVDS.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Replace the DRM_DEBUG with DRM_DEBUG_KMS in output device code.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
If the device didn't support EDP, we would bail out too soon.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
[anholt: Pulled this patch out of the patch for adding quirks to
enable reclocking.]
Signed-off-by: Eric Anholt <eric@anholt.net>
IGDNG LVDS SSC uses 120Mhz freq. This fixes one
1600x900 LVDS panel black issue on IGDNG with SSC enabled.
Cc: Stable Team <stable@kernel.org>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
There are several sources of unnecessary power consumption on Intel
graphics systems. The first is the LVDS clock. TFTs don't suffer from
persistence issues like CRTs, and so we can reduce the LVDS refresh rate
when the screen is idle. It will be automatically upclocked when
userspace triggers graphical activity. Beyond that, we can enable memory
self refresh. This allows the memory to go into a lower power state when
the graphics are idle. Finally, we can drop some clocks on the gpu
itself. All of these things can be reenabled between frames when GPU
activity is triggered, and so there should be no user visible graphical
changes.
Signed-off-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Use VBT information to determine which DDC bus to use for CRTDCC.
Fall back to GPIOA if VBT info is not available.
Signed-off-by: David Müller <d.mueller@elsoft.ch>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested on: 855 (David), and 945GM, 965GM, GM45, and G45 (anholt)
This adds embedded DisplayPort support on next mobile chip which
aims to replace origin LVDS port. VBT's driver feature block has
been used to determine the type of current internal panel for eDP
or LVDS.
Currently no panel fitting support for eDP and backlight control
would be added in future.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Now the DVO timing in LVDS data entry is obtained by using the
following step:
a. get the entry size for every LVDS panel data
b. Get the LVDS fp entry for the preferred panel type
c. get the DVO timing by using entry->dvo_timing
In our driver the entry->dvo_timing is related with the size of
lvds_fp_timing. For example: the size is 46.
But it seems that the size of lvds_fp_timing varies on the differnt
platform. In such case we will get the incorrect DVO timing entry
because of the incorrect DVO offset in LVDS panel data entry.
This also removes a hack on new IGDNG to get proper DVO timing.
Calculate the DVO timing offset in LVDS data entry to get the DVO timing
a. get the DVO timing offset in the LVDS fp data entry by using the
pointer definition in LVDS data ptr
b. get the LVDS data entry
c. get the DVO timing by adding the DVO timing offset to data entry
https://bugs.freedesktop.org/show_bug.cgi?id=22787
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
IGDNG mobile chip's LVDS data block removes panel fitting
register definition. So this fixes offset for LVDS timing
block parsing. Thanks for Michael Fu to catch this.
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
