kernel/drivers/gpu/drm/i915/intel_modes.c, branch linux-4.1.y

drm/i915: Add "Automatic" mode for the "Broadcast RGB" property

2013-01-20T12:09:44Z

Add a new "Automatic" mode to the "Broadcast RGB" range property. When selected the driver automagically selects between full range and limited range output. Based on CEA-861 [1] guidelines, limited range output is selected if the mode is a CEA mode, except 640x480. Otherwise full range output is used. Additionally DVI monitors should most likely default to full range always. As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and otherwise will follow CEA-861 rules. NOTE: The default value for the property will now be "Automatic" so some people may be affected in case they're relying on the current full range default. [1] CEA-861-E - 5.1 Default Encoding Parameters [2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry v2: Use has_hdmi_sink to check if a HDMI monitor is present v3: Add information about relevant spec chapters Reviewed-by: Paulo Zanoni Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter

drm/i915: Remove duplicate inclusion of drm/drm_edid.h

2012-12-10T09:12:29Z

drm/drm_edid.h was included twice. Signed-off-by: Sachin Kamat Reviewed-by: Jani Nikula Signed-off-by: Daniel Vetter

drm/i915: drm_connector_property -> drm_object_property

2012-11-21T21:12:26Z

v2: Rebased. Signed-off-by: Rob Clark Reviewed-by: Jani Nikula (v1) [danvet: Pimp commit message a bit.] Signed-off-by: Daniel Vetter

drm/i915: Do not free the passed EDID in intel_connector_update_modes()

2012-10-22T17:33:46Z

The caller, not intel_connector_update_modes(), should free the edid. This improves the reusability of intel_connector_update_modes(). Signed-off-by: Jani Nikula Reviewed-by: Jesse Barnes Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

2012-10-04T06:29:23Z

Pull drm merge (part 1) from Dave Airlie: "So first of all my tree and uapi stuff has a conflict mess, its my fault as the nouveau stuff didn't hit -next as were trying to rebase regressions out of it before we merged. Highlights: - SH mobile modesetting driver and associated helpers - some DRM core documentation - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write combined pte writing, ilk rc6 support, - nouveau: major driver rework into a hw core driver, makes features like SLI a lot saner to implement, - psb: add eDP/DP support for Cedarview - radeon: 2 layer page tables, async VM pte updates, better PLL selection for > 2 screens, better ACPI interactions The rest is general grab bag of fixes. So why part 1? well I have the exynos pull req which came in a bit late but was waiting for me to do something they shouldn't have and it looks fairly safe, and David Howells has some more header cleanups he'd like me to pull, that seem like a good idea, but I'd like to get this merge out of the way so -next dosen't get blocked." Tons of conflicts mostly due to silly include line changes, but mostly mindless. A few other small semantic conflicts too, noted from Dave's pre-merged branch. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits) drm/nv98/crypt: fix fuc build with latest envyas drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering drm/nv41/vm: fix and enable use of "real" pciegart drm/nv44/vm: fix and enable use of "real" pciegart drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie drm/nouveau: store supported dma mask in vmmgr drm/nvc0/ibus: initial implementation of subdev drm/nouveau/therm: add support for fan-control modes drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules drm/nouveau/therm: calculate the pwm divisor on nv50+ drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster drm/nouveau/therm: move thermal-related functions to the therm subdev drm/nouveau/bios: parse the pwm divisor from the perf table drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices drm/nouveau/therm: rework thermal table parsing drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table drm/nouveau: fix pm initialization order drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it drm/nouveau: log channel debug/error messages from client object rather than drm client drm/nouveau: have drm debugging macros build on top of core macros ...

UAPI: (Scripted) Convert #include "..." to #include in drivers/gpu/

2012-10-02T17:01:07Z

Convert #include "..." to #include in drivers/gpu/. Signed-off-by: David Howells Acked-by: Dave Airlie Acked-by: Arnd Bergmann Acked-by: Thomas Gleixner Acked-by: Paul E. McKenney Acked-by: Dave Jones

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next

2012-08-27T06:22:20Z

There was some merge conflicts in -next and they weren't so pretty, so backmerge now to avoid them. Conflicts: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_modes.c

drm: remove the raw_edid field from struct drm_display_info

2012-08-23T23:37:36Z

Neither the drm core nor any of the drivers really need the raw_edid field of struct drm_display_info for anything. Instead of being useful, it creates confusion about who is responsible for freeing the memory it points to and setting the field to NULL afterwards, leading to memory leaks and dangling pointers. Remove the raw_edid field, and fix drivers as necessary. Reported-by: Russell King Signed-off-by: Jani Nikula Acked-by: Inki Dae Signed-off-by: Dave Airlie

drm/i915: extract connector update from intel_ddc_get_modes() for reuse

2012-08-17T07:21:35Z

Refactor the connector update part of intel_ddc_get_modes() into a separate intel_connector_update_modes() function for reuse. No functional changes. Signed-off-by: Jani Nikula Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881 Tested-by: Alex Ferrando Cc: stable@vger.kernel.org (for 3.4+3.5) Signed-off-by: Daniel Vetter

drm/i915: kill intel_ddc_probe

2012-07-20T10:21:39Z

We have way too much lying hardware to rely on a simple "does someone answer on the ddc i2c address?" check. And now it's unused, so just kill it. Reviewed-by: Chris Wilson Signed-Off-by: Daniel Vetter