- 20 Mar, 2015 15 commits
-
-
Ville Syrjälä authored
"P1273_DPLL_Programming Spreadsheet.xlsm" lists a boatload of frequencies for eDP. Try to use them all. For now I've decided not to add hardcoded DPLL dividers for these cases since chv_find_best_dpll() works just fine. I've not actually tested any of these since I don't have an eDP 1.4 panel. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Complain loudly if we ever attempt to overflow the the supported_rates[] array. This should never happen since the sink_rates[] array will always be smaller or of equal size. But should someone change that we want to catch it without scribblign over the stack. Signed-off-by:
-
Ville Syrjälä authored
Now that intel_dp_max_link_bw() no longer considers the source restrictions we may try to enable MST with 5.4GHz even when the source doesn't support it. To fix that switch the code over to handle the link rate in the same way as the SST code handles it. Signed-off-by:
-
Ville Syrjälä authored
Drop the gen9 checks from the code and issue DP_LINK_RATE_SET whenever the sink reports to support it. Signed-off-by:
-
Ville Syrjälä authored
Consider the link rates reported by the sink via DP_SUPPORTED_LINK_RATES when checking modes against the max link rate. Signed-off-by:
-
Ville Syrjälä authored
intel_dp_compute_config() only really needs to know the rates supported by both source and sink, so hide the raw source and sink arrays from it. Signed-off-by:
-
Ville Syrjälä authored
Remove the sink vs. source limit mess from intel_dp_max_link_bw() and just move the source restriction checks to intel_dp_source_rates(). Signed-off-by:
-
Ville Syrjälä authored
Now that both source and sink rates are always filled in there's no need for any special cases in intel_supported_rates(). Signed-off-by:
-
Ville Syrjälä authored
Once we've read the rates from the sink we don't have to mess with them, so the caller can just look at the stored rates without doing extra copies. If the sink doesn't support the new link rate stuff, we just point the caller at the default_rates[] array. Signed-off-by:
-
Ville Syrjälä authored
The source rates don't change, so we can just point the caller at the const arrays. Signed-off-by:
Todd Previte <tprevite@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
No point in converting from hardware format every single time, just store the rates in the final format under intel_dp. Signed-off-by:
-
Ville Syrjälä authored
No point in using uint32_t here, just plain old int will do. Signed-off-by:
-
Joonas Lahtinen authored
GGTT views are only applicable when dealing with GGTT. Change the code to reject ggtt_view where it should not be used and require it when it should be. v2: - Dropped _ppgtt_ infixes, allow both types to be passed - Disregard other but normal views when no view is specified - More checks that valid parameters are passed - More readable error checking v3: - Prefer WARN_ONCE over BUG_ON when there is code path for failure Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> [danvet: Drop unecessary forward decl from earlier patch iterations.] [danvet: Remove unused variable spotted by Tvrtko.] Signed-off-by:
-
Rodrigo Vivi authored
Regressed by this commit: commit 3455454e18ca3f92c565700539e744c620d8276b Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Mar 3 15:21:56 2015 +0200 drm/i915: Add a for_each_intel_connector macro Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Backmerge because of numerous and interleaving conflicts and git rerere getting confused a bit too often. Conflicts: drivers/gpu/drm/i915/intel_display.c All conflicts are because of -next patches backported to -fixes, so just go with the code in -next. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
- 18 Mar, 2015 1 commit
-
-
Damien Lespiau authored
We don't want to end up in a state where we track that the pipe has its primary plane enabled when primary plane registers are programmed with values that look possible but the plane actually disabled. Refuse to read out the fb state when the primary plane isn't enabled. Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Andrey Skvortsov <andrej.skvortzov@gmail.com> Reported-by:
Steven Rostedt <rostedt@goodmis.org> Reference: http://mid.gmane.org/20150203191507.GA2374@crion86Tested-by:
Jani Nikula <jani.nikula@intel.com>
-
- 17 Mar, 2015 24 commits
-
-
Daniel Vetter authored
Signed-off-by: -
Mika Kuoppala authored
vmap_batch() calculates amount of needed pages for the mapping we are going to create. And it uses this page count as an argument for the for_each_sg_pages() macro. The macro takes the number of sg list entities as an argument, not the page count. So we ended up iterating through all the pages on the mapped object, corrupting memory past the smaller pages[] array. Fix this by bailing out when we have enough pages. This regression has been introduced in commit 17cabf57 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 14 11:20:57 2015 +0000 drm/i915: Trim the command parser allocations Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Jeff McGee authored
Setup new I915_GETPARAM ioctl entries for subslice total and EU total. Userspace drivers need these values when constructing GPGPU commands. This kernel query method is intended to replace the PCI ID-based tables that userspace drivers currently maintain. The kernel driver can employ fuse register reads as needed to ensure the most accurate determination of GT config attributes. This first became important with Cherryview in which the config could differ between devices with the same PCI ID. The kernel detection of these values is device-specific and not included in this patch. Because zero is not a valid value for any of these parameters, a value of zero is interpreted as unknown for the device. Userspace drivers should continue to maintain ID-based tables for older devices not supported by the new query method. v2: Increment our I915_GETPARAM indices to fit after REVISION which was merged ahead of us. For: VIZ-4636 Signed-off-by:Jeff McGee <jeff.mcgee@intel.com> Tested-by:
Zhigang Gong <zhigang.gong@linux.intel.com> Acked-by:
-
Jani Nikula authored
Same as commit c883ef1b Author: Mika Kuoppala <miku@iki.fi> Date: Tue Oct 28 17:32:30 2014 +0200 drm/i915: Redefine WARN_ON to include the condition but for WARN_ON_ONCE. Since the kernel WARN_ON_ONCE actually picks up *our* version of WARN_ON, we end up with messages like [ 838.285319] WARN_ON(!__warned) which are not that helpful. Signed-off-by:
-
Damien Lespiau authored
v2: Use the recently introduced INTEL_REVID() and SKL_REVID defines (Nick Hoath) Signed-off-by:Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by:
-
Ville Syrjälä authored
CHV should be in a good enough shape now, so let's drop the .is_preliminary flag. Signed-off-by:
-
Ville Syrjälä authored
We accidentally pass 'pipe' instead of 'port' to CHV_PLL_DW8() and with PIPE_C we end up at register offset 0x8320 which isn't the 0x8020 we wanted. Fix it. The problem was fortunately caught by the sanity check in vlv_dpio_read(): WARNING: CPU: 1 PID: 238 at ../drivers/gpu/drm/i915/intel_sideband.c:200 vlv_dpio_read+0x77/0x80 [i915]() DPIO read pipe C reg 0x8320 == 0xffffffff The problem got introduced with this commit: commit 71af07f91f12bbab96335e202c82525d31680960 Author: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Date: Thu Mar 5 19:33:08 2015 +0530 drm/i915: Update prop, int co-eff and gain threshold for CHV Cc: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Signed-off-by: -
Ville Syrjälä authored
Ignore the current state of the pipe and just check crtc_state->enable and the number of FDI lanes required. This means we don't accidentally mistake the FDI lanes as being available of one of the pipes just happens to be disabled at the time of the check. Also we no longer consider pipe C to require FDI lanes when it's driving the eDP transcoder. We also take the opportunity to make the code a bit nicer looking by hiding the ugly bits in the new pipe_required_fdi_lanes() function. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
The logic in the FDI lane checks is very hard for my poor brain to grasp. Rewrite it in a more straightforward way. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Akash Goel authored
Enable the RPS interrupts programming(enable/disable/reset) for GEN9, as missing changes to enable the RPS support on GEN9 have been added. Signed-off-by:
Akash Goel <akash.goel@intel.com> Reviewed-by:
-
Akash Goel authored
Earlier Turbo interrupts were not being processed for SKL, as something was amiss in turbo programming for SKL. Now missing changes have been added, so enabling the Turbo interrupt processing for SKL. Signed-off-by:
-
Akash Goel authored
Added support for SKL in the i915_frequency_info debugfs function v2: - corrected the handling of reqf (Damien) - Reorderd the platform check for cagf (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Remove the global modeset resource function that would disable the bifurcation bit, and instead enable/disable it when enabling the pch transcoder. The mode set consistency check should prevent us from disabling the bit if pipe C is enabled so the change should be safe. Note that this doens't affect the logic that prevents the bit being set while a pipe is active, since the patch retains the behavior of only chaging the bit if necessary. Because of the checks during mode set, the first change would necessarily happen with both pipes B and C disabled, and any subsequent write would be skipped. v2: Only change the bit during pch trancoder enable. (Ville) Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
-
Akash Goel authored
Added support for SKL in the act_freq_mhz_show sysfs function Signed-off-by:
-
Akash Goel authored
On SKL, GT frequency is programmed in units of 16.66 MHZ units compared to 50 MHZ for older platforms. Also the time value specified for Up/Down EI & Up/Down thresholds are expressed in units of 1.33 us, compared to 1.28 us for older platforms. So updated the gen9_enable_rps function as per that. v2: Updated to use new macro GT_INTERVAL_FROM_US v3: Removed the initial setup of certain registers, from gen9_enable_rps, which gets overridden later from gen6_set_rps (Damien) v4: Removed the enabling of rps interrupts, from gen9_enable_rps. To be done from intel_gen6_powersave_work only, as done for other platforms also. Signed-off-by: -
Akash Goel authored
RP Interrupt Up/Down Frequency Limits register (A014) definition has changed for SKL. Updated the gen6_rps_limits function as per that v2: Renamed the function to intel_rps_limits (Chris) Signed-off-by:
-
Akash Goel authored
Prior to SKL, the time period programmed in Up/Down EI & Up/Down threshold registers was in units of 1.28 micro seconds. But for SKL, the units have changed (1.333 micro seconds). Have generalized the implementation of gen6_set_rps_thresholds function, by removing the hard coding done in it as per 1.28 micro seconds. v2: Renamed the local variables & removed superfluous comments (Chris) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Akash Goel authored
On SKL, the frequency is programmed differently in RPNSWREQ (A008) register (from bits 23 to 31, compared to bits 24 to 31). So updated the gen6_set_rps function, as per this change. Signed-off-by:
-
Akash Goel authored
On SKL the frequency is specified in units of 16.66 MHZ, barring the RP_STATE_CAP(0x5998) register, which still reports frequency in units of 50 MHZ. So an extra conversion is required in gen6_init_rps_frequencies function for SKL, to store the frequency values as per the actual hardware unit. v2: Corrected the conversion from 50 to 16.66 MHZ (Ville) Signed-off-by:
-
Akash Goel authored
On SKL, frequency is specified in units of 16.66 MHZ. Updated the intel_gpu_freq() and intel_freq_opecode() functions to do the conversion appropriately. Signed-off-by:
-
Akash Goel authored
For SKL, register definition for RPNSWREQ (A008), RPSTAT1(A01C) have changed slightly. Also on SKL, frequency is specified in units of 16.66 MHZ, compared to 50 MHZ for most of the earlier platforms and the time values are expressed in units of 1.33 us, compared to 1.28 us for earlier platforms. Added new macros for the aforementioned changes. v2: Renamed the GT_FREQ_FROM_PERIOD macro to GT_INTERVAL_FROM_US (Damien) v3: Removed the implicit use of dev_priv in GT_INTERVAL_FROM_US macro (Chris) Signed-off-by:
-
Jani Nikula authored
Spell all the PCI IDs out to be able to quickly grep for the IDs. No functional changes. Signed-off-by:
-
Ville Syrjälä authored
Use the FW_WM() macro from the VLV wm code to polish up the wm code for older gmch platforms. Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
Wrap the FW register value shift+mask operations into a macro to hide the ugliness a bit. Also might avoid bugs due to typos. Also rename all the primary/sprite plane low order bit masks to have the _VLV suffix, so that we can use the FW_WM_VLV() macro instead of the FW_WM() macro for them in a consistent manner. Cursor and all the high order bits are left to use the FW_WM() macro as there's no real confusion with them. Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
