summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2015-09-23drm/i915: don't enable FBC when pixel rate exceeds 95% on HSW/BDWPaulo Zanoni
BSpec says we shouldn't enable FBC on HSW/BDW when the pipe pixel rate exceeds 95% of the core display clock. v2: - HSW also needs the WA (Ville). - Add the WA name (Ville). - Use the current cdclk (Ville). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: print the correct amount of bytes allocated for the CFBPaulo Zanoni
And also print the threshold. I was surprised to see a log message claiming the CFB size was 32mb when there was less than 24mb available for it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: avoid the last 8mb of stolen on BDW/SKLPaulo Zanoni
The FBC hardware for these platforms doesn't have access to the bios_reserved range, so it always assumes the maximum (8mb) is used. So avoid this range while allocating. This solves a bunch of FIFO underruns that happen if you end up putting the CFB in that memory range. On my machine, with 32mb of stolen, I need a 2560x1440 mode for that. Testcase: igt/kms_frontbuffer_tracking/fbc-* (given the right setup) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: check for the supported strides on HSW+ FBCPaulo Zanoni
Don't allow FBC for cases where the spec says we can't FBC. v2: - Just WARN_ON() the strides that should have been caught earlier (Daniel) - Make it a new function since I expect this to grow more. v3: - Document which IGT test is exercised by this. v4: - Implement the restrictions for gens 2-6 too (Ville). - Fix off-by-one mistake (Ville). Testcase: igt/kms_frontbuffer_tracking/fbc-badstride Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: fix the FBC work allocation failure pathPaulo Zanoni
Always update the currrent crtc, fb and vertical offset after calling enable_fbc. We were forgetting to do so along the failure paths when enabling fbc synchronously. Fix this with a new helper to enable_fbc() and update the state simultaneously. v2: Improve commit message (Chris). v3: Constify struct drm_framebuffer (Ville). Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Fix fastboot scalers for skylake.Maarten Lankhorst
The scaler_id in intel_pipe_config_compare should not be checked when adjusting in intel_pipe_config_compare. The hw scaler id may be changed in intel_update_pipe_config. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Program GuC MAX IDLE CountSagar Arun Kamble
Cc: Alex Dai <yu.dai@intel.com> Cc: Tom O'Rourke <Tom.O'Rourke@intel.com> Cc: Akash Goel <akash.goel@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: WaRsDoubleRc6WrlWithCoarsePowerGatingSagar Arun Kamble
Cc: Tom O'Rourke <Tom.O'Rourke@intel.com> Cc: Akash Goel <akash.goel@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> [danvet: Fix continuation alignment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: WaRsUseTimeoutModeSagar Arun Kamble
Enable TO mode for RC6 for SKL till D0 and BXT till A0. Cc: Tom O'Rourke <Tom.O'Rourke@intel.com> Cc: Akash Goel <akash.goel@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> [danvet: Fixup line continuation alignment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Add primary plane to mask if it's visibleMaarten Lankhorst
This fixes the warnings like "plane A assertion failure, should be disabled but not" that on the initial modeset during boot. This can happen if the primary plane is enabled by the firmware, but inheriting it fails because the DMAR is active or for other reasons. Most likely caused by commit 36750f284b3a4f19b304fda1bb7d6e9e1275ea8d Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Mon Jun 1 12:49:54 2015 +0200 drm/i915: update plane state during init Reported-by: Andreas Reis <andreas.reis@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429 Reported-and-tested-by: Emil Renner Berthing <kernel@esmil.dk> Tested-by: Andreas Reis <andreas.reis@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-23drm/i915: WaRsDisableCoarsePowerGatingSagar Arun Kamble
WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0. v2: Added GT3/GT4 Check. Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> [danvet: Align continuation properly.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Add IS_SKL_GT3 and IS_SKL_GT4 macro.Sagar Arun Kamble
It will be usefull to specify w/a that affects only SKL GT3 and GT4. Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: fix crash in error state readout on non-execlist platforms v2Jesse Barnes
Looks like this was introduced in: commit d1675198ed1f21aec6e036336e4340c40b726497 Author: Alex Dai <yu.dai@intel.com> Date: Wed Aug 12 15:43:43 2015 +0100 drm/i915: Integrate GuC-based command submission This patch assumed LRC contexts and HWS layout, which is incorrect on platforms without execlists. This can lead to a crash in GPU error state readout on those platforms. I don't see a bug filed for this, but there may be one that I haven't found. v2: fixup offset handling for error capture fix (Dave) Cc: Alex Dai <yu.dai@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Move scanline_offset and timestamping constant setup to ↵Ville Syrjälä
intel_modeset_readout_hw_state() intel_modeset_readout_hw_state() seems like the more appropriate place for populating the scanline_offset and timestamping constants than intel_sanitize_crtc() since they are basically part of the state we read out. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()Ville Syrjälä
Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc() where it belongs instead of doing it in intel_modeset_readout_hw_state(). The plane disabling was first added in 4cf0ebbd4fafbdf8e6431dbb315e5511c3efdc3b drm/i915: Rework plane readout. I got the idea from some patches from Partik and/or Maarten but those moved also the plane state readout to intel_sanitize_crtc() which isn't quite right in my opinion. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=91910 Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Assign hwmode after encoder state readoutVille Syrjälä
The dotclock is often calculated in encoder .get_config(), so we shouldn't copy the adjusted_mode to hwmode until we have read out the dotclock. Gets rid of some warnings like these: [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! [drm:i915_get_vblank_timestamp] crtc 0 is disabled v2: Steal Maarten's idea to move crtc->mode etc. assignment too Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428 Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Check live status before reading edidSonika Jindal
The Bspec is very clear that Live status must be checked about before trying to read EDID over DDC channel. This patch makes sure that HDMI EDID is read only when live status is up. The live status doesn't seem to perform very consistent across various platforms when tested with different monitors. The reason behind that is some monitors are late to provide right voltage to set live_status up. So, after getting the interrupt, for a small duration, live status reg fluctuates, and then settles down showing the correct staus. This is explained here in, in a rough way: HPD line ________________ |\ T1 = Monitor Hotplug causing IRQ | \______________________________________ | | | | | | T2 = Live status is stable | | _____________________________________ | | /| Live status _____________|_|/ | | | | | | | | | | T0 T1 T2 (Between T1 and T2 Live status fluctuates or can be even low, depending on the monitor) After several experiments, we have concluded that a max delay of 30ms is enough to allow the live status to settle down with most of the monitors. This total delay of 30ms has been split into a resolution of 3 retries of 10ms each, for the better cases. This delay is kept at 30ms, keeping in consideration that, HDCP compliance expect the HPD handler to respond a plug out in 100ms, by disabling port. v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions to check digital port status. Adding a separate function to get bxt live status (Daniel) v3: Using intel_encoder->hpd_pin to check the live status (Siva) Moving the live status read to intel_hdmi_probe and passing parameter to read/not to read the edid. (me) v4: * Added live status check for all platforms using intel_digital_port_connected. * Rebased on top of Jani's DP cleanup series * Some monitors take time in setting the live status. So retry for few times if this is a connect HPD v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob which was missed. v6: Drop the (!detect_edid && !live_status check) check because for DDI ports which are enumerated as hdmi as well as DP, we don't have a mechanism to differentiate between DP and hdmi inside the encoder's hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well as hdmi which leads to issues during unplug because of the above check. v7: Make intel_digital_port_connected global in this patch, some reformatting of while loop, adding a print when live status is not up. (Rodrigo) v8: Rebase it on nightly which involved skipping the hot_plug hook for now and letting the live_status check happen in detect until the hpd handling part is finalized (Daniel) Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915/bxt: DSI prepare changes for BXTShashank Sharma
This patch modifies dsi_prepare() function to support the same modeset prepare sequence for BXT also. Main changes are: 1. BXT port control register is different than VLV. 2. BXT modeset sequence needs vdisplay and hdisplay programmed for transcoder. 3. BXT can select PIPE for MIPI transcoders. 4. BXT needs to program register MIPI_INIT_COUNT for both the ports, even if only one is being used. v2: Fixed Jani's review comments. Rectified the DSI Macros to get proper register offsets using _MIPI_PORT instead of _TRANSCODER v3: Rebased on latest drm-nightly branch. Fixed Jani's review comments. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915/bxt: Disable DSI PLL for BXTShashank Sharma
This patch adds two new functions: - disable_dsi_pll. BXT DSI disable sequence and registers are different from previous platforms. - intel_disable_dsi_pll wrapper function to re-use the same code for multiple platforms. It checks platform type and calls appropriate core pll disable function. v2: Fixed Jani's review comments. v3: Rebased on latest drm-nightly branch. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915/bxt: Enable BXT DSI PLLShashank Sharma
This patch adds new functions for BXT clock and PLL programming. They are: 1. configure_dsi_pll for BXT. This function does the basic math and generates the divider ratio based on requested pixclock, and program clock registers. 2. enable_dsi_pll function. This function programs the calculated clock values on the PLL. 3. intel_enable_dsi_pll Wrapper function to use same code for multiple platforms. It checks the platform and calls appropriate core pll enable function. v2: Fixed Jani's review comments. Macros are adjusted as per convention. v3: Removed a redundant change wrt code comment. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: Increase maximum polling time to 50ms for forcewake request/clear ackSagar Arun Kamble
On BXT, We Observe timeout for forcewake request completion with 2ms polling period as given here: [drm:fw_domains_get] ERROR render: timed out waiting for forcewake ack request. Polling for 50ms is recommended to avoid these timeouts. Change-Id: Ie715b0069a3049606e9602bc5e97a6511890864d Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed by: Alex Dai <yu.dai@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915/bxt: WaGsvDisableTurboSagar Arun Kamble
Disable Turbo on steppings prior to B0 on BXT due to hangs seen during GT CPD exit. Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed by: Alex Dai <yu.dai@intel.com>. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915/bxt: Modified HAS_CSR, added support for BXTAnimesh Manna
Modified HAS_CSR macro defination which earlier only supported for skl, now added support for BXT. v1: Initial version. v2: Instaed of skylake/broxton check added gen9 check alone based on review comment from Sunil. Cc: Vetter, Daniel <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915/bxt: Stepping info added for bxt.Animesh Manna
Added stepping info in intel_csr.c which is required to extract specific firmware from packaged dmc firmware. Stepping info is aligned with current bspec info. Cc: Vetter, Daniel <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915/bxt: Path added of dmc firmware ver1 for BXT.Animesh Manna
Broxton also has dmc to manage low-power display engine state. Path of the firmware added in intel_csr.c. Naming convention followed as <platform>_dmc_<api-version>.bin v1: Initial version. v2: Commit description added based on review comment from Sunil. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-23drm/i915: workaround bad DSL readout v3Jesse Barnes
On HSW at least (still testing other platforms, but should be harmless elsewhere), the DSL reg reads back as 0 when read around vblank start time. This ends up confusing the atomic start/end checking code, since it causes the update to appear as if it crossed a frame count boundary. Avoid the problem by making sure we don't return scanline_offset from the get_crtc_scanline function. In moving the code there, I add to add an additional delay since it could be called and have a legitimate 0 result for some time (depending on the pixel clock). v2: move hsw dsl read hack to get_crtc_scanline (Ville) v3: use break instead of goto (Ville) update comment with workaround details (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=91579 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-22drm/i915/skl: Don't clear all watermarks when updating. (v2)Bob Paauwe
Clearing the watermarks for all pipes/planes when updating the watermarks for a single CRTC change seems like the wrong thing to do here. As is, this code will ony update any pipe/plane watermarks that need updating and leave the remaining set to zero. Later, the watermark checks in check_wm_state() will flag these zero'd out pipe/plane watermarks and throw errors. By clearing only the watermark values associated with the specific crtc the other watermark values may remain unchanged. v2: Make sure all the dirty flags are cleared. Damien Clear all values assoicated with crtc/pipe being updated. Damien Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-22drm/i915: Mark debug mod options as _unsafeDaniel Vetter
We don't want random people to touch these. Especially true since we've just screwed up SKL by holding it way too long under the preliminary flag because of some ABI issues. And now there's howtos all over the internets about how to set this. Same pretty much for anything else. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: drop fastboot changes, that option is gone.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-22drm/i915: fix handling gen8_emit_flush_coherentl3_wa resultAndrzej Hajda
The function can return negative value. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-22drm/i915: Spell vga_switcheroo consistentlyLukas Wunner
Currently everyone and their dog has their own favourite spelling for vga_switcheroo. This makes it hard to grep dmesg for log entries relating to vga_switcheroo. It also makes it hard to find related source files in the tree. vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-21drm/i915/skl: handle port E in cpt_digital_port_connectedJani Nikula
SKL port E handling was added in commit 26951caf55d73ceb1967b0bf12f6d0b96853508e Author: Xiong Zhang <xiong.y.zhang@intel.com> Date: Mon Aug 17 15:55:50 2015 +0800 drm/i915/skl: enable DDI-E hotplug but the whole function was moved in a another branch in commit b93433ccf64846820b9448f5ff5dd4348b58a8ed Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Aug 20 10:47:36 2015 +0300 drm/i915: move ibx_digital_port_connected to intel_dp.c and the addition was lost at some backmerge that I was unable to identify. Put it back in. Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-21drm/i915: fix kernel-doc warnings in intel_audio.cGeliang Tang
Fix the following 'make htmldocs' warnings: .//drivers/gpu/drm/i915/intel_audio.c:439: warning: No description found for parameter 'intel_encoder' .//drivers/gpu/drm/i915/intel_audio.c:439: warning: Excess function parameter 'encoder' description in 'intel_audio_codec_disable' .//drivers/gpu/drm/i915/intel_audio.c:439: warning: No description found for parameter 'intel_encoder' .//drivers/gpu/drm/i915/intel_audio.c:439: warning: Excess function parameter 'encoder' description in 'intel_audio_codec_disable' Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-18drm/i915/bxt: Fix wrongly placed ')' in I915_READ()Damien Lespiau
Not the first time! not the last time? There is a possibility to use gcc 5's -Wbool-compare to try and compare (reg) in those macros to a constant and gcc will warn that the comparison between a boolean expression and a constant is always either true or false. Maybe. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-18drm/i915: Don't leak VBT mode dataMatt Roper
We allocate memory for LVDS modes while parsing the VBT at startup, but never free this memory when the driver is unloaded, causing a small leak. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-18drm/i915: cleanup pipe_update trace functions with new crtc debug info v3Jesse Barnes
Use the new debug info in the intel_crtc struct in these functions rather than passing them as args. v2: move min/max assignment back above first trace call (Ville) use scanline from crtc->debug rather than fetching a new one (Ville) v3: fix up trace_i915_pipe_update_end, needs end scanline (Ville) Requested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-17drm/vmwgfx: Only build on X86Thomas Hellstrom
ioremap_cache() is currently not available on some architectures. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2015-09-17drm/i915: add more debug info for when atomic updates fail v3Jesse Barnes
I used these additional fields to track down the issue I saw on HSW. v2: move debug fields into a substruct (Ville) v3: clean up debug code more (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=91579 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-17drm/i915: fix kernel-doc warnings in i915_gem.cGeliang Tang
Fix the following 'make htmldocs' warnings: .//drivers/gpu/drm/i915/i915_gem.c:1729: warning: No description found for parameter 'vma' .//drivers/gpu/drm/i915/i915_gem.c:1729: warning: No description found for parameter 'vmf' .//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'old' .//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'new' .//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'frontbuffer_bits' Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-16drm/i915: enable atomic fb-helperRob Clark
i915 supports enough atomic to have atomic fb-helper paths, even though it does not yet advertise DRIVER_ATOMIC. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-16drm/fb-helper: atomic pan_display()..Rob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-16drm/fb-helper: atomic restore_fbdev_mode()..Rob Clark
Add support for using atomic code-paths for restore_fbdev_mode(). Signed-off-by: Rob Clark <robdclark@gmail.com> [danvet: Bikeshed comments slightly.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-16gpu/drm: Kill off set_irq_flags usageRob Herring
set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID -> !IRQ_NOREQUEST IRQF_PROBE -> !IRQ_NOPROBE IRQF_NOAUTOEN -> IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also modify IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. Signed-off-by: Rob Herring <robh@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: Russell King <linux@arm.linux.org.uk> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-09-15drm/armada: factor out retirement of old fbRussell King
We have two identical places in the overlay code which retire the drm framebuffer. Factor these out into a common function. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-15drm/armada: rename overlay identifiersRussell King
Include an _ovl infix into the overlay identifiers to separate them from the primary plane. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-15drm/armada: redo locking and atomics for armada_drm_crtc_complete_frame_work()Russell King
We can do better with armada_drm_crtc_complete_frame_work() - we can avoid taking the event lock unless a call to drm_send_vblank_event() is required, and using cmpxchg() and xchg(), we can eliminate the locking around dcrtc->frame_work entirely. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-15drm/armada: disable CRTC clock during DPMSRussell King
When the CRTC is in low power mode, it isn't running, and so there's no point keeping the CRTC clock enabled. Disable the CRTC clock during DPMS. We need to re-enable it in the mode_set callback to ensure that the variant's compute_clock() continues to see its clock in the expected state (enabled). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-15drm/armada: use drm_plane_force_disable() to disable the overlay planeRussell King
Use drm_plane_force_disable() to disable the overlay plane on a mode_set rather than coding this ourselves. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-15drm/armada: move vbl code into armada_crtcRussell King
Our vblank event code belongs in armada_crtc.c rather than the core of the driver. Move it there. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-15drm/armada: remove non-component supportRussell King
Now that the transition of TDA998x to the component helpers is complete, remove the non-componentised support from the Armada DRM driver. All outputs are expected to use the component helpers from now on. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-15drm/i2c: tda998x: use more HDMI helpersRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>