- 23 Apr, 2013 8 commits
-
-
Damien Lespiau authored
Let's introduce one more of those orthogonal feature macros. This should hopefully make the code more readable and make things easier for new platform enabling. This time, HAS_FPGA_DBG_UNCLAIMED() is true for platforms that have bit 31 of FPGA_DBG able to signal unclaimed writes. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
This way, when adding a device flag we don't have to manually maintain that list. v2: undefine the helper macros (Jani Nikula, Daniel Vetter) Signed-off-by:
-
Damien Lespiau authored
DEV_INFO_FOR_FLAG() now takes 2 parameters: • A function to apply to the flag • A separator This will allow us to use the macro twice in the DRM_DEBUG_DRIVER() call of i915_dump_device_info(). v2: Fix a typo in the subject (Jani Nikula) v3: Undef the helper macros (Jani Nikula, Daniel vetter) Reviewed-by:
-
Egbert Eich authored
Instead of calling into the DRM helper layer to poll all connectors for changes in connected displays probe only those connectors which have received a hotplug event. v2: Resolved conflicts with changes in previous commits. Renamed function and and added a WARN_ON() to warn of intel_hpd_irq_event() from being called without mode_config.mutex held - suggested by Jani Nikula. Signed-off-by:Egbert Eich <eich@suse.de> Reviewed-by:
-
Egbert Eich authored
This way it is possible to limit 're'-detect() of displays to connectors which have received an HPD event. v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking. v3: Fixed merge conflicts with previous patches. Signed-off-by:
-
Jesse Barnes authored
We need to hold the rps lock around punit access. Reported-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
- 22 Apr, 2013 3 commits
-
-
Kenneth Graunke authored
Now that we have function pointers, it's cleaner to just create a new per-platform PTE encoding function. This should be identical in behavior to the previous code. v2: Drop accidental inline keyword on hsw_pte_encode. Signed-off-by:
-
Kenneth Graunke authored
On Bay Trail, bit 1 means "writeable by the GPU." Failing to set that means basically anything using the GPU will cause hangs. v2: Drop accidental inline keyword on byt_pte_encode. Signed-off-by:
-
Kenneth Graunke authored
Sandybridge/Ivybridge, Bay Trail, and Haswell all have slightly different page table entry formats. Rather than polluting one function with generation checks, simply use a function pointer and set up the correct PTE encoding function at startup. v2: Move the gen6_gtt_pte_t typedef to i915_drv.h so that the function pointers and implementations have identical signatures. Also remove inline keyword on gen6_pte_encode. Both suggested by Jani Nikula. Signed-off-by:Jani Nikula <jani.nikula@linux.intel.com> Tested-by: Daniel Leung <daniel.leung@linux.intel.com> [v1] Signed-off-by:
-
- 20 Apr, 2013 1 commit
-
-
Ville Syrjälä authored
This allows unifying a bunch of the PLL calculations and whatnot. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 19 Apr, 2013 8 commits
-
-
Jesse Barnes authored
Minor cleanup. Would be nice to use an enum for channel in the DPIO macros so we don't mix up pipes and channels, but that's for another patch. Signed-off-by:
-
Damien Lespiau authored
We are trying to have more platform-orthogonal pieces of code. The DDI code shouldn't mention Haswell. v2: Fix the email address Signed-off-by:
-
Ville Syrjälä authored
Shame on me for not putting the bit definitions next to the register definition in the first place. Signed-off-by:
-
Paulo Zanoni authored
... inside haswell_get_pipe_config. Because there's one TRANS_DDI_FUNC_CTL register per CPU transcoder, not per pipe. This solves "unclaimed register" messages when booting with eDP only and using the i915.disable_power_well=1. Also fix a comment and remove an useless empty line. The error messages were caused by: commit 88adfff1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Mar 28 10:42:01 2013 +0100 drm/i915: hw readout support for ->has_pch_encoders Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Paulo Zanoni authored
This fixes "unclaimed register" messages when booting with eDP only and i915.disable_power_well=1. The error messages were caused by: commit 0e8ffe1b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Mar 28 10:42:00 2013 +0100 drm/i915: add hw state readout/checking for pipe_config Signed-off-by:
-
Paulo Zanoni authored
This is bad news and shouldn't be happening. V2: Rebase. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Paulo Zanoni authored
In this commit we enable both CPU and PCH FIFO underrun reporting and start reporting them. We follow a few rules: - after we receive one of these errors, we mask the interrupt, so we won't get an "interrupt storm" and we also won't flood dmesg; - at each mode set we enable the interrupts again, so we'll see each message at most once per mode set; - in the specific places where we need to ignore the errors, we completely mask the interrupts. The downside of this patch is that since we're completely disabling (masking) the interrupts instead of just not printing error messages, we will mask more than just what we want on IVB/HSW CPU interrupts (due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll also be masking PCH FIFO underruns for pipe B, because both are reported by SERR_INT, which has to be either completely enabled or completely disabled (in othe words, there's no way to disable/enable specific bits of GEN7_ERR_INT and SERR_INT). V2: Rename some functions and variables, downgrade messages to DRM_DEBUG_DRIVER and rebase. Signed-off-by: -
Jesse Barnes authored
In Valleyview voltage swing, pre-emphasis and lane control registers can be programmed only through the h/w side band fabric. Update vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the appropriate programming. We need to make sure that the tx lane reset occurs in both the full mode set and DPMS paths, so factor things out to allow that. v2: use different DPIO_DIVISOR values for VGA and DisplayPort v3: Fix update pll logic to use same DPIO_DIVISOR & DPIO_REFSFR values for all display interfaces v4: collapse with various updates v5: squash with crtc enable/pll enable bits v6: split out DP code (jbarnes) put phyready check under IS_VALLEYVIEW (jbarnes) remove unneeded check in 9xx pll div update (Jani) wrap VLV pll update call in IS_VALLEYVIEW (Jani) move port enable back to end of crtc enable (jbarnes) put phyready check under IS_VALLEYVIEW (jbarnes) v7: fix up conflicts against latest drm-intel-next-queued v8: use DPIO reg names, fix pipes (Jani) from mPhy_registers_VLV2_ww20p5 doc v9: update to latest info from driver enabling notes doc driver_vbios_notes_9 v10: fixup a bit of pipe/port confusion to allow eDP and HDMI to work simultaneously (Jesse) v11: use pll/port callbacks for DPIO port activity (Daniel) use separate VLV CRTC enable function (Daniel) move around port ready checks (Jesse) Signed-off-by:Pallavi G <pallavi.g@intel.com> Signed-off-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
-
- 18 Apr, 2013 20 commits
-
-
Jesse Barnes authored
This is a reset feature we don't actually need. Signed-off-by:
-
Pallavi G authored
Program few Tx buffer Swing control settings through DPIO. v2: fix up codingstyle (Daniel) call from set_signal_levels (Ville, Daniel) use proper port numbers (Jesse) Signed-off-by:Yogesh M <yogesh.mohan.marimuthu@intel.com> Signed-off-by:
-
Daniel Vetter authored
Stolen from a patch with the below impressive sob-section. Signed-off-by:
-
Daniel Vetter authored
Magic updates. v2: use 64 bit types and math (Ville) v3: Trim out all the m/n/p calculation changes since they are still under discussion. Instead squash in a fixup for hdmi limits which slipped into a different patch. Signed-off-by:
-
Jesse Barnes authored
Uses slightly different interfaces than other platforms. v2: track actual set freq, not requested (Rohit) fix debug prints in init code (Jesse) v3: don't write sleep reg (Jesse) re-add RC6 wake limit write (Ben) fixup thresholds to match other platforms (Ben) clean up mem freq calculation (Ben) clean up debug prints (Ben) v4: move defines from punit patch (Ville) v5: remove writes to nonexistent regs (Jesse) put RP and RC regs together (Jesse) fix RC6 enable (Jesse) v6: use correct fuse reads from NC (Jesse) split out min/max funcs for use in sysfs (Jesse) add debugfs & sysfs freq controls (Jesse) v7: update with Ben's hw_max changes (Jesse) Signed-off-by: -
Jesse Barnes authored
When requesting frequency changes or querying status from the Punit, we need to use an opcode that corresponds to the frequency, taking into account the memory frequency. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ville Syrjälä authored
Add sprite_name() macro which should be used with the kind of sprites that are fixed to pipes (gen4.5+). Also use dev_priv->num_plane to calculate the sprite index insted assuming two sprites per pipe. This should make it print the right name. Signed-off-by:
-
Ville Syrjälä authored
Print the alphabetical name for transcoders. The code already used the pipe_name() macro for transcoders, so I did the same. But we do have the (unused) transcoder_name() macro which could be used instead. Signed-off-by:
-
Ville Syrjälä authored
Alway use the alphabetical names in debug/error messages for planes, pipes and ports, instead of using decimal numbers occasionally. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Get rid of the few remaining open coded copies of pipe_name() and port_name(). Signed-off-by:
-
Daniel Vetter authored
When adding the pipe config computation step I've accidentally moved this a bit away. Which momentarily confused me since the pipe config step rejected some modesetting operations I expected and so left me looking in vain for that debug output. v2: Move the debug output into the right function to prevent this from happening again. v3: Make it compile (Ville). Also reorder the patch so that the two bugfixes are first. Signed-off-by: -
Daniel Vetter authored
We can only enable the pfit if the pipe is disabled. Ensure that this is obeyed with a neat assert. Also check whether the pfit is off before enabling it - if not we've lost track of things somewhere since the pfit is only ever used by the lvds output. v2: Fix spell fail in the commit message pointed out by Ville&Jani. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
The i9xx modeset sequence is currently pretty fishy, so tight it all up with some good assert-sprinkling. We already have good coverage on the disable side, but the enable side is spotty (since until recently it was wrong). Reviewed-by:
-
Daniel Vetter authored
Just blows through 50ms for naught, since the pipe is off. Reviewed-by:
-
Daniel Vetter authored
This is horrible lore and we should be able to get rid of it now that the lvds/pfit handling code actually does the right thing. Reviewed-by:
-
Daniel Vetter authored
Oops. This regression has been introduced in commit 5d2d38dd Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:45:01 2013 +0100 drm/i915: clean up pipe bpp confusion Reported-by:
-
Daniel Vetter authored
For a bunch of reason we need to more accurately track this: - hw pipe state readout for Haswell needs the cpu transcoder. - We need to know the right cpu transcoder in a bunch of places in ->disable and other modeset callbacks. In the future we need to add hw state readout&check support, too. But to avoid ugly merge conflicts do the rote sed job now without any functional changes. v2: Preserve the cpu_transcoder value when overwriting crtc->config. Reported by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Paulo Zanoni authored
Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits are being zeroed, but I couldn't find a reason for this, so leave them as they are for now to avoid regressions. Signed-off-by:
-
Paulo Zanoni authored
Check the VBT to see if the machine has inverted FDI RX polarity on CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2 registers. This should fix some machines that were showing black screens on all outputs. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029Signed-off-by:
-
