Intel OpenBMC Linux kernel source tree (mirror) https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.7 2016-05-27T06:08:38+00:00 2016-05-27T06:08:38+00:00 Dave Airlie airlied@redhat.com 2016-05-27T06:08:38+00:00 urn:sha1:7fa1d27b638db86516d7b3d8dc1a3576c72ee423 I see the main drm pull got merged, here's the first batch of fixes for 4.7 already. Fixes all around, a large portion cc: stable stuff. [airlied: the DP++ stuff is a regression fix]. * tag 'drm-intel-next-fixes-2016-05-25' of git://anongit.freedesktop.org/drm-intel: drm/i915: Stop automatically retiring requests after a GPU hang drm/i915: Unify intel_ring_begin() drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2) drm/i915/psr: Try to program link training times correctly drm/i915/bxt: Adjusting the error in horizontal timings retrieval drm/i915: Don't leave old junk in ilk active watermarks on readout drm/i915: s/DPPL/DPLL/ for SKL DPLLs drm/i915: Fix gen8 semaphores id for legacy mode drm/i915: Set crtc_state->lane_count for HDMI drm/i915/BXT: Retrieving the horizontal timing for DSI drm/i915: Protect gen7 irq_seqno_barrier with uncore lock drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed drm/i915: Respect DP++ adaptor TMDS clock limit drm: Add helper for DP++ adaptors 2016-05-23T08:10:46+00:00 Ville Syrjälä ville.syrjala@linux.intel.com 2016-05-06T13:46:52+00:00 urn:sha1:b3daa5ef52c26acd7432c787989bd92d48070c76 Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes v4: Adjust code indentation of type2 adaptor detection (Shashank) Add debug messages for failurs cases (Shashank) v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit ede53344dbfd1dd43bfd73eb6af743d37c56a7c3) Signed-off-by: Jani Nikula <jani.nikula@intel.com> 2016-05-11T16:48:10+00:00 Noralf Trønnes noralf@tronnes.org 2016-05-11T16:09:18+00:00 urn:sha1:02da16d0fbe2cde3d7befb8a907c167c4a79a681 Hook up fb_cma_helper to DocBook. Remove mention of CONFIG_FB_DEFERRED_IO in the docs, which was forgotten in the latest version of the deferred_io patch. Use & when referencing drm_mode_config_funcs in docs. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462982962-10530-3-git-send-email-noralf@tronnes.org 2016-05-06T14:04:48+00:00 Thierry Reding thierry.reding@gmail.com 2016-05-06T14:01:37+00:00 urn:sha1:83127f67e450a9a0882da495d59c88a71da25389 Write more complete kerneldoc comments for the DRM panel API and integrate the helpers in the DRM DocBook reference. Signed-off-by: Thierry Reding <treding@nvidia.com>drm/panel: Add helper for simple panel connector Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160506140137.GA4641@ulmo.ba.sec 2016-05-02T21:51:22+00:00 Robert Foss robert.foss@collabora.com 2016-05-02T19:13:01+00:00 urn:sha1:fcbcb3b0cf9f73742426877ff56d63f12fd92c12 The "scaling mode" property has been moved to the DRM->Generic. It has also had a list of supported drivers added to it. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462216381-10160-1-git-send-email-robert.foss@collabora.com 2016-03-21T18:40:31+00:00 Lionel Landwerlin lionel.g.landwerlin@intel.com 2016-03-16T10:57:16+00:00 urn:sha1:82cf435b3134a5f892971b721b34e4c5d249363d Patch based on a previous series by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add documentation on how the Broadcast RGB property is affected by CTM v4: Update contributors v5: Refactor degamma/gamma LUTs load into a single function v6: Fix missing intel_crtc variable (bisect issue) v7: Fix & simplify limited range matrix multiplication (Matt Roper's comment) Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Kumar, Kiran S <kiran.s.kumar@intel.com> Signed-off-by: Kausal Malladi <kausalmalladi@gmail.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acknowledged-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458125837-2576-4-git-send-email-lionel.g.landwerlin@intel.com 2016-03-17T09:58:57+00:00 Jani Nikula jani.nikula@intel.com 2016-03-16T10:43:35+00:00 urn:sha1:72341af4285ae1337c0dfdfa3e68318b52b8757c We've been accumulating code across the driver that depends on the VBT specific structures and defines. The VBT is an uncontrollable beast. Encourage encapsulation of the VBT data by hiding the structures and defines in a private header only to be included from intel_bios.c. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458125015-7931-7-git-send-email-jani.nikula@intel.com 2016-03-08T12:57:32+00:00 Lionel Landwerlin lionel.g.landwerlin@intel.com 2016-02-26T17:05:00+00:00 urn:sha1:5488dc16fde74595a40c5d20ae52d978313f0b4e Patch based on a previous series by Shashank Sharma. This introduces optional properties to enable color correction at the pipe level. It relies on 3 transformations applied to every pixels displayed. First a lookup into a degamma table, then a multiplication of the rgb components by a 3x3 matrix and finally another lookup into a gamma table. The following properties can be added to a pipe : - DEGAMMA_LUT : blob containing degamma LUT - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT - CTM : transformation matrix applied after the degamma LUT - GAMMA_LUT : blob containing gamma LUT - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by the driver to tell userspace applications what sizes should be the lookup tables in DEGAMMA_LUT and GAMMA_LUT. A helper is also provided so legacy gamma correction is redirected through these new properties. v2: Register LUT size properties as range v3: Fix round in drm_color_lut_get_value() helper More docs on how degamma/gamma properties are used v4: Update contributors v5: Rename CTM_MATRIX property to CTM (Doh!) Add legacy gamma_set atomic helper Describe CTM/LUT acronyms in the kernel doc v6: Fix missing blob unref in drm_atomic_helper_crtc_reset Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Kumar, Kiran S <kiran.s.kumar@intel.com> Signed-off-by: Kausal Malladi <kausalmalladi@gmail.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Rob Bradford <robert.bradford@intel.com> [danvet: CrOS maintainers are also happy with the userspacde side: https://codereview.chromium.org/1182063002/ ] Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1456506302-640-4-git-send-email-lionel.g.landwerlin@intel.com 2016-02-09T10:21:11+00:00 Lukas Wunner lukas@wunner.de 2016-01-11T19:09:20+00:00 urn:sha1:2413306c2566b729a9d17a81e9d1181e6f354d6a Centralize gmux' ACPI HID in a header file and add apple_gmux_present(). This can be used by other drivers to activate quirks specific to dual GPU MacBook Pros & Mac Pros. The alternative would be to hardcode DMI or PCI IDs and amend them whenever Apple introduces a new machine. Tested-by: Lukas Wunner <lukas@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/89c23769058a340e5e11d4a7102f3793d3b0c94c.1452525860.git.lukas@wunner.de 2016-02-09T10:21:07+00:00 Lukas Wunner lukas@wunner.de 2016-01-11T19:09:20+00:00 urn:sha1:156d7d4120e1c860fde667fc30eeae84bc3e7a25 Allow handlers to declare their capabilities and allow clients to obtain that information. So far we have these use cases: * If the handler is able to switch DDC separately, clients need to probe EDID with drm_get_edid_switcheroo(). We should allow them to detect a capable handler to ensure this function only gets called when needed. * Likewise if the handler is unable to switch AUX separately, the active client needs to communicate link training parameters to the inactive client, which may then skip the AUX handshake and set up its output with these pre-calibrated values (DisplayPort specification v1.1a, section 2.5.3.3). Clients need a way to recognize such a situation. The flags for the radeon_atpx_handler and amdgpu_atpx_handler are initially set to 0, this can later on be amended with handler_flags |= VGA_SWITCHEROO_CAN_SWITCH_DDC; when a ->switch_ddc callback is added. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115 Tested-by: Lukas Wunner <lukas@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/2b0d93ed6e511ca09e95e45e0b35627f330fabce.1452525860.git.lukas@wunner.de