linux-toradex.git/include/drm/drm_edid.h, branch v3.9.7

drm: Add HDMI infoframe helpers

2013-02-22T07:20:10+00:00

Add a generic helper to fill in an HDMI AVI infoframe with data
extracted from a DRM display mode.

Signed-off-by: Thierry Reding 
Reviewed-by: Alex Deucher

drm/edid: Add packed attribute to new gtf2 and cvt structs

2012-04-23T16:41:17+00:00

The new structs added in struct detailed_data_monitor_range must be
marked with packed attribute although the outer struct itself is
already marked as packed.  Otherwise these 7-bytes structs may be
aligned, and give the wrong position and size for the data.

Signed-off-by: Takashi Iwai 
Acked-by: Adam Jackson 
Signed-off-by: Dave Airlie

drm/edid: Update range descriptor struct for EDID 1.4

2012-04-20T11:57:37+00:00

Signed-off-by: Adam Jackson 
Tested-by: Takashi Iwai 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Dave Airlie

drm: allow loading an EDID as firmware to override broken monitor

2012-03-20T10:09:28+00:00

Broken monitors and/or broken graphic boards may send erroneous or no
EDID data. This also applies to broken KVM devices that are unable to
correctly forward the EDID data of the connected monitor but invent
their own fantasy data.

This patch allows to specify an EDID data set to be used instead of
probing the monitor for it. It contains built-in data sets of frequently
used screen resolutions. In addition, a particular EDID data set may be
provided in the /lib/firmware directory and loaded via the firmware
interface. The name is passed to the kernel as module parameter of the
drm_kms_helper module either when loaded
  options drm_kms_helper edid_firmware=edid/1280x1024.bin
or as kernel commandline parameter
  drm_kms_helper.edid_firmware=edid/1280x1024.bin

It is also possible to restrict the usage of a specified EDID data set
to a particular connector. This is done by prepending the name of the
connector to the name of the EDID data set using the syntax
  edid_firmware=[:]
such as, for example,
  edid_firmware=DVI-I-1:edid/1920x1080.bin
in which case no other connector will be affected.

The built-in data sets are
Resolution    Name
--------------------------------
1024x768      edid/1024x768.bin
1280x1024     edid/1280x1024.bin
1680x1050     edid/1680x1050.bin
1920x1080     edid/1920x1080.bin

They are ignored, if a file with the same name is available in the
/lib/firmware directory.

The built-in EDID data sets are based on standard timings that may not
apply to a particular monitor and even crash it. Ideally, EDID data of
the connected monitor should be used. They may be obtained through the
drm/cardX/cardX-/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is even possible to specify the name of an EDID data set on-the-fly
via the /sys/module interface, e.g.
echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
The new screen mode is considered when the related kernel function is
called for the first time after the change. Such calls are made when the
X server is started or when the display settings dialog is opened in an
already running X server.

Signed-off-by: Carsten Emde 
Signed-off-by: Dave Airlie

drm: support routines for HDMI/DP ELD

2011-09-21T21:52:41+00:00

ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor.

This adds drm_edid_to_eld() for converting EDID to ELD. The converted
ELD will be saved in a new drm_connector.eld[128] data field. This is
necessary because the graphics driver will need to fixup some of the
data fields (eg. HDMI/DP connection type, AV sync delay) before writing
to the hardware ELD buffer. drm_av_sync_delay() will help the graphics
drivers dynamically compute the AV sync delay for fixing-up the ELD.

ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be returned by drm_select_eld(). This policy may not be
suitable for all users, but let's start it simple first.

The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor.

According to James, many TVs will either refuse the display anything or
pop-up an OSD warning whenever they receive hdmi audio which they cannot
handle. Eventually we will require configurability and/or per-monitor
audio control even when the video is cloned.

CC: Zhao Yakui 
CC: Wang Zhenyu 
CC: Jeremy Bush 
CC: Christopher White 
CC: Pierre-Louis Bossart 
CC: Paul Menzel 
CC: James Cloos 
CC: Chris Wilson 
Signed-off-by: Ben Skeggs 
Signed-off-by: Wu Fengguang 
Signed-off-by: Keith Packard

drm: parse color format support for digital displays

2011-04-28T04:44:56+00:00

EDID 1.4 digital displays report the color spaces they support in the
features block.  Add support for grabbing this data and stuffing it into
the display_info struct for driver use.

Signed-off-by: Jesse Barnes 
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie

drm: add bit depth parsing

2011-04-28T04:42:58+00:00

EDID 1.4 digital monitors report the bit depth supported in the input
field.  Add support for parsing this out and storing the info in the
display_info structure for use by drivers.

[airlied: tweaked to fix inter-patch dependency]
Signed-off-by: Jesse Barnes 
Reviewed-by: Adam Jackson 
Signed-off-by: Dave Airlie

drm/edid: Add detailed block walk for CEA extensions

2010-08-10T00:46:57+00:00

Signed-off-by: Adam Jackson 
Signed-off-by: Dave Airlie

drm_edid: There should be 6 Standard Timings

2010-05-18T05:56:14+00:00

Smatch complained that we initialize 6 elements in add_detailed_modes()
but the timings[] array is declared with 5 elements.  Adam Jackson
verified that 6 is the correct number of timings.

On Mon, May 10, 2010 at 12:08:24PM -0400, Adam Jackson wrote:
> > >                 struct std_timing timings[5];
> > >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This decl is wrong, should be 6.  From the 1.4 spec:
>
> "Six additional Standard Timings may be listed as a display descriptor
> (tag #FAh)."
>
> The 1.3 spec is a little less explicit about it, but does show 6
> standard timing codes in the 0xFA detailed subblock, terminated by 0x0A
> in the 18th byte.  I don't have the docs for 1.2 or earlier, but we're
> paranoid enough about not adding broken timings that we should be fine.

This patch is basically a clean up, because timings[] is declared inside
a union and increasing the number of elements here doesn't change the
overall size of the union.

Signed-off-by: Dan Carpenter 
Signed-off-by: Dave Airlie

drm/edid: Remove arbitrary EDID extension limit

2010-04-06T00:40:20+00:00

Signed-off-by: Adam Jackson 
Signed-off-by: Dave Airlie