- 23 Sep, 2015 40 commits
-
-
Tvrtko Ursulin authored
By providing a start offset into the source array of pages, and returning the end position in the scatter-gather table, we will be able to append the UV plane to the rotated mapping in later patches. v2: Rebase. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Tvrtko Ursulin authored
This will be needed for NV12 support. v2: Rebase. Signed-off-by:
-
Arun Siluvery authored
Cc: Nick Hoath <nicholas.hoath@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ville Syrjälä authored
FIXME: Should there be a WARN(i != 9) or something, or what does the entry 9 comment mean? Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
intel_sdvo_select_ddc_bus() and intel_sdvo_select_i2c_bus() have no used for the passed in 'reg', so just drop it. Signed-off-by:
-
Ville Syrjälä authored
Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT and DEVICE_TYPE_DIGITAL_OUTPUT when trying to determine the presence of eDP based on the VBT child device type. Apparently a significant portion of VLV systems have these bits set incorrectly, and so we currently fail to detect eDP on said systems. This is based on an earlier patch [1] from Andreas Lampersperger. Instead of ignoring the bits just on VLV as was done in the orignal patch, we now ignore them for all platforms. We should still have enough bits in there to avoid false positives (unless the VBT is totally bonkers). Quoting the orignal patch: > When the i915.ko identify an eDP output on a valleyview > board, it should be more slackly. The reason for that is, > that BIOS DATA TABLES generated with intel BMP (Binary > Modification Program) do not set bits for NOT_HDMI or > DIGITAL_OUTPUT on the device type. Due to Adolfo > Sanchez from Intel EMGD, this is not possible. > To solve this problem and enable i915.ko on embedded > vlv boards with eDP, we ignore this two bits. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/069416.html Cc: Andreas Lampersperger <lampersperger.andreas@heidenhain.de> Cc: "Sanchez, AdolfoX" <adolfox.sanchez@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We don't support eDP on g4x, so let's not even look at the VBT to determine the port type, just in case the VBT is bonkers on some g4x machines and indicates the precense of eDP. Signed-off-by:
-
Egbert Eich authored
An HPD interrupt may fire while we are in a function that changes the PORT_HOTPLUG_EN register - especially when an HPD interrupt storm occurs. Since the interrupt handler changes the enabled HPD lines when it detects such a storm the read-modify-write cycles may interfere. To avoid this, shiled the rmw cycles with IRQ save spinlocks. Changes since v1: - Implement a function which takes care of accessing PORT_HOTPLUG_EN. Signed-off-by:
Egbert Eich <eich@suse.de> Signed-off-by:
-
Dongwon Kim authored
We can calculate BXT values correctly from GFX fuse values without hardcoding special limits. Cc: Imre Deak <imre.deak@intel.com> Cc: Matthew D Roper <matthew.d.roper@intel.com> Signed-off-by:
Dongwon Kim <dongwon.kim@intel.com> Reviewed-by:
-
Michał Winiarski authored
It would be initialized just moments later by i915_init_vm. Rearrange the code such that i915_init_vm() is next to its callers inside i915_gem_gtt (and so we can make it static). After removing the dance around the files, it is clear that we are repeating some work inside the initializers (such as calling drm_mm_init() multiple times), so take advantage of the refactor to also remove some redundant code and clean up the interface. v2: Commit msg update, s/i915_init_vm/i915_address_space_init, move to i915_gem_gtt.c, init address_space during i915_gem_setup_global_gtt for ggtt. v3: Do not init global_link - we are adding it to vm_list moments later, make i915_address_space_init static, use OOP style parameter order. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:Michał Winiarski <michal.winiarski@intel.com> Reviewed-by Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Finally managed to dig up enough hints as to where the stolen reserved stuff lives on ctg/elk. So add the code to decode it. This was a combination of old chipset specs, diggin up an old elk grits release with an ctg/elk AubLoad etc. This was only tested on an elk as I don't have a ctg here unfortunately. This leaves ilk as the only platform that doesn't have a way to detect this stuff. Looking at the register contents on my ilk, it might be that the elk way works there too, but I can't be sure since I can't affect the amount of reserved memory on that machine, and if I am to trust the register contents, by default it would reserve 0 bytes. v2: s/WARN_ON_ONCE/WARN_ON/ since it's in one time init code anyway (Paulo) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
I only tested this on BDW and SKL, but since the register description is the same ever since gen4, let's assume that all gens take the same register format. If that's not true, then hopefully someone will bisect a bug to this patch and we'll fix it. Notice that the wrong fence offset register just means that the hardware tracking will be wrong. Testcases: - igt/kms_frontbuffer_tracking/fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt - igt/kms_frontbuffer_tracking/fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt v2: - Add intel_crtc->adjusted_{x,y} so this code can work independently of intel_gen4_compute_page_offset(). (Ville). - This version also works on SKL. Signed-off-by: -
Paulo Zanoni authored
This commit is essentially a rewrite of "drm/i915: Check pixel format for fbc" from Ville Syrjälä. The idea is the same, but the code is different due to all the changes that happened since his original patch. So any bugs are due to my bad rewrite. v2: - Drop the alpha formats (Ville). v3: - Drop the stale comment (Ville). Testcases: igt/kms_frontbuffer_tracking/*fbc*-${format_name}-draw-* Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: -
Paulo Zanoni authored
This WA is only for HSW/BDW. Reviewed-by:
-
Paulo Zanoni authored
The spec says the register should have that value for the entire time that FBC is enabled, so apply the WA before we enable FBC. Notice that we also have this WA for ILK/SNB, but it is implemented at init_clock_gating(). I could move the IVB/HSW/BDW WA code to init_clock_gating() too, but since we recently had some complaints about WAs not staying after being set, I'm going to play safe and keep this here for now. Reviewed-by:
-
Paulo Zanoni authored
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 authored
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:
-
Paulo Zanoni authored
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 authored
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 authored
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:
-
Maarten Lankhorst authored
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:
-
Sagar Arun Kamble authored
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:
-
Sagar Arun Kamble authored
Cc: Tom O'Rourke <Tom.O'Rourke@intel.com> Cc: Akash Goel <akash.goel@intel.com> Signed-off-by:
-
Sagar Arun Kamble authored
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 authored
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 authored
It will be usefull to specify w/a that affects only SKL GT3 and GT4. Signed-off-by:
-
Jesse Barnes authored
Looks like this was introduced in: commit d1675198 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:
-
Ville Syrjälä authored
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:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
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 4cf0ebbd 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ä authored
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:
-
Sonika Jindal authored
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:
-
Shashank Sharma authored
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:Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
Shashank Sharma authored
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:
-
