Commit Graph

6877 Commits

Author SHA1 Message Date
Chris Wilson
adca473021 drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq
Also as we set the HOTPLUG_EN to 0 during pre-install, we can simply set
it during post-install, and nor do we wish to enable unwanted hotplug
events.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-21 20:13:35 +02:00
Dave Airlie
f15b4ca2cc Merge tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
Daniel wrote:

The last pull I'd like to squeeze into 3.5, safe for the hsw stuff mostly
bugfixes:
- last few patches for basic hsw enabling (Eugeni, infoframe support by
 Paulo)
- Fix up infoframe support, we've hopefully squashed all the cargo-culting
 in there (Paulo). Among all the issues, this finally fixes some of the
 infoframe regressions seen on g4x and snb systems.
- Fixup sdvo infoframe support, this fixes a regression from 2.6.37.
- Correctly enable semaphores on snb, we've enabled it already for 3.5,
 but the dmar check was slightly wrong.
- gen6 irq fixlets from Chris.
- disable gmbus on i830, the hw seems to be simply broken.
- fix up the pch pll fallout (Chris & me).
- for_each_ring macro from Chris - I've figured I'll merge this now to
 avoid backport pain.
- complain when the rps state isn't what we expect (Chris). Note that this
 is shockingly easy to hit and hence pretty much will cause a regression
 report. But it only tells us that the gpu turbo state got out of whack,
 a problem we know off since a long time (it cause the gpu to get stuck a
 a fixed frequency, usually the lowest one). Chris is working on a fix,
 but we haven't yet found a magic formula that works perfectly (only
 patches that massively reduce the frequency of this happening).
- MAINTAINERS patch, I'm now officially the guy to beat up."

* tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel: (57 commits)
  drm/i915: IBX has a fixed pch pll to pch pipe mapping
  drm/i915: implement hsw_write_infoframe
  drm/i915: small hdmi coding style cleanups
  drm/i915: fixup infoframe support for sdvo
  drm/i915: Enable the PCH PLL for all generations after link training
  drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN
  drm/i915: don't clobber the pipe param in sanitize_modesetting
  drm/i915: disable gmbus on i830
  drm/i915: Replace the feature tests for BLT/BSD with ring init checks
  drm/i915: Check whether the ring is initialised prior to dispatch
  drm/i915: Introduce for_each_ring() macro
  drm/i915: Assert that the transcoder is indeed off before modifying it
  drm/i915: hook Haswell devices in place
  drm/i915: prepare HDMI link for Haswell
  drm/i915: move HDMI structs to shared location
  drm/i915: add WR PLL programming table
  drm/i915: add support for DDI-controlled digital outputs
  drm/i915: detect digital outputs on Haswell
  drm/i915: program iCLKIP on Lynx Point
  drm/i915: program WM_LINETIME on Haswell
  ...
2012-05-21 08:17:42 +01:00
Daniel Vetter
98b6bd998a drm/i915: IBX has a fixed pch pll to pch pipe mapping
This should fix breakage introduced in

commit ee7b9f93fd
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Apr 20 17:11:53 2012 +0100

    drm/i915: manage PCH PLLs separately from pipes

v2: Add a DRM_DEBUG_KMS message to explain why a given pll was
selected, suggested by Chris Wilson.

v3: Actually run git add.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-20 20:48:35 +02:00
Paulo Zanoni
2da8af5405 drm/i915: implement hsw_write_infoframe
Both the control and data registers are completely different now.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-20 17:52:35 +02:00
Paulo Zanoni
ed517fbbbd drm/i915: small hdmi coding style cleanups
- Changed the coding style of auxiliary infoframe functions to make
  them smaller
- Fixed the column alignment of some function definitions
- Remove definition of "struct drm_crtc" in some places as they're
  used only to retrieve "struct intel_crtc"

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-20 17:51:51 +02:00
Daniel Vetter
81014b9d0b drm/i915: fixup infoframe support for sdvo
At least the worst offenders:
- SDVO specifies that the encoder should compute the ecc. Testing also
  shows that we must not send the ecc field, so copy the dip_infoframe
  struct to a temporay place and avoid the ecc field. This way the avi
  infoframe is exactly 17 bytes long, which agrees with what the spec
  mandates as a minimal storage capacity (with the ecc field it would
  be 18 bytes).
- Only 17 when sending the avi infoframe. The SDVO spec explicitly
  says that sending more data than what the device announces results
  in undefined behaviour.
- Add __attribute__((packed)) to the avi and spd infoframes, for
  otherwise they're wrongly aligned. Noticed because the avi infoframe
  ended up being 18 bytes large instead of 17. We haven't noticed this
  yet because we don't use the uint16_t fields yet (which are the only
  ones that would be wrongly aligned).

This regression has been introduce by

3c17fe4b8f is the first bad commit
commit 3c17fe4b8f
Author: David Härdeman <david@hardeman.nu>
Date:   Fri Sep 24 21:44:32 2010 +0200

    i915: enable AVI infoframe for intel_hdmi.c [v4]

Patch tested on my g33 with a sdvo hdmi adaptor.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI)
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-20 17:11:11 +02:00
Dave Airlie
64172ccbe2 drm/kms: fix Kconfig for new drivers.
Reported-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-20 10:10:53 +01:00
Chris Wilson
6f13b7b5be drm/i915: Enable the PCH PLL for all generations after link training
Hidden away within one chipset specific path was the necessary logic to
turn on the PLL. This needs to be done everywhere in order for us to
drive any display! As such as soon as we tested on a non-CougarPoint
chipset, we failed to bring up any DisplayPorts and generated a nice set
of assertion failures in the process. At least one part of our logic is
working, the part that assumes that we have no idea what we are doing.

Reported-by: guang.a.yang@intel.com
References: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 23:10:01 +02:00
Chris Wilson
48da64a8bf drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN
Turn a fatal lockup into a merely blank display with lots of shouty
messages.

v2: Whilst in the area, convert the other BUG_ON into less fatal errors.
In particular, note that we may be called on a PCH platform not using
PLLs, such as Haswell, and so we do not always want to BUG_ON(!pll)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 23:09:50 +02:00
Daniel Vetter
a9dcf84b14 drm/i915: don't clobber the pipe param in sanitize_modesetting
... we need it later on in the function to clean up pipe <-> plane
associations. This regression has been introduced in

commit f47166d2b0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Mar 22 15:00:50 2012 +0000

    drm/i915: Sanitize BIOS debugging bits from PIPECONF

Spotted by staring at debug output of an (as it turns out) totally
unrelated bug.

v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
Chris Wilson.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Cc: stable@kernel.org (the regression was Cc: stable, too)
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:42:54 +02:00
Daniel Vetter
83ee9e6458 drm/i915: disable gmbus on i830
The hw just returns garbage.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838
Reported-and-tested-by: Vladyslav <DFEW.Entwickler@googlemail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:55 +02:00
Chris Wilson
edc912f58e drm/i915: Replace the feature tests for BLT/BSD with ring init checks
When userspace asks whether the driver supports the BLT or BSD rings for
this chip, simply report whether those particular rings are initialised

v2: Use intel_ring_initialized()

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:54 +02:00
Chris Wilson
a15817cf16 drm/i915: Check whether the ring is initialised prior to dispatch
Rather than use the magic feature tests HAS_BLT/HAS_BSD just check
whether the ring we are about to dispatch the execbuffer on is
initialised.

v2: Use intel_ring_initialized()

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:53 +02:00
Chris Wilson
b4519513e8 drm/i915: Introduce for_each_ring() macro
In many places we wish to iterate over the rings associated with the
GPU, so refactor them to use a common macro.

Along the way, there are a few code removals that should be side-effect
free and some rearrangement which should only have a cosmetic impact,
such as error-state.

Note that this slightly changes the semantics in the hangcheck code:
We now always cycle through all enabled rings instead of
short-circuiting the logic.

v2: Pull in a couple of suggestions from Ben and Daniel for
intel_ring_initialized() and not removing the warning (just moving them
to a new home, closer to the error).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Added note to commit message about the small behaviour
change, suggested by Ben Widawsky.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:53 +02:00
Chris Wilson
e7e164db6d drm/i915: Assert that the transcoder is indeed off before modifying it
Inspired by a recent regression that seems to confuse pch transcoder
state, let's be a bit more paranoid.

References: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Pimped commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:52 +02:00
Eugeni Dodonov
c14f52860e drm/i915: hook Haswell devices in place
This patch enables i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:52 +02:00
Eugeni Dodonov
72662e103c drm/i915: prepare HDMI link for Haswell
On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI, and enable the required clocks with correct dividers for the desired
frequency.

Also, we cannot simple reuse HDMI routines from previous generations of
GPU, as most of HDMI-specific stuff is being done via the DDI port
programming instead of HDMI-specific registers.

This commit take advantage of the WR PLL clock table which is in a
separate (previous) commit to select the right divisors for each mode.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:51 +02:00
Eugeni Dodonov
f5bbfca3e5 drm/i915: move HDMI structs to shared location
Move intel_hdmi data structure and support functions to a shared location,
to allow their usage from intel_ddi module.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:51 +02:00
Eugeni Dodonov
12a13a3389 drm/i915: add WR PLL programming table
This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
I split it into a separate patch to simplify the HDMI enabling patch which was
getting huge.

Note that this table is a temporary solution for WR PLL programming. It
will be reworked into a more exact algorithm at a later stage. But for
now, it provides the most accurate clock setting solution, so we use it
here.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:51 +02:00
Eugeni Dodonov
7ceae0a55c drm/i915: add support for DDI-controlled digital outputs
Those are driven by DDIs on Haswell architecture, so we need to keep track
of which DDI is being used on each output.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:50 +02:00
Eugeni Dodonov
0e72a5b55e drm/i915: detect digital outputs on Haswell
Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.

Note that this bit does not indicates whether the output is DP or HDMI.
However, the DDI buffers can be programmed in a way that is shared between
DP/HDMI and FDI/HDMI except for PORT E.

So for now, we detect those digital outputs as being HDMI, but proper DP
support is still pending.

Note that DDI A can only drive eDP, so we do not handle it here for hdmi
initialization.

v2: simplify Haswell handling logic

v3: use generic function for handling digital outputs.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:50 +02:00
Eugeni Dodonov
e615efe4b8 drm/i915: program iCLKIP on Lynx Point
The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
to do so, it must be programmed to properly do the clock ticks according
to the divisor, phase direction, phase increments and a special auxiliary
divisor for 20MHz clock.

v2: calculate divisor values directly instead of relying on a table.

v3: merged a fix from Ben to properly check for invalid divider values.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:49 +02:00
Eugeni Dodonov
1f8eeabf2e drm/i915: program WM_LINETIME on Haswell
The line time can be programmed according to the number of horizontal
pixels vs effective pixel rate ratio.

v2: improve comment as per Chris Wilson suggestion

v3: incorporate latest changes in specs.

v4: move into wm update routine, also mention that the same routine can
program IPS watermarks. We do not have their enablement code yet, nor
handle the required clock settings at the moment, so this patch won't
program those values for now.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:49 +02:00
Eugeni Dodonov
6b8a5eeb9f drm/i915: define Haswell watermarks and clock gating
For now, we simple reuse the Ivy Bridge routines here.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:49 +02:00
Eugeni Dodonov
4abb3c8c71 drm/i915: use ironlake eld write routine for Haswell
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:48 +02:00
Eugeni Dodonov
c82e4d265d drm/i915: support DDI training in FDI mode
Starting with Haswell, DDI ports can work in FDI mode to support
connectivity with the outputs located on the PCH.

This commit adds support for such connections in the intel_ddi module, and
provides Haswell-specific functionality to make it work.

v2: simplify the commit as per Daniel Vetter suggestion.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:48 +02:00
Eugeni Dodonov
45244b8794 drm/i915: initialize DDI buffer translations
DDI is introduced starting with Haswell GPU generation. So to simplify its
management in the future, we also add intel_ddi.c to hold all the
DDI-related items.

Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the connection
parameters. HDMI uses the last pair of values and ignores the first 9
pairs. So we program HDMI values in both cases, which allows HDMI to work
over both FDI and DP-friendly buffers.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:47 +02:00
Eugeni Dodonov
59c859d6f2 drm/i915: account for only one PCH receiver on Haswell
On Haswell, only one pipe can work in FDI mode, so this patch prevents
messing with wrong registers when FDI is being used by non-first pipe. And
to prevent this, we also specify that the VGA can only be used on pipe 0
for now in the crtc_mask value.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:47 +02:00
Eugeni Dodonov
bf507ef7aa drm/i915: handle DDI-related assertions
Prevent bogus asserts on DDI-related paths.

Longer explanation from Eugeni by mail:

"For the asserts there are 3 paths where we hit them:
- in assert_fdi_tx (we don't have the FDI_TX_CTL anymore, backup plan
  DDI_FUNC_CTL is used instead)
- in assert_fdi_tx_pll_enabled (we have the combination of iCLKIP and
  DDI_FUNC_CTL, plus PORT_CLK_SEL and PIPE_CLK_SEL now to make things
  work). We could use an assert here indeed - if we configure port to
  use one clock, and pipe to use another, everything hangs. Right now,
  we configure all of them in one place only; but yes, when DP code
  lands it will get more funky.
- and in ironlake_fdi_pll_enable. I reuse part of this function (to
  configure the TU sizes), but as in the 1st case, FDI_TX_CTL is gone
  so I just ignore it here."

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: Pasted Eugeni's explanation into the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:47 +02:00
Eugeni Dodonov
9d82aa1740 drm/i915: add LPT PCH checks
Avoid bogus asserts and PCH PLL accesses on Lynx Point.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:46 +02:00
Eugeni Dodonov
d0d3e51360 drm/i915: enable power wells on Haswell init
This attempts to enable all the available power wells during the
initialization.

Those power wells can be enabled in parallel or on-demand, and disabled
when no longer needed, but this is out of scope of this initial
enablement. Proper tracking of who uses which power well will require
a considerable rework of our display handling, so we just leave them all
enabled when the driver is loaded for now.

v2: use more generic and future-proof code

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:46 +02:00
Eugeni Dodonov
6ee8bab09d drm/i915: detect PCH encoders on Haswell
On Haswell, the recommended PCH-connected output is the one driven by DDI
E in FDI mode, used for VGA connection. All the others are handled by the
CPU.

Note that this does not accounts for Haswell/PPT combination yet, so if we
encounter such combination an error message is thrown to indicate that
things could go wrong.

v2: improve non-LPT detection warning per Daniel Vetter's suggestion.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:45 +02:00
Eugeni Dodonov
f57e1e3a67 drm/i915: do not use fdi_normal_train on Haswell
This should be already configured when FDI auto-negotiation is done.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:45 +02:00
Eugeni Dodonov
6e4c1677fe drm/i915: show unknown sdvox registers on hdmi init
This will throw a BUG() message when an unknown sdvox register is
given to intel_hdmi_init. When this happens, things could going to be pretty
much broken afterwards, so we better detect this as soon as possible.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:45 +02:00
Eugeni Dodonov
5826eca5ac drm/i915: properly check for pipe count
As suggested by Chris Wilson and Daniel Vetter, this chunk of code can be
simplified with a more simple check.

Also, as noticed by Jesse Barnes, it is worth mentioning that plane is an
enum and num_pipe is an int, so we could be more paranoid here about those
validation checks eventually.

CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:44 +02:00
Eugeni Dodonov
461bc9b587 drm/i915: calculate watermarks for devices that have 3 pipes
This adds proper support for calculating those watermarks, checking for
number of available pipes instead of specific GPU variants when deciding
if watermarks for 3rd pipe are necessary.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:44 +02:00
Eugeni Dodonov
a416edefbb drm/i915: add support for SBI ops
With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.

v2: de-inline the function and address changes in bits names

v3: protect operations with dpio_lock, increase timeout to 100 for
paranoia sake.

v4: decrease paranoia a bit, as noticed by Chris Wilson

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:43 +02:00
Eugeni Dodonov
7d4e146f75 drm/i915: reuse Ivy Bridge interrupts code for Haswell
Haswell interrupts are mostly similar with Ivy Bridge, so we share same
routines with it.

This patch also simplifies the vblank counter handling for all the Gen5+
architectures.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:43 +02:00
Eugeni Dodonov
8c5f5f7c42 drm/i915: add new Haswell DIP controls registers
Haswell has different DIP control registers and offsets which we need to
use for infoframes, which this patch adds.

Note that this does not adds full DIP frames support, but only the basic
functionality necessary for HDMI to work in early enablement.

v2: replace infoframe handling with a debug message, proper support will
be added via a patch from Paulo Zanoni later.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:39:43 +02:00
Chris Wilson
1833b13445 drm/i915: gen6_enable_rps() wants to be called after ring initialisation
Currently we call gen6_enable_rps() (which writes into the per-ring
register mmio space) from intel_modeset_init_hw() which is called before
we initialise the rings. If we defer intel_modeset_init_hw() until
afterwards (in the intel_modeset_gem_init() phase) all is well.

v2: Rectify ordering of gem vs display HW init upon resume. (Daniel)

v3: Fix up locking. (Paulo)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Smash Paulo's locking fix onto Chris' patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19 22:38:29 +02:00
Dave Airlie
4688a69dd1 drm/cirrus/ast/mgag200: fix build without CONFIG_VGA_CONSOLE
Reported-by: Randy Dunlap
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-19 16:34:16 +01:00
Dave Airlie
4271a40900 drm/prime: expose capability flags for userspace.
This lets the kernel tell userspace if the device supports prime
import/export.

This is useful for -modesetting at least, but would be nice for other
drivers.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-18 11:12:16 +01:00
Rafał Miłecki
cfcbd6d3de drm/radeon/hdmi: use new AFMT structs
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-17 12:16:03 +01:00
Alex Deucher
0783986ad7 drm/radeon/hdmi: store info about all AFMT blocks
Introduce special struct radeon_afmt for this purpose.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-17 12:15:40 +01:00
Alex Deucher
1b9c3dd022 drm/radeon: make use of radeon_gem_init() consistent
All radeon_gem_init() does is initialize the gem objects
list.  radeon_device.c does this explicitly.  r600+ calls
radeon_gem_init() so the list gets initialized twice.  Older
asics don't call it at all and rely on the the init in
radeon_device.c.  Just call radeon_gem_init() in radeon_device.c
and remove the explicit calls from all the newer asics.

All asics call radeon_gem_fini() in their fini pathes.  That
could possibly be cleaned up too.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-17 11:46:32 +01:00
Ilija Hadzic
c1d2dbd2ad drm/radeon: eliminate redundant connector_names table
connector_names table is just a repeat of information that
already exists in drm_connector_enum_list and the same string
can be retrieved using drm_get_connector_name function.

Nuke the redundant table and use the proper function to retrieve
the connector name.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-17 11:44:58 +01:00
Michel Dänzer
6f789301fa drm/radeon: Also reset BCI on SI GPU reset.
Without this, e.g. egltri_screen looks scrambled after a GPU reset.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-17 11:44:26 +01:00
Jerome Glisse
455c89b957 drm/radeon: don't mess with hot plug detect for eDP or LVDS connector v2
It seems imac pannel doesn't like whe we change the hot plug setup
and then refuse to work. This help but doesn't fully fix:
https://bugzilla.redhat.com/show_bug.cgi?id=726143

v2: fix typo and improve commit message

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-17 11:43:50 +01:00
Dan Carpenter
10f5ab0405 drm: checking the wrong variable in savage_do_init_bci()
drm_core_ioremap() initializes ->handle.  We already know
"dev->agp_buffer_map" is a valid pointer.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-17 11:42:27 +01:00
Dave Airlie
0333592ff9 gma500: fix build warning
CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c: In function ‘psb_chip_errata’:
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:360:1: warning: no return statement in function returning non-void [-Wreturn-type]
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c: At top level:
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:379:2: warning: initialization from incompatible pointer type [enabled by default]
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:379:2: warning: (near initialization for ‘psb_chip_ops.errata’) [enabled by default]

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-17 11:17:33 +01:00