Create the standard timing modeline by using CVT/GFT algorithm while
interpreting the EDID.

In course of interpreting the EDID, the timing level will be obtained,
which is used to determine whether the CVT/GTF algorithm is selected to
generate the modeline for the given hdisplay/vdisplay/vrefresh_rate.
In the UMS mode firstly it will check whether it can be found in
the DMT table. If it can be found, then the modeline is returned. Then the
timing_level is used to choose CVT/GTF.
As there is no DMT table, no modeline is returned when timing level
is DMT. For the other two timing levels, the CVT/GTF will be called to
generate the required standard timing modeline.

[airlied: fixed up conflicts since EDID rework]
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Looks like I managed to mess up most shifts when converting from bitfields. :(

The patch below works on my Thinkpad T500 (as well as on my PowerBook,
where the previous change worked as well, maybe out of luck...). I'd
appreciate more testing and eyes looking over it though.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Tested-by: NMichael Pyne <mpyne@kde.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Mostly replacing bitfields with explicit masks and shifts.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This code depends on the underlying I2C adapter using the bit-banging algo,
which may not be the case. If specific encoders require this mechanism, they
should build a custom I2C algo that implements this workaround, rather than
having it in the general path.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some EDIDs lie and report tiny modes that aren't possible. Ignore
these modes.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

EDIDs should be backward compatible, so don't bail if we see a version
of 3 (which is out there now) and print a message if we see something
newer, but allow it to be parsed.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Should be,

    edid_vendor[2] = (edid->mfg_id[1] & 0x1f) +  '@';

Since vendor ID has only two bytes only, I am somewhat surprised why gcc
doesn't complain this.
Reported-by: NGuo, Chaohong <chaohong.guo@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Sometime we need to communicate with HDMI monitor by sending audio or video
info frame, so we have to know monitor type. However if user utilize HDMI-DVI adapter to connect DVI monitor, hardware detection will incorrectly show the monitor is HDMI. HDMI spec tell us that any device containing IEEE registration Identifier will be treated as HDMI device.  The patch intends to detect HDMI monitor by this rule.
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Usually drm read basic EDID, that is enough for us, but since igital display
were introduced i.e. HDMI monitor, sometime we need to interact with monitor by
EDID extension information,

EDID extensions include audio/video data block, speaker allocation and vendor specific data blocks.

This patch intends to read EDID extensions from digital monitor for users.
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

edid->revision == 0 should be valid (at least, so the error message
indicates. :) and wikipedia seems to indicate that EDID 1.0 existed.

We can dump the entire check, since edid->revision is a u8, so
it can't ever be less than 0.

Marko reports in RH bz#476735 that his monitor claims to be
EDID 1.0, and therefore hits the check and is stuck at 800x600 because
of it.
Reported-by: NMarko Ristola <marko.ristola@kolumbus.fi>
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Make this message a little quieter, since it's common and not necessarily
indicative of a problem.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

the calling function doesn't call this function unless one of the two
states that sets the value is true.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add mode setting support to the DRM layer.

This is a fairly big chunk of work that allows DRM drivers to provide
full output control and configuration capabilities to userspace.  It was
motivated by several factors:
  - the fb layer's APIs aren't suited for anything but simple
    configurations
  - coordination between the fb layer, DRM layer, and various userspace
    drivers is poor to non-existent (radeonfb excepted)
  - user level mode setting drivers makes displaying panic & oops
    messages more difficult
  - suspend/resume of graphics state is possible in many more
    configurations with kernel level support

This commit just adds the core DRM part of the mode setting APIs.
Driver specific commits using these new structure and APIs will follow.

Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com>
Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>