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>

Besides a couple of bugs when writing more than a single byte along the
GMBUS, SDVO was completely failing whilst trying to use GMBUS, so use
bit banging instead.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In the event that the external chipset doesn't implement the
GET_SUPPORTED_ENHANCEMENTS commands, gracefully treat it as having no
enhancments rather than bailing.
Reported-and-tested-by: NWoody Suwalski <terraluna977@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We weren't unlinking the freed connector from the drm lists, and so
hit some use-after-free if we failed to initialise the connector.
Reported-and-tested-by: NWoody Suwalski <terraluna977@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Avoid confusion between i965g meaning broadwater and the gen4+ chipset
families.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC (and for other forms of auxiliary communication with external
display controllers). The hope is that this method will be much faster
and more reliable than bit banging for fetching EDIDs from buggy monitors
or through switches, though we still preserve the bit banging as a
fallback in case GMBUS fails.

Based on an original patch by Jesse Barnes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Later initialisation of the encoder often requires that
drm_encoder_init() has already been called, for instance, initialiasing
the DDC buses.

Yet another recent regression, as 819f3fb7 depended upon these fixes
which I missed when cherry-picking.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>