An error occurred fetching the project authors.
- 10 Sep, 2015 1 commit
-
-
Shashank Sharma authored
This patch adds the intel_connector initialized to intel_hdmi display, during the init phase, just like the other encoders do. This attachment is very useful when we need to extract the connector pointer during the hotplug handler function Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 Sep, 2015 1 commit
-
-
Jani Nikula authored
There is no need to have a separate flag for tps3 as the information is only used at one location. Move the logic there to make it easier to follow. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 Sep, 2015 3 commits
-
-
Maarten Lankhorst authored
This makes the error message slightly more useful. Changes since v1: - Use ktime_get() while irqs are still disabled. (vsyrjala) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
There's already a per crtc member that can be used for it. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Make it available outside of intel_dp.c. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 Sep, 2015 1 commit
-
-
Ander Conselvan de Oliveira authored
The DP MST encoder config function never sets ddi_pll_sel, even though its value is programmed in its ->pre_enable() hook. That used to work because a new pipe_config was kzalloc'ed at every modeset, and the value of zero selects the highest clock for the PLL. Starting with the commit below, the value of ddi_pll_sel is preserved through modesets, and since the correct value wasn't properly setup by the MST code, it could lead to warnings and blank screens. commit 8504c74c Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Fri May 15 11:51:50 2015 +0300 drm/i915: Preserve ddi_pll_sel when allocating new pipe_config Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628 Cc: stable@vger.kernel.org # 7e6313a2 drm/i915: Don't use link_bw for PLL setup Cc: stable@vger.kernel.org Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
- 26 Aug, 2015 6 commits
-
-
Ville Syrjälä authored
Normmally the common lane in a PHY channel gets powered up when some of the data lanes get powered up. But when we're driving port B with pipe B we don't want to enabled any of the data lanes, and just want the DPLL in the common lane to be active. To make that happens we have to temporarily enable some data lanes after which we can access the DPLL registers in the common lane. Once the pipe is up and running we can drop the power override on the data lanes allowing them to shut down. From this point forward the common lane will in fact stay powered on until the data lanes in the other channel get powered down. Ville's extended explanation from the review thread: On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote: > One Q, why only for port B? Port C is also in same common lane right? Port B is in the first PHY channel which also houses CL1. CL1 always powers up whenever any lanes in either PHY channel are powered up. CL2 only powers up if lanes in the second channel (ie. the one with port C) powers up. So in this scenario (pipe B->port B) we want the DPLL from CL2, but ideally we only want to power up the lanes for port B. Powering up port B lanes will only power up CL1, but as we need CL2 instead we need to, temporarily, power up some lanes in port C as well. Crossing the streams the other way (pipe A->port C) is not a problem since CL1 powers up whenever anything else powers up. So powering up some port C lanes is enough on its own to make the CL1 DPLL operational, even though CL1 and the lanes live in separate channels. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Deepak S <deepak.s@linux.intel.com> [danvet: Amend commit message with extended explanation.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Powergate the PHY lanes when they're not needed. For HDMI all four lanes are needed always, but for DP we can enable only the needed lanes. To power down the unused lanes we use some power down override bits in the DISPLAY_PHY_CONTROL register. Without the overrides it appears that the hardware always powers on all the lanes. When the port is disabled the power down override is not needed and the lanes will shut off on their own. That also means the override is critical to actually be able to access the DPIO registers before the port is actually enabled. Additionally the common lanes will power down when not needed. CL1 remains on as long as anything else is on, CL2 will shut down when all the lanes in the same channel will shut down. There is one exception for CL2 that will be dealt in a separate patch for clarity. With potentially some lanes powered down, the DP code now has to check the number of active lanes before accessing PCS/TX registers. All registers in powered down blocks will reads as 0xffffffff, and soe we would drown in warnings from vlv_dpio_read() if we allowed the code to access all those registers. Another important detail in the DP code is the "TX latency optimal" setting. Normally the second TX lane acts as some kind of reset master, with the other lanes as slaves. But when only a single lane is enabled, that single lane obviously has to be the master. A bit of extra care is needed to reconstruct the initial state of the DISPLAY_PHY_CONTROL register since it can't be read safely. So instead read the actual lane status from the DPLL/PHY_STATUS registers and use that to determine which lanes ought to be powergated initially. We also need to switch the PHY power modes to "deep PSR" to avoid a hard system hang when powering down the single channel PHY. Also sprinkle a few debug prints around so that we can monitor the DISPLAY_PHY_STATUS changes without having to read it and risk corrupting it. v2: Add locking to chv_powergate_phy_lanes() v3: Actually enable dynamic powerdown in the PHY and deal with the fallout Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
The function can be made static there. No functional changes. Reviewed-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Add vlv_dport_to_phy() and fix up the return values of vlv_dport_to_channel() and vlv_pipe_to_channel() to use the appropriate enums. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Move the CHV clock buffer disable from chv_disable_pll() to the new encoder .post_pll_disable() hook. This is more symmetric since the clock buffer enable happens from the .pre_pll_enable() hook. We'll have more use for the new hook soon. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
With MST there won't be a crtc assigned to the main link encoder, so trying to dig up the pipe_config from there is a recipe for an oops. Instead store the parameters (lane_count and link_rate) in the encoder, and use those values during link training etc. Since those parameters are now assigned only when the link is actually enabled, .compute_config() won't clobber them as it did before. Hardware state readout is still bonkers though as we don't transfer the link parameters from pipe_config intel_dp. We should do that during encoder sanitation. But since we don't even do a proper job of reading out the main link encoder state for MST there's littel point in worrying about this now. Fixes a regression with MST caused by: commit 90a6b7b0 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Jul 6 16:39:15 2015 +0300 drm/i915: Move intel_dp->lane_count into pipe_config v2: Different apporoach that should keep intel_dp_check_mst_status() somewhat less oopsy Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 Aug, 2015 8 commits
-
-
Ville Syrjälä authored
We only need the link_bw/rate_select parameters when starting link training, and they should be computed based on the currently active config, so throw them out from intel_dp and just compute on demand. Toss in an extra debug print to see rate_select in addition to link_bw, as the latter may be 0 for eDP 1.4. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Currently we clobber intel_dp->lane_count in compute config, which means after a rejected modeset we may no longer be able to retrain the current link. Move lane_count into pipe_config to avoid that. v2: Add missing ':' to the pipe config debug dump Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Currently we treat intel_{dp,hdmi}->color_range as partly user controller value (via the property) but we also change it during .compute_config() when using the "Automatic" mode. That is a bit confusing, so let's just change things so that we store the user property values in intel_dp, and only change what's stored in pipe_config during .compute_config(). There should be no functional change. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
By Vesa DP 1.2 Spec TEST_CRC_COUNT should be "reset to 0 when TEST_SINK bit 0 = 0." However for some strange reason when PSR is enabled in certain platforms this is not true. At least not immediatelly. So we face cases like this: first get_sink_crc operation: count: 0, crc: 000000000000 count: 1, crc: c101c101c101 returned expected crc: c101c101c101 secont get_sink_crc operation: count: 1, crc: c101c101c101 count: 0, crc: 000000000000 count: 1, crc: 0000c1010000 should return expected crc: 0000c1010000 But also the reset to 0 should be faster resulting into: get_sink_crc operation: count: 1, crc: c101c101c101 count: 1, crc: 0000c1010000 should return expected crc: 0000c1010000 So in order to know that the second one is valid one we need to compare the pair (count, crc) with latest (count, crc). If the pair changed you have your valid CRC. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Rafael Antognolli <rafael.antognolli@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
By Vesa DP spec, test counter at DP_TEST_SINK_MISC just reset to 0 when unsetting DP_TEST_SINK_START, so let's force this stop here. But let's minimize the aux transactions and just do it when we know it hasn't been properly stoped. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Rafael Antognolli <rafael.antognolli@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
There are no more users, byebye! Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
This is now done completely atomically. Keep connectors_active for now, but make it mirror crtc_state->active. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
First step in removing dpms and validating atomic state. There can still be a mismatch in the connector state because the dpms callbacks are still used, but this can not happen immediately after a modeset. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 11 Aug, 2015 1 commit
-
-
Daniel Vetter authored
Instead of our own duplicated one. This fixes a bug in the driver unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we try to unregister the nonexistent fbdev drm_framebuffer. Cc: Archit Taneja <architt@codeaurora.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 Aug, 2015 1 commit
-
-
Paulo Zanoni authored
Due to the way busy_bits was handled, we were not doing any flushes if we didn't previously get an invalidate. Since it's possible to get flushes without an invalidate first, remove the busy_bits early return. So now that we don't have the busy_bits guard anymore we'll need the origin check for the GTT tracking (we were not doing anything on GTT flushes due to the GTT check at invalidate()). As a last detail, since we can get multiple consecutive flushes, disable FBC before updating it, otherwise intel_fbc_update() will just keep FBC enabled instead of restarting it. Notice that this does not fix any of the current IGT tests due to the fact that we still have a few intel_fbc() calls at points where we also have the frontbuffer tracking calls: we didn't fully convert to frontbuffer tracking yet. Once we remove those calls and start relying only on the frontbuffer tracking infrastructure we'll need this patch. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 Jul, 2015 1 commit
-
-
Maarten Lankhorst authored
This is required to properly handle failing dpms calls. When making a wait in i915 interruptible, I've noticed that the dpms sequence could fail with -ERESTARTSYS because it was waiting interruptibly for flips. So from now on allow drivers to fail in their connector dpms callback. Encoder and crtc dpms callbacks are unaffected. Changes since v1: - Update kerneldoc for the drm helper functions. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Resolve conflicts due to different merge order.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 Jul, 2015 1 commit
-
-
Shobhit Kumar authored
Use the CRC PWM device in intel_panel.c and add new MIPI backlight specififc callbacks v2: Modify to use pwm_config callback v3: Addressed Jani's comments - Renamed all function as pwm_* instead of vlv_* - Call intel_panel_actually_set_backlight in enable function - Return -ENODEV in case pwm_get fails - in case pwm_config error return error cdoe from pwm_config - Cleanup pwm in intel_panel_destroy_backlight v4: Removed unused #defines and initialized backlight with INVALID_PIPE (Ville) CC: Samuel Ortiz <sameo@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 15 Jul, 2015 3 commits
-
-
Daniel Vetter authored
Currently we both set mode->private_flags to some value and also use the pipe_config quirk. But since the pipe_config quirk isn't tied to the lifetime of the mode object we need to check both. Simplify this by only using mode.private_flags and stop using the INHERITED_MODE quirk. Also for clarity add an explicit #define for that driver priavete mode flag. By using crtc_state->mode_changed we can also remove the recalc local variable. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
This can only fail because of a bug in the code. Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Squash in follow-up to also remove start_vbl_count from intel_crtc->atomic and put it into the intel_crtc directly - it's not precomputed state.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
Huzzah! \o/ Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 Jul, 2015 5 commits
-
-
Maarten Lankhorst authored
Calculate all state using a normal transition, but afterwards fudge crtc->state->active back to its old value. This should still allow state restore in setup_hw_state to work properly. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
The previous commit converted hw readout to atomic, all the new_* members were used for restoring the old state, but with the conversion of suspend to atomic there's no use left for them. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
All non-primary planes get disabled during hw readout, this reduces complexity and means not having to do some plane visibility checks during the first commit. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
Nothing depends on this outside initial hw readout, so keep this struct on the stack instead. Changes since v1: - Remove unrelated changes. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
There's not much point for calculating the changes for the old state. Instead just disable all scalers when disabling. It's probably good enough to just disable the crtc_scaler, but just in case there's a bug disable all scalers. This means intel_atomic_setup_scalers is only called in the crtc check function now, so all the transitional code can be removed. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 Jul, 2015 2 commits
-
-
Paulo Zanoni authored
So make it static. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Since flush actually means invalidate + flush we need to force psr exit on PSR flush. On Core platforms there is no way to disable hw tracking and do the pure sw tracking so we simulate it by fully disable psr and reschedule a enable back. So a good idea is to minimize sequential disable/enable in cases we know that HW tracking like when flush has been originated by a flip. Also flip had just invalidated it already. It also uses origin to minimize the a bit the amount of disable/enabled, mainly when flip already had invalidated. With this patch in place it is possible to do a flush on dirty areas properly in a following patch. v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 Jul, 2015 2 commits
-
-
Rodrigo Vivi authored
This will be useful to PSR and FBC once we start making dirty fb calls to also flush frontbuffer. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Because the cool kids use dev_priv and FBC wants to be cool too. We've been historically using struct drm_device on the FBC function arguments, but we only really need it for intel_vgpu_active(): we can use dev_priv everywhere else. So let's fully switch to dev_priv since I'm getting tired of adding "struct drm_device *dev = dev_priv->dev" everywhere. If I get a NACK here I'll propose the opposite: convert all the functions that currently take dev_priv to take dev. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 Jul, 2015 2 commits
-
-
Paulo Zanoni authored
Make sure we're not going to have weird races in really weird cases where a lot of different CRTCs are doing rendering and modesets at the same time. With this change and the stolen_lock from the previous patch, we can start removing the struct_mutex locking we have around FBC in the next patches. v2: - Rebase (6 months later) - Also lock debugfs and stolen. v3: - Don't lock a single value read (Chris). - Replace lockdep assertions with WARNs (Daniel). - Improve commit message. - Don't forget intel_pre_plane_update() locking. v4: - Don't remove struct_mutex at intel_pre_plane_update() (Chris). - Add comment regarding locking dependencies (Chris). - Rebase after the stolen code rework. - Rebase again after drm-intel-nightly changes. v5: - Rebase after the new stolen_lock patch. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4) Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
With the abstractions created by the last patch, we can move this code and the only thing inside intel_fbc.c that knows about dev_priv->mm is the code that reads stolen_base. We also had to move a call to i915_gem_stolen_cleanup_compression() - now called intel_fbc_cleanup_cfb() - outside i915_gem_stolen.c. v2: - Rebase after the remove_node() changes on the previous patch. Requested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 Jun, 2015 2 commits
-
-
Imre Deak authored
Depending on the platform the port clock fed to the pipe can be the PLL's post-divided fast clock rate or a /5 divided version of it. To make this more obvious across the platforms calculate this port clock along with the rest of the PLL parameters. This is also needed by the next patch where we can reuse the CHV helper for the BXT PLL HW readout code; so export the corresponding helper. While at it also add a more descriptive name to the helpers and a comment explaining what's being calculated. No functional change. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
David Weinehall authored
This patch adds support for 0.85V VccIO on Skylake Y, separate buffer translation tables for Skylake U, and support for I_boost for the entries that needs this. Changes in v2: * Refactored the code a bit to move all DDI signal level setup to intel_ddi.c Issue: VIZ-5677 Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com> Reviewed-by:
Antti Koskipää <antti.koskipaa@linux.intel.com> [danvet: Apply style polish checkpatch suggested.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-