linux-toradex.git/drivers/gpu, branch v3.0.2

drm/i915: Fixup for 'Hold mode_config->mutex during hotplug'

2011-08-16T01:31:35+00:00

commit 40ee3381dd1010432acc13e907329029096c5bfc upstream.

drm_helper_hpd_irq_event queues another work proc to go and deliver
the user-space event, and that function also wants to hold the config
mutex, so we shouldn't hold the mutex across the
drm_helper_hpd_irq_event call.

Signed-off-by: Keith Packard 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Hold mode_config->mutex during hotplug processing

2011-08-16T01:31:35+00:00

commit a65e34c79c88895766ab1f8a5afa451eed26622b upstream.

Hotplug detection is a mode setting operation and must hold the
struct_mutex or risk colliding with other mode setting operations.

In particular, the display port hotplug function attempts to re-train
the link if the monitor is supposed to be running when plugged back
in. If that happens while mode setting is underway, the link will get
scrambled, leaving it in an inconsistent state.

This is a special case -- usually the driver mode setting entry points
are covered by the upper level DRM code, but in this case the function
is invoked as a work function not under the control of DRM.

Signed-off-by: Keith Packard 
Reviewed-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri

2011-08-16T01:31:35+00:00

commit f3234706a77bd6e1592ae71fb3268e04cb030dba upstream.

Physically-addressed hardware status pages are initialized early in
the driver load process by i915_init_phys_hws. For UMS environments,
the ring structure is not initialized until the X server starts. At
that point, the entire ring structure is re-initialized with all new
values. Any values set in the ring structure (including
ring->status_page.page_addr) will be lost when the ring is
re-initialized.

This patch moves the initialization of the status_page.page_addr value
to intel_render_ring_init_dri.

Signed-off-by: Keith Packard 
Signed-off-by: Greg Kroah-Hartman

drm/i915: load the LUT before pipe enable on ILK+

2011-08-16T01:31:34+00:00

commit 9c54c0dd948d715ccfd79e97d852f80eeb53254a upstream.

Per the specs and to address
https://bugs.freedesktop.org/show_bug.cgi?id=36888.

Signed-off-by: Jesse Barnes 
Signed-off-by: Keith Packard 
Signed-off-by: Greg Kroah-Hartman

drm/i915/pch: Fix integer math bugs in panel fitting

2011-08-16T01:31:34+00:00

commit 302983e9059e9ef5de3ca7671918eeb237c5971e upstream.

Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect.  The
old math would give you:

    scaled_width  = 1600 * 768;         /* 1228800 */
    scaled_height = 1360 * 900;         /* 1224000 */
    if (scaled_width > scaled_height) { /* pillarbox, and true */
        width  = 1224000 / 768;         /* int(1593.75) = 1593 */
        x      = (1600 - 1593 + 1) / 2; /* 4 */
        y      = 0;
        height = 768;
    } /* ... */

This is broken.  The total width of scanout would then be 1593 + 4 + 4,
or 1601, which is wider than the panel itself.  The hardware very
dutifully implements this, and you end up with a black 45° diagonal from
the top-left corner to the bottom edge of the screen.  It's a cool
effect and all, but not what you wanted.  Similar things happen for the
letterbox case.

The problem is that you have an integer number of pixels, which means
it's usually impossible to upscale equally on both axes.  1360/768 is
1.7708, 1600/900 is 1.7777.  Since we're constrained on the one axis,
the other one wants to come out as an even number of pixels (the panel
is almost certainly even on both axes, and the x/y offsets will be
applied on both sides).  In the math above, if 'width' comes out even,
rounding down is correct; if it's odd, you'd rather round up.  So just
increment width/height in those cases.

Tested on a Lenovo T500 (Ironlake).

Signed-off-by: Adam Jackson 
Tested-By: Daniel Manrique 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851
Reviewed-by: Chris Wilson 
Signed-off-by: Keith Packard 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Log Subsystem Vendor and Device Information

2011-08-16T01:31:34+00:00

commit d522d9cc5bdd41214084383fc3e6d882f6916a78 upstream.

    Log PCI subsystem vendor and subsystem device ID in addition to
    PCI vendor and device ID during kernel mode initialisation. This helps
    to better identify radeon devices of third-party vendors, e. g. for
    bug analysis.

    Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board

Signed-off-by: Thomas Reim 
Reviewed-by: Alex Deucher 
Acked-by: Stephen Michaels 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Extended DDC Probing for ECS A740GM-M DVI-D Connector

2011-08-16T01:31:34+00:00

commit a81b31e9fc98e067b7e7f1244861c97e44268e2d upstream.

   ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
   for a DVI connector that is not implemented/existent on the board.

   Fix by applying extented DDC probing for this connector.

   Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
   with Improperly Wired DDC Lines

   Tested for kernel 2.6.38 on Asus ECS A740GM-M board

   BugLink: http://bugs.launchpad.net/bugs/810926

Signed-off-by: Thomas Reim 
Reviewed-by: Alex Deucher 
Acked-by: Stephen Michaels 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines (here: Asus M2A-VM HDMI)

2011-08-16T01:31:34+00:00

commit e384fab8c6f3ca88600bcb2ebdf0eb2f90864fab upstream.

    Some integrated ATI Radeon chipset implementations with add-on HDMI card
    (e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even
    when the add-on card is not plugged in or HDMI is disabled in BIOS setup.
    In this case, drm_get_edid() and drm_edid_block_valid() periodically
    dump data and kernel errors into system log files and onto terminals.
    For these connectors DDC probing is extended by a check for a correct
    EDID header. Only in case a valid EDID header is also found, the
    (HDMI or DVI) connector will be used by the Radeon driver. This prevents
    the kernel driver from useless flooding of logs and terminal sessions with
    EDID dumps and error messages.
    This patch adds a flag 'requires_extended_probe' to the radeon_connector
    structure. In function radeon_connector_needs_extended_probe() this flag
    can be set on a chipset family/vendor/connector type specific basis.
    In addition, function radeon_ddc_probe() has been adapted to perform
    extended DDC probing if required by the connector's flag.
    Requires function drm_edid_header_is_valid() in DRM module provided by
    [PATCH] drm: Separate EDID Header Check from EDID Block Check.

    Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board

    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196
    BugLink: http://bugs.launchpad.net/bugs/7228066

Signed-off-by: Thomas Reim 
Reviewed-by: Alex Deucher 
Acked-by: Stephen Michaels 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm: Separate EDID Header Check from EDID Block Check

2011-08-16T01:31:34+00:00

commit 051963d4832ed61e5ae74f5330b0a94489e101b9 upstream.

    Provides function drm_edid_header_is_valid() for EDID header check
    and replaces EDID header check part of function drm_edid_block_valid()
    by a call of drm_edid_header_is_valid().
    This is a prerequisite to extend DDC probing, e. g. in function
    radeon_ddc_probe() for Radeon devices, by a central EDID header check.

    Tested for kernel 2.6.35, 2.6.38 and 3.0

Signed-off-by: Thomas Reim 
Reviewed-by: Alex Deucher 
Acked-by: Stephen Michaels 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: add missing vddci setting on NI+

2011-08-05T04:58:36+00:00

commit 4639dd21e759e32125adc7171abf6cb8140d54cf upstream.

Need to add vddci setting to pm init as well as
resume.  Fixes hangs on load on some boards.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38754

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman