Our handling of the crtc timing computation has been nicely
cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over
the place. But with

commit f9bef081
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Apr 15 19:53:19 2012 +0200

    drm/i915: don't clobber the special upscaling lvds timings

and

commit ca9bfa7e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jan 28 14:49:20 2012 +0100

    drm/i915: fixup interlaced vertical timings confusion, part 1

we now only set the crtc timing fields in the encoder->mode_fixup
(lvds only) and in crtc->mode_fixup (for everyone else). And since

commit 75c13993
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jan 28 23:48:46 2012 +0100

    drm/i915: fixup overlay checks for interlaced modes

the only places we actually need the crtc timings is in the mode_set
function.

I guess the idea of the drm core is that every time it creates a drm
mode, it also sets the timings. But afaics it never uses them, safe
for the precise vblank timestamp code (but that can only run on active
modes, i.e.  after our mode_fixup functions have been called). The
problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the
timings are pretty much bogus for us anyway (at least with interlaced
support).

So I guess it's the drivers job that every active modes needs to have
crtc timings that suits it, and with these patches we should have
that. drm core doesn't seem to care about modes that just get passed
around. Hence we can now safely rip out all the remaining calls to
set_crtcinfo left in the driver and clean up this confusion.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Sparse doesn't like:
"error: bad constant expression"
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
[danvet: apply s/drm_malloc_ab/kcalloc bikeshed. If it's small enough
for the stack, it's small enough for kmalloc.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should contain all the changes which require no thought to make
sparse happy.
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reported-and-tested-by: Bo Wang < bo.b.wang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

With valleyview we'll have these at yet another address, so keeping
track of this with an ever-growing list of registers will get ugly.

This way intel_sdvo.c is fully independent of the base address of the
output ports display register blocks.

While at it, do 2 closely related cleanups:
- use SDVO_NAME some more
- change the sdvo_reg variables to uint32_t like other registers.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While fixing up a merge conflict with drm-next I've noticed that we
use the same audio drm connector property also for dp and sdvo
outputs.

So put the new enum to some good use and convert these paths, too. The
HDMI_AUDIO_ prefix is a bit a misnomer. But at least for sdvo it makes
sense (and you can also connect a hdmi monitor with a dp->hdmi cable),
so I've decided to stick with it.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NPeter Ross <pross@xvid.org>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NChristopher Egert <cme3000@gmail.com>
Tested-by: NAlfonso Fiore <alfonso.fiore@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have a pretty decent confusion about vertical timings of interlaced
modes. Peter Ross has written a patch that makes interlace modes work
on a lot more platforms/output combinations by doubling the vertical
timings.

The issue with that patch is that core drm _does_ support specifying
whether we want these vertical timings in fields or frames, we just
haven't managed to consistently use this facility. The relavant
function is drm_mode_set_crtcinfo, which fills in the crtc timing
information.

The first thing to note is that the drm core keeps interlaced modes in
frames, but displays modelines in fields. So when the crtc modeset
helper copies over the mode into adjusted_mode it will already contain
vertical timings in half-frames. The result is that the fixup code in
intel_crtc_mode_fixup doesn't actually do anything (in most cases at
least).

Now gen3+ natively supports interlaced modes and wants the vertical
timings in frames. Which is what sdvo already fixes up, at least under
some conditions.

There are a few other place that demand vertical timings in fields
but never actually deal with interlaced modes, so use frame timings
for consistency, too. These are:
- lvds panel,
- dvo encoders - dvo is the only way gen2 could support interlaced
  mode, but currently we don't support any encoders that do.
- tv out - despite that the tv dac sends out an interlaced signal it
  expects a progressive mode pipe configuration.
All these encoders enforce progressive modes by resetting
interlace_allowed.

Hence we always want crtc vertical timings in frames. Enforce this in
our crtc mode_fixup function and rip out any redudant timing
computations from the encoders' mode_fixup function.

v2-4: Adjust the vertical timings a bit.

v5: Split out the 'subtract-one for interlaced' fixes.

v6: Clarify issues around tv-out and gen2.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NChristopher Egert <cme3000@gmail.com>
Tested-by: NAlfonso Fiore <alfonso.fiore@gmail.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Creating a range property is a common pattern, so create
a convenience function for this and use it where appropriate.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is a revert of 81a14b46.

We already set the mode polarity using the SDVO commands with struct
intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch.
The documentation, despite not clear, can also be interpreted in a way
that suggests this patch is needed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43333
Cc: stable@kernel.org
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

We were checking whether the supplied edid matched the connector it was
read from. We do this in case a DDC read returns an EDID for another
device on a multifunction or otherwise interesting card. However, we
failed to include LVDS as a digital device and so rejecting an otherwise
valid EDID.

Fixes the detection of the secondary SDVO LVDS panel on the Libretto
W105.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39216Signed-off-by: NKeith Packard <keithp@keithp.com>

v2: add a CPT-specific macro, make code cleaner
v3: fix commit message

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41272
Cc: stable@kernel.org
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Well almost anyway.  IVB has 3 planes, pipes, transcoders, and FDI
interfaces, but only 2 pipe PLLs.  So two of the pipes must use the same
pipe timings (e.g. 2 DP plus one other, or two HDMI with the same mode
and one other, etc.).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-By: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-By: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This is general TMDS detect, not HDMI specifically.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

I can't think of any sensible reason to limit this to a mask of 0x0f,
ie, SDVO_OUTPUT_{TMDS,RGB,CVBS,SVID}0.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

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

I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.

As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.

Note that this is only tested on single-function DVI-D SDVOs, on two
platforms (965GME and 945GSE), and has not been checked against a
specification document.

With lots of help from Adam Jackson <ajax@redhat.com> on IRC.
Signed-off-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

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: NAkshay Joshi <me@akshayjoshi.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Make the audio property creation routine common and share the single
property between the connectors.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The ddc proxy depends upon the underlying i2c bus being selected. Under
certain configurations, the i2c-adapter functionality is queried during
initialisation and so may trigger an OOPS during boot. Hence, we need to
reorder the initialisation of the ddc proxy until after we hook up the i2c
adapter for the SDVO device.

The condition under which it fails is when the i2c_add_adapter calls
into i2c_detect which will attempt to probe all valid addresses on the
adapter iff there is a pre-existing i2c_driver with the same class as
the freshly added i2c_adapter.

So it appears to depend upon having compiled in (or loaded such a
module before i915.ko) an i2c-driver that likes to futz over the
i2c_adapters claiming DDC support.
Reported-by: NMihai Moldovan <ionic@ionic.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

... and fixup some methods to accept the constant argument.

Now that constant module arrays are loaded into read-only memory, using
const appropriately has some benefits beyond warning the programmer
about likely mistakes.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In order to prevent "crushed blacks" on TVs, the range of the RGB output
may be limited to 16-235. This used to be available through Xorg under
the "Broadcast RGB" option, so reintroduce support for KMS.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34543Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If the user changes the force-audio property and it no longer reflects
the current configuration, then we need to trigger a mode set in order
to update the registers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If we have an EDID for a digital panel, but we are probing a non-TMDS
connector then we know that this is a false detection, and vice versa.
This should reduce the number of bogus outputs on multi-function
adapters that report the same output on multiple connectors.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34101Reported-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We were not pausing after detecting the response was pending and so did
not allow the hardware sufficient time to complete before aborting. This
lead to transient failures whilst probing SDVO devices.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30235Reported-by: NKnut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Alex Fiestas reported an issue with his HDMI connector being misdetected
as DVI unless he had something connected upon boot. By moving the
decision as to whether to use HDMI or DVI encoding for the HDMI capable
output until we probe the monitor means that we should avoid sending a
HDMI signal to a DVI monitor and also correctly detect hardware like
Alex's.

However, to really determine what connector is soldered onto the wire we
need to inspect the VBT sdvo child devices - but can we trust it?
Reported-by: NAlex Fiestas <alex@eyeos.org>
Tested-by: NAlex Fiestas <alex@eyeos.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25012Reported-by: NTõnu Raitviir <jussuf@linux.ee>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is even more important as those bits will be moved in future.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

BIOSes. Can't live without them (apparently), definitely can't live with
them.
Reported-by: NBen Gamari <bgamari@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24312Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Commit d09c23de intended to add a 30ms delay to give the ADD time to
detect any TVs connected. However, it used the sdvo->is_tv flag to do so
which is dependent upon the previous detection result and not whether the
output supports TVs.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

On a few devices, like the Mac Mini, the CRT DDC pins are shared between
the analog connector and the digital connector. In this scenario, rely
on the EDID to determine if a digital panel is connected to the digital
connector.
Reported-and-tested-by: NTino Keitel <tino.keitel@tikei.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we conflated intel_sdvo->is_hdmi with both having HDMI support on the
ADD along with having HDMI support on the monitor, we would attempt to
use HDMI encodings even if the interface did not support those commands.
Reported-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>

This block is only used when detecting whether the connector is HDMI and
never again, so scope the variable to the detection routine.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This patch enables the sending of AVI infoframes in
drivers/gpu/drm/i915/intel_hdmi.c.

My receiver currently loses sync when the HDMI output on my computer
(DG45FC motherboard) is switched from 800x600 (the BIOS resolution) to
1920x1080 as part of the boot. Fixable by switching inputs on the receiver
a couple of times.

With this patch, my receiver has not lost sync yet (> 40 tries).

Fourth version, now based on drm-intel-next from:
git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git

Two questions still remain:

I'm assuming that the sdvo hardware also stores a header ECC byte in
the MSB of the first dword - is this correct?

Does the SDVOB and SDVOC handling in intel_hdmi_set_avi_infoframe()
look correct?
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>