drm/i915: simplify sysfs setup code

Positively checking for the required feature/gen is simpler than build
a cascade of negative "we need to bail" checks. And the later won't
scale if we add more stuff that doesn't fit in nicely.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: initialize the parity work only once

This fixes an (albeit really hard to hit) race resulting in an oops:
- The parity work get scheduled.
- We re-init the irq state and call INIT_WORK again.
- The workqueue code tries to run the work item and stumbles over a
  work item that should be on it's runlist.

Also initiliaze the work item unconditionally like all the others,
it's simpler.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: ivybridge_handle_parity_error should be static

Notice by Fengguang Wu's automatic sparse checker.

Reported-by: Fengguang Wu <wfg@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: l3 parity sysfs interface

Dumb binary interfaces which allow root-only updates of the cache
remapping registers. As mentioned in a previous patch, software using
this interface needs to know about HW limits, and other programming
considerations as the kernel interface does no checking for these things
on the root-only interface.

v1: Drop extra posting reads (Chris)
Return negative values in the sysfs interfaces on errors (Chris)

v2: Return -EINVAL for offset % 4 (Jesse)
Move schizo userspace check out (Jesse)
Cleaner sysfs item initializers (Daniel)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remap l3 on hw init

If any l3 rows have been previously remapped, we must remap them after
GPU reset/resume too.

v2: Just return (no warn) on remapping init if not IVB (Jesse)
Move the check of schizo userspace to i915_gem_l3_remap (Jesse)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: enable parity error interrupts

The previous patch put all the code, and handlers in place. It should
now be safe to enable the parity error interrupt. The parity error must
be unmasked in both the GTIMR, and the CS IMR. Unfortunately, the docs
aren't clear about this; nevertheless it's the truth.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Dynamic Parity Detection handling

On IVB hardware we are given an interrupt whenever a L3 parity error
occurs in the L3 cache. The L3 cache is used by internal GPU clients
only.  This is a very rare occurrence (in fact to test this I need to
use specially instrumented silicon).

When a row in the L3 cache detects a parity error the HW generates an
interrupt. The interrupt is masked in GTIMR until we get a chance to
read some registers and alert userspace via a uevent. With this
information userspace can use a sysfs interface (follow-up patch) to
remap those rows.

Way above my level of understanding, but if a given row fails, it is
statistically more likely to fail again than a row which has not failed.
Therefore it is desirable for an operating system to maintain a lifelong
list of failing rows and always remap any bad rows on driver load.
Hardware limits the number of rows that are remappable per bank/subbank,
and should more than that many rows detect parity errors, software
should maintain a list of the most frequent errors, and remap those
rows.

V2: Drop WARN_ON(IS_GEN6) (Jesse)
DRM_DEBUG row/bank/subbank on errror (Jesse)
Comment updates (Jesse)

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: s/mdelay/msleep/ in the sdvo detect function

A 30 ms delay is simply way too big to waste cpu cycles on.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: reuse the sdvo tv clock adjustment in ilk mode_set

Jesse extracted this nice helper in his i9xx_crtc_mode_set refactor,
but we have the identical code in ironlake_ccrtc_mode_set. And that
function is huge, so extracting some code full of magic numbers is
always nice.

Noticed while trying to get a handle on our dp clock code.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: there's no cxsr on ilk

Already discovered in

commit 5a117db77e47e3946d1aaa7ce8deafafd9d76746
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date:   Thu Jan 5 09:34:29 2012 -0200

    drm/i915: there is no pipe CxSR on ironlake

but we've failed to rip out the code from the ironlake specific code.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add some barriers when changing DIPs

On IVB and older, we basically have two registers: the control and the
data register. We write a few consecutitve times to the control
register, and we need these writes to arrive exactly in the specified
order.

Also, when we're changing the data register, we need to guarantee that
anything written to the control register already arrived (since
changing the control register can change where the data register
points to). Also, we need to make sure all the writes to the data
register happen exactly in the specified order, and we also *can't*
read the data register during this process, since reading and/or
writing it will change the place it points to.

So invoke the "better safe than sorry" rule and just be careful and
put barriers everywhere :)

On HSW we still have a control register that we write many times, but
we have many data registers.

Demanded-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove comment about HSW HDMI DIPs

HSW support is now just like all the other generations: we send AVI
and SPD InfoFrames. There are other DIPs for HSW, but there are other
DIPs for the previous generations too. For each gen, we can see which
DIPs are missing by looking at the 'set_infoframes' function: we
explicitly disable the DIPs we're not using.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI

The register that controls the HDMI port can be used to control the
sDVO port. Some bits are defined only for sDVO, and SDVO_BORDER_ENABLE
is one of those: HDMI ports that can't be used in sDVO mode don't even
have this bit defined in their specifications.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't write 0 to DIP control at HDMI init

At this time, the HDMI port is enabled, and the DIP control register
specification says we need to disable the port *before* disabling the
DIPs. Also, while doing this we risk telling the HW to send the AVI
DIPs once (not every VSync), which really seems to confuse the HW and
trigger bugs where the DIPs are not sent.

This code was here just to set the DIP register to a 'known state'
before using it, but since now the set_infoframes functions already
set the control registers to a known state, this code can go away.

Also, the previous code disables *all* the DIP registers for *each*
HDMI port, so we end disabling each DIP register more than once.

This patch solves a problem I can reproduce on my IVB machine. When I
boot it with just a single HDMI monitor, the AVI InfoFrames are not
sent. With this patch, the InfoFrames are sent. Previously, I wrote a
patch to 'touch the DIP registers after we enable the HDMI port' to
solve this same problem, but that patch doesn't seem to be needed
anymore after this patch.

All this patch does is revert a chunk of the following commit:

    commit 64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b
    Author: Jesse Barnes <jbarnes@virtuousgeek.org>
    Date:   Thu Sep 22 11:16:00 2011 +0530

        drm/i915: fix ILK+ infoframe support

So bugs that can be bisected to that commit may be fixed now.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43256
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: disable DIP while changing the port

The register specification says we need to do this.

V2: Only write the register if the port is enabled.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: explicitly disable the DIPs we're not using

From this point on, the 'set_infoframe' functions always set the DIP
registers to a known state, so anything done will always be undone at
the modeset.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't wait for vblank while writing InfoFrames

This function is called when the pipe is disabled, so it always gets
the 50ms timeout.

This function is called once for each InfoFrame, so we actually get a
100ms timeout. Will be more if we add more InfoFrames.

Also, the spec says we need to "wait for a VSync to ensure completion
of any pending DIP transmissions", not for a VBlank. OTOH, the
register documentation suggests that the DIPs are sent *during* the
VSync, so shouldn't we be waiting until *after* the VSync to ensure
all DIPs are sent?

So this wait_for_vblank seems, besides useless, totally wrong.

If we ever want to change some specific InfoFrame on-the-fly (outside
of the modeset code), the code that changes the InfoFrame will have to
do the waiting itself, and properly.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: enable DIP before enabling each InfoFrame

So the write_infoframe function can assume the DIP is on.

V2: Be more defensive and add WARN().

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: only set the HDMI port on the DIP once

Not once for each InfoFrame. Now we have a function that allows us to
do this.

[danvet: Paulo clarified on irc that a later bugfix patch needs this
cleanup.]

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: properly alternate between DVI and HDMI

This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.

When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.

When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.

Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.

This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
  - drm/i915: don't write 0 to DIP control at HDMI init

[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]

V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add set_infoframes to struct intel_hdmi

We need a function that is able to fully 'set' the state of the DIP
registers to a known state.

Currently, we have the write_infoframe function that is called twice:
once for AVI and once for SPD. The problem is that write_infoframe
tries to keep the state of the DIP register as it is, changing only
the minimum necessary bits. The second problem is that
write_infoframe does twice (once for each time it is called) some
work that should be done only once (like waiting for vblank and
setting the port). If we add even more DIPs, it will do even more
repeated work.

This patch only adds the infrastructure keeping the code behavior the
same as before.

v2: add static keywords

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/hdmi: Fix reg values for g4x_hdmi_connected

Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the
separate HDMI registers where introduced with the first PCH) and so
g4x_hdmi_connected() never selected the right bit and always returned
disconnected.

Regression in

commit 8ec22b214d76773c9d89f4040505ce10f677ed9a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 11 18:01:34 2012 +0100

    drm/i915/hdmi: Query the live connector status bit for G4x

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: s/i915_wait_request/i915_wait_seqno/g

Wait request is poorly named IMO. After working with these functions for
some time, I feel it's much clearer to name the functions more
appropriately.

Of course we must update the callers to use the new name as well.

This leaves room within our namespace for a *real* wait request function
at some point.

Note to maintainer: this patch is optional.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: wait render timeout ioctl

This helps implement GL_ARB_sync but stops short of allowing full blown
sync objects. Finally we can use the new timed seqno waiting function
to allow userspace to wait on a buffer object with a timeout. This
implements that interface.

The IOCTL will take as input a buffer object handle, and a timeout in
nanoseconds (flags is currently optional but will likely be used for
permutations of flush operations). Users may specify 0 nanoseconds to
instantly check.

The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
non-zero timeout parameter the wait ioctl will wait for the given number
of nanoseconds on an object becoming unbusy. Since the wait itself does
so holding struct_mutex the object may become re-busied before this
completes. A similar but shorter race condition exists in the busy
ioctl.

v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
Flush the object from the gpu write domain (Chris + Daniel)
Fix leaked refcount in good case (Chris)
Naturally align ioctl struct (Chris)

v3: Drop lock after getting seqno to avoid ugly dance (Chris)

v4: check for 0 timeout after olr check to allow polling (Chris)

v5: Updated the comment. (Chris)

v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
Fix the commit message comment to be less ugly (Ben)
Add a warning to check the return timespec (Ben)

v7: Use DRM_AUTH for the ioctl. (Eugeni)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: improve i915_wait_request_begin trace

The trace events adds whether or not the wait was blocking. Blocking in
this case means to hold struct_mutex (ie. no new work can be submitted
during the wait). The information is inherently racy.

The blocking information is racy since mutex_is_locked doesn't check
that the current thread holds the lock. The only other option would be
to pass the boolean information of whether or not the class was blocking
down through the stack which is less desirable.

v2: Don't do a trace event per loop. (Chris)
Only get blocking/non-blocking info (Chris)

v3: updated comment in code as well as commit msg (Daniel)
Add "(NB)" to trace information to remind us in 6 months (Ben)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: timeout parameter for seqno wait

Insert a wait parameter in the code so we can possibly timeout on a
seqno wait if need be. The code should be functionally the same as
before because all the callers will continue to retry if an arbitrary
timeout elapses.

We'd like to have nanosecond granularity, but the only way to do this is
with hrtimer, and that doesn't fit well with the needs of this code.

v2: Fix rebase error (Chris)
Return proper time even in wedged + signal case (Chris + Ben)
Use timespec constructs (Ben)
Didn't take Daniel's advice regarding the Frankenstein-ness of the
  function. I did try his advice, but in the end I liked the way the
  original code looked, better.

v3: Make wakeups far less frequent for infinite waits (Chris)

v4: Remove dummy_wait variable (Daniel)
Use raw monotonic time instead of jiffies (made the code a bit cleaner) (Ben)
Added a couple of warnings (Ben)

v5: Remove warnings (Daniel)
Use more accurate time diff for default case (Daniel)
Bikeshed for setting the return timespec in timeout case (Daniel)
s/jiffies/time in one of the comments

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't silently ignore sdvo mode_set failures

Unfortunately we can't abort a mode_set, but at least tell the user
that something might have gone wrong when setting the sdvo input or
output timing fails.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: clarify preferred sdvo input mode code

- kill intel_sdvo->input_dtd, it's only used as a temporary variable,
  we store the preferred input mode in the adjusted mode at mode_fixup
  time.
- rename the function to make it clear what we want it to do (get the
  preferred mode) and say in a comment what it unfortunately does as a
  side-effect (set the new output timings).

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dp: For consistency use the DP hotplug synonyms

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/hdmi: Query the live connector status bit for G4x

Similar to g4x_dp_detect() we should probe the PORT_HOTPLUG_STATUS as to
whether the connector is active prior to attempting to retrieve the EDID.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x

Note that gen3 is the only platform where we've got the bit
definitions right, hence the workaround of disabling sdvo hotplug
support on i945g/gm is not due to misdiagnosis of broken hotplug irq
handling ...

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: add some blurb about sdvo hotplug fail on i945g/gm I've
wondered about while reviewing.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4

The status bits corresponding to the interrupt enable bits are the
"live" hotplug status bits, and reflect the current status of the port
(high for a detected connection, low for a disconnect). The actual bits
corresponding to the interrupt source are elsewhere. The actual event is
then determined by a combination of the interrupt flag and the current
live status (if the interrupt is active, but the current status is not,
then we have detected a disconnect.)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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>

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
  ...

drm/i915: IBX has a fixed pch pll to pch pipe mapping

This should fix breakage introduced in

commit ee7b9f93fd96a72e5d09e2b44024c11880873c6b
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>

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>

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>

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

3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit
commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647
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>

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>

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>

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>

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 f47166d2b0001fcb752b40c5a2d4db986dfbea68
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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

drm/cirrus/ast/mgag200: fix build without CONFIG_VGA_CONSOLE

Reported-by: Randy Dunlap
Signed-off-by: Dave Airlie <airlied@redhat.com>

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>

drm/radeon/hdmi: use new AFMT structs

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

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>

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>

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>

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>

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>

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>

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>

gma500: silence an unused variable warning

If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that:
drivers/gpu/drm/gma500/opregion.c:154:6: warning:
unused variable ‘max’ [-Wunused-variable]

Which give me a chance to use the new config_enabled() macro.  :)

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: check kmalloc() for failures

We can just return -ENOMEM here if the allocation fails.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add CRTC properties

The i915 driver needs this for the rotation and overscan compensation
properties. Other drivers might need this too.

Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add 'count' to struct drm_object_properties

This way, we don't need to count every time, so we're a little bit
faster and code is a little bit smaller.

Change suggested by Ville Syrjälä.

Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: make the connector properties code use the object properties code

In the future, we may want to kill the internal functions:
- drm_connector_attach_property
- drm_connector_property_set_value
- drm_connector_property_get_value

It seems the IOCTL drm_mode_connector_property_set_ioctl will have to live, but
we may change libdrm to not use it anymore, if we want.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add generic ioctls to get/set properties on any object

Useless for connector properties (since they already have their own
ioctls), but useful when we add properties to CRTCs, planes and other
objects.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: create struct drm_object_properties and use it

For now, only connectors have it. In the future, all objects that need
properties should use it. Since the structure is referenced inside
struct drm_mode_object, we will be able to deal with object properties
without knowing the real type of the object.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: WARN() when drm_connector_attach_property fails

Also return void instead of int. We have more than 100 callers and
no one checks for the return value.

If this function fails the property won't be exposed by the get/set
ioctls, but we should probably survive. If this starts happening,
the solution will be to increase DRM_CONNECTOR_MAX_PROPERTY and
recompile the Kernel.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add drm_property_change_is_valid

Move code from drm_mode_connector_property_set_ioctl to a new
function, so we can reuse this code when we add crtc properties.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: unload fixes

Debugging the lid problem tested various error paths which were found
wanting so start fixing them up.

There is a ton of improvement work could be done here so that every bit
of functionality agrees if its _fini, _uninit, etc, and they agree who
is responsible for deciding if the clean up is needed.

That can come later.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Fix crash on D2700MUD and various other boards

The recent changes led to the lid timer code being run on various devices.
It does no harm on most but isn't needed. It also calls unconditionally
into the Poulsbo backlight code which goes bang on Cedartrail.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/kms: driver for virtual cirrus under qemu

This is the initial driver for emulated cirrus GPU found in qemu.
This driver only supports the emulated GPU and doesn't attempt
to bind to any real cirrus GPUs.

This driver is intended to be used with xf86-video-modesetting in userspace.
It requires at least version 0.3.0

This follow the same design as ast and mgag200, and is based on work
done by Matthew Garrett previously.

This GPU has no hw cursor, and it can't scanout 32-bpp, only packed 24-bpp.
i.e. it sucks.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

mgag200: initial g200se driver (v2)

This is a driver for the G200 server engines chips,
it doesn't driver any of the Matrix G series desktop cards.

It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards.

Its based on previous work done my Matthew Garrett but remodelled
to follow the same style and flow as the AST server driver. It also
works along the same lines as the AST server driver wrt memory management.

There is no userspace driver planned, xf86-video-modesetting should be used.
It also appears these GPUs have no ARGB hw cursors.

v2: add missing tagfifo reset + G200 SE memory bw setup pieces.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)

This is the initial driver for the Aspeed Technologies chips found in
servers. This driver supports the AST 2000, 2100, 2200, 2150 and 2300. It
doesn't support the AST11xx due to lack of hw to test it on, and them requiring
different codepaths.

This driver is intended to be used with xf86-video-modesetting in userspace.

This driver has a slightly different design than other KMS drivers, but
future server chips will probably share similiar setup. As these GPUs commonly
have low video RAM, it doesn't make sense to put the kms console in VRAM
always. This driver places the kms console into system RAM, and does dirty
updates to a copy in video RAM. When userspace sets a new scanout buffer,
it forcefully evicts the video RAM console, and X can create a framebuffer
that can use all of of video RAM.

This driver uses TTM but in a very simple fashion to control the eviction
to system RAM of the console, and multiple servers.

v2: add s/r support, fix Kconfig.

Signed-off-by: Dave Airlie <airlied@redhat.com>

x86/vga: fix build with efi disabled.

Reported by sfr on -next merge.

Signed-off-by: Dave Airlie <airlied@redhat.com>

x86/vga: set the default device from the fixup.

Since Matthew's efi/vga changes on non-EFI machines we were failing
to tell the vgaarb/switcheroo what the default device was, this
sets the default device in the quirk if none has been set before.

This fixes the switcheroo on my T410s.

Cc: Matthew Garrett <mjg@redhat.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'topic/vga-switcheroo' of git://git./linux/kernel/git/tiwai/sound into drm-core-next

* 'topic/vga-switcheroo' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  vga_switcheroo: Add the support for audio clients
  vga_switcheroo: Introduce struct vga_switcheroo_client_ops
  vga_switcheroo: Refactor using linked list

drm/radeon/hdmi: fix some coding style

Use defined macros by the way.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>