aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_display.c
Commit message (Collapse)AuthorAge
...
* | drm/i915: Wait for pending page flips before enabling/disabling the primary ↵Ville Syrjälä2014-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | plane We have to write to the primary plane base address registrer when we enable/disable the primary plane in response to sprite coverage. Those writes will cause the flip counter to increment which could interfere with the detection of CS flip completion. We could end up completing CS flips before the CS has even executed the commands from the ring. To avoid such issues, wait for CS flips to finish before we toggle the primary plane on/off. v2: Rebased due to atomic sprite update changes Testcase: igt/kms_mmio_vs_cs_flip/setplane_vs_cs_flip Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Shuffle fifo underrun disable/enable points for gmch platformsVille Syrjälä2014-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gen2 reports FIFO underruns whenever no planes are enabled on the pipe. So in order to avoid false positives we must enable the FIFO underrun reporting only when at least one plane is enabled on the pipe. For now just move the underrun reporting enable/disable points to the other side of the plane enable/disable point. That doesn't cover cases when we turn off all the planes for the pipe but leave the pipe running on purpose, but it's better than the current situation. On gen4+ we can actually move the underrun reporting enable/disable to the opposite ends of the crtc enable/disable hooks. I suppose in theory we could leave the underrun reporting enabled all the time, except on VLV where PIPESTAT stops working when the display power well is down. If we ever get around to unifying the PIPESTAT irq handling for all gmch platforms, we should still follow the VLV route for other platforms. It would also micro-optimize the irq handler a bit since we could then skip the PIPESTAT reads for all disabled pipes. Gen3 is still a mystery, but for now I'm going to assume it behaves like gen4+. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Check for FIFO underruns at the end of modeset on gmchVille Syrjälä2014-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | FIFO underruns don't generate interrupts on gmch platforms, so if we want to know whether a modeset triggered FIFO underruns we need to explicitly check for them. As a modeset on one pipe could cause underruns on other pipes, check for underruns on all pipes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com> [danvet: Fix up merge error, kudos to Ville for noticing it.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Re-enable vblank irqs for already active pipesVille Syrjälä2014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a pipe is already active when we init/resume there might not be a full modeset afterwards so drm_vblank_on() may not get called. In such a case if someone is holding a vblank reference across a suspend/resume cycle drm_vblank_get() called after resuming won't re-enable the vblank interrupts. So in order to make sure vblank interrupts get re-enabled post-resume, call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already active. v2: Also drm_vblank_off() if the pipe got disabled magically Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Testecase: igt/kms_flip/vblank-vs-suspend Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge branch 'topic/drm-vblank-rework' into drm-intel-next-queuedDaniel Vetter2014-05-21
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in the drm vblank rework from Ville and me. drm core parts acked by Dave Airlie Conflicts: drivers/gpu/drm/i915/intel_display.c Just a bit of fun around the placement of drm_vblank_on. This merge resolution has been tested in drm-intel-nightly for a while already. Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Accurately initialize fifo underrun state on gmch platformsDaniel Vetter2014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't have hardware based disable bits on gmch platforms, so need to block spurious underrun reports in software. Which means that we _must_ start out with fifo underrun reporting disabled everywhere. This is in big contrast to ilk/hsw/cpt where there's only _one_ disable bit for all platforms and hence we must allow underrun reporting on disabled pipes. Otherwise nothing really works, especially the CRC support since that's key'ed off the same irq disable bit. This allows us to ditch the fifo underrun reporting hack from the vlv runtime pm code and unexport the internal function from i915_irq.c again. Yay! v2: Keep the display irq disabling, spotted by Imre. Cc: 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>
| * | drm/i915: Use new kms-native vblank functionsDaniel Vetter2014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only the low-level irq handling functions still use integer crtc indices with this. But fixing that will require a lot more sugery and some good ideas for backwards compat with old ums userspace. Both in drivers and in the drm core. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Remove drm_vblank_pre/post_modeset callsDaniel Vetter2014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally these functions have been for user modesetting drivers to ensure vblank processing doesn't fall over completely around modeset changes. This has been carried over ever since then. Now that Ville cleaned our vblank handling with an explicit drm_vblank_off/on braket when disabling/enabling crtcs. So this seems to be unnecessary now. The most important side effect was that due to the delayed vblank disabling we have been pretty much guaranteed to receive a vblank interrupt soonish after a crtc was enabled. Note that our vblank handling across modeset is still fairly decent fubar - we don't actually handle vblank counter all to well. drm_update_vblank_count will make sure that the frame counter always rolls forward, but userspace isn't really all to ready to cope with the big jumps this causes. This isn't a big mostly because the hardware retains the frame counter. But with runtime pm and also across suspend/resume we fall over. Fixing this is a lot more involved and also needs som i-g-ts. So material for another patch series. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm: Add drm_vblank_on()Ville Syrjälä2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_vblank_off() will turn off vblank interrupts, but as long as the refcount is elevated drm_vblank_get() will not re-enable them. This is a problem is someone is holding a vblank reference while a modeset is happening, and the driver requires vblank interrupt to work during that time. Add drm_vblank_on() as a counterpart to drm_vblank_off() which will re-enabled vblank interrupts if the refcount is already elevated. This will allow drivers to choose the specific places in the modeset sequence at which vblank interrupts get disabled and enabled. Testcase: igt/kms_flip/*-vs-suspend Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Add Testcase tag for the igt I've written.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Move buffer pinning and ring selection to intel_crtc_page_flip()Ville Syrjälä2014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All of the .queue_flip() callbacks duplicate the same code to pin the buffers and calculate the gtt_offset. Move that code to intel_crtc_page_flip(). In order to do that we must also move the ring selection logic there. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Drop the excessive vblank waits from modeset codepathsVille Syrjälä2014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we've plugged the mmio vs. ring flip race, we shouldn't need these vblank waits in the modeset codepaths anymore. So get rid of them. v2: gen2 needs to wait for planes to turn off before disabling pipe Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Wait for vblank in hsw_enable_ips()Ville Syrjälä2014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the vblank wait is gone from intel_enable_primary_plane(), hsw_enable_ips() needs to do the vblank wait itself. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Fix mmio vs. CS flip race on ILK+Ville Syrjälä2014-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting from ILK, mmio flips also cause a flip done interrupt to be signalled. This means if we first do a set_base and follow it immediately with the CS flip, we might mistake the flip done interrupt caused by the set_base as the flip done interrupt caused by the CS flip. The hardware has a flip counter which increments every time a mmio or CS flip is issued. It basically counts the number of DSPSURF register writes. This means we can sample the counter before we put the CS flip into the ring, and then when we get a flip done interrupt we can check whether the CS flip has actually performed the surface address update, or if the interrupt was caused by a previous but yet unfinished mmio flip. Even with the flip counter we still have a race condition of the CS flip base address update happens after the mmio flip done interrupt was raised but not yet processed by the driver. When the interrupt is eventually processed, the flip counter will already indicate that the CS flip has been executed, but it would not actually complete until the next start of vblank. We can use the DSPSURFLIVE register to check whether the hardware is actually scanning out of the buffer we expect, or if we managed hit this race window. This covers all the cases where the CS flip actually changes the base address. If the base address remains unchanged, we might still complete the CS flip before it has actually completed. But since the address didn't change anyway, the premature flip completion can't result in userspace overwriting data that's still being scanned out. CTG already has the flip counter and DSPSURFLIVE registers, and although the flip done interrupt is still limited to CS flips alone, the code now also checks the flip counter on CTG as well. v2: s/dspsurf/gtt_offset/ (Chris) Testcase: igt/kms_mmio_vs_cs_flip/setcrtc_vs_cs_flip Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73027 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add g4x_ prefix to flip_count_after_eq.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Reset data lanes in encoder .post_disable() hookVille Syrjälä2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Seems like we shouldn't leave the data lane resert deasserted when the port if disabled. So propagate the reset the data lanes in the encoder .post_disable() hook. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Turn off dclkp after the PLL has been disabledVille Syrjälä2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the enable sequence we first enable the dclkp output to the display controller, and then enable the PLL. Do the opposite during the disable sequence. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Move data lane deassert to encoder pre_enableVille Syrjälä2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to pick the correct data lanes based on the port not the pipe, so move the data lane deassert into the encoder .pre_enable() hook from the chv_enable_pll(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Fix CHV PLL state trackingVille Syrjälä2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setup the pipe config dpll state correctly for CHV. Also add a assert_pipe_disabled() to chv_disable_pll(), and program the DPLL_MD registers in chv_enable_pll(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Register port D encoders and connectorsVille Syrjälä2014-05-20
| | | | | | | | | | | | | | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Add cursor pipe offsetsVille Syrjälä2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unsurprisingly the cursor C regiters are also at a weird offset on CHV. Add more pipe offsets to handle them. This also gets rid of most of the differences between the i9xx vs. ivb cursor code. We can unify the remaining code as well, but I'll leave that for another patch. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: s/ironlake_/intel_ for the enable_share_dpll functionDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Besides the fairly useless BUG_ON the logic is completely generic and cane be used on any platform what wants to reuse the shared dpll support code. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Extract intel_prepare_shared_dpllDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the last piece of code which write state to the hardware in the ironalake ->crtc_mode_set callback. I think we could merge this with the pll->enable hook, but otoh the ordering requirements with the ldvs port are really tricky. Doing the FP0/1 writes up-front before we even prepare the lvds port (in the pre_pll_enable hook) like on i9xx seems safest. With this ilk+ platforms are now ready for runtime PM with DPMS. Since hsw/bdw also support runtime pm besides snb we need to first make the haswell code save before we can touch the core code. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Only update shared dpll state when neededDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of every time it isn't active: We only need to do that when the pll is currently unused, i.e. when pll->refcount == 0. For paranoia add a warning for the ibx case where plls have a fixed mapping and hence should always be unused after the call to intel_put_shared_dpll. v2: Simplify control flow and use struct assignment instead of memcpy as suggested by Damien. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Extract vlv_prepare_pllDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this all hw writes are also gone from the ->crtc_mode_set hook on vlv. I wondered whether we should track more of the pll state in the pipe config, but otoh as long as we don't have shared plls that's not really useful - the cross-checking of the port clock should be sufficient. While at it also de-magic some of the pipe checks, this has been irking me since a long time. Whit this vlv is now ready for runtime PM on dpms. If we'd have runtime PM support in general ... Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Extract i9xx_set_pll_dividersDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | These two writes are the very last hw writes from the ->crtc_modeset_callback on pre-gen5 hardware. As usual vlv is a bit different, so this here is just warm-up. Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Shovel hw setup code out of hsw_crtc_mode_setDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Again the same story: This code just transform sw state from the pipe config into hardware state. And again we can't move the pll code, but this time around because the state isn't properly tracked in the pipe config. Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Shovel hw setup code out of ilk_crtc_mode_setDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Again this code just transforms sw state from the pipe config into hardware state, so we can just move it around. Unfortunately again a few forward declarations since intel_display.c is becoming a bit of a mess. Note that both for i9xx and ironlake code the only things remaining in the ->crtc_mode_set hook is now the clock state computation and sharing code. That needs to be moved into the compute config stage so that we can catch impossible configurations earlier. Also note that some of the DPLL hw setup code is still run from within ->crtc_mode_set, namele the pll->mode_set callback. We need to move that first before we can do fancy things like enable runtime PM for dpms off. v2: Make it compile again after the rebase, bisectability issue reported by Wu Fengguang. Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_setDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now this really should be in the pipe config somewhere, but till now it isn't. We can at least move it up a bit next to all the other pll code since intel_dp_set_m_n really doesn't depend upon this. This is just prep work so that moving all the hw frobbing code from ->crtc_mode_set to ->crtc_enable is clean. v2: Do the same for haswell while at it, not just for ivb. Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Shovel hw setup code out of i9xx_crtc_mode_setDaniel Vetter2014-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All these functions simply convert sw state as encoded in the pipe config or primary framebuffer into hardware state. So we can move them all into the crtc enable hook. Unfortunately this means a little bit of duplication between the i9xx and vlv functions, but since we already have highly refactored code I think this is acceptable. Also a pile of forward declarations unfortunately. Note also that the various <platform>_update_pll functions are still called from within the ->crtc_mode_set hook. Mostly they compute the clock state for the pipe config, but unfortunately there are some random register writes interspersed. Those need to be moved out first before we can enable runtime PM for DPMS. Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Don't die in wait_for_pending_flipsDaniel Vetter2014-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can apperently miss them, but breaking the entire driver hampers testing. So bail out after one minute, our customerary "this is a lost cause" timeout. References: https://bugs.freedesktop.org/show_bug.cgi?id=78383 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drivers/gpu/drm/i915/intel_display: coding style fixesRobin Schroer2014-05-19
| | | | | | | | | | | | | | | | | | | | | | | | Fixed several switch statements, curly braces, dereference operators and keywords. Signed-off-by: Robin Schroer <sulamiification@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Move fb pinning into __intel_set_modeDaniel Vetter2014-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our two ->crtc_mode_set callbacks really don't care whether the fb is pinned and set up already or not - all the state computation and handling which originally looked at the framebuffer is already using the indirection through the pipe configuration. Eventually we want to move this up a bit more, but as long as the crtc mode_set callback still exists (and as long as we don't need to pin an entire pile of planes due to atomic modesets) there's not much point in it. So I'll let this be for now. v2: Don't forget about haswell ... Reviewed-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Inline set_base into crtc_mode_setDaniel Vetter2014-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A lot of the code in set_base is uncessary when the crtc is off, so we can get rid of it all. Also, we don't need to call the fbc/psr update functions since the crtc enable/disable hooks do that already. The only things we really need are: - Pin the new framebuffer and potentially unpin the old framebuffer (if the crtc has been on and we only change the configuration). - Update the plane registers. The first step will move out of platform code with the very next patch. v2: Don't forget about haswell ... Reviewed-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Sprinkle intel_edp_psr_update over crtc_enable/disableDaniel Vetter2014-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My plan here is to split up set_base into a prepare step, which does the pinning, and a commit stage, which updates the hw state. Eventually we should be able to move the prepare step at the beginning of any atomic update. For now I only want to move the commit step into the crtc_enable callbacks. As a prep step sprinkle intel_edp_psr_update all over the place so that we don't have to concern ourselves with that in the commit step. v2: Rebase on top of Ville's enable/disable functions for all planes. v3: Rebase more. Reviewed-by: Akash Goel <akash.goel@intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: More cargo-culted locking for intel_update_fbcDaniel Vetter2014-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Just for consistency, this patch won't fix anything really. v2: Rebase over all the recent plane enabling shuffling. Reviewed-by: Akash Goel <akash.goel@intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Make ->update_primary_plane infallibleDaniel Vetter2014-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Way back we've used this to reject framebuffers with unsupported pixel formats. But since the modesetting reorg with the compute config stage we reject those much earlier and just BUG() in this callback. So switch to a void return type. Reviewed-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Stop calling encoder->mode_setDaniel Vetter2014-05-16
| | | | | | | | | | | | | | | | | | | | | All the callbacks are gone now. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Track has_audio in the pipe configDaniel Vetter2014-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Including state readout and cross-checking. This allows us to get rid of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy if the BIOS hasn't set up the audio routing like we want it too. Wrt fastboot and external screens I see a few options: - Don't. - Try to fix up eld, infoframes and audio settings after the fact. But that means some pretty extensive reworking of our code which currently does all this while the pipe/port is still off. I won't bother with converting SDVO over to this because the audio support for SDVO is very lacking: - We don't update the eld. - We don't update the audio state on the sdvo encoder. - We don't check whether the platform can even feed audio to the sdvo encoder. I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi and dp converted and so doing it step-by-step would have required a few intermediate hacks. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: state readout and cross checking for limited_color_rangeDaniel Vetter2014-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least on those platforms which have a simple bit and don't rely on the fully programmable CSC unit to do this. Note that with the current code this includes CHV, but I guess that platform will match BYT. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Track hdmi mode in the pipe configDaniel Vetter2014-05-16
| | | | | | | | | | | | | | | | | | | | | | | | Also add state readout and cross-check support. The only invasive change is wiring up the new flag to the ->set_infoframes callbacks. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Use for_each_crtc() when iterating through the CRTCsDamien Lespiau2014-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch done using the following semantic patch (thanks Daniel for the help!) @@ iterator name list_for_each_entry; iterator name for_each_crtc; struct drm_crtc * crtc; struct drm_device * dev; @@ -list_for_each_entry(crtc,&dev->mode_config.crtc_list, head) { +for_each_crtc(dev,crtc) { ... } Followed by a couple of fixups by hand (that spatch doesn't match the cases where list_for_each_entry() is not followed by a set of '{', '}', but I couldn't figure out a way to leave the '{' out of the iterator match). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Use for_each_intel_crtc() when iterating through intel_crtcsDamien Lespiau2014-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generated using the semantic patch: @@ iterator name list_for_each_entry; iterator name for_each_intel_crtc; struct intel_crtc * crtc; struct drm_device * dev; @@ -list_for_each_entry(crtc,&dev->mode_config.crtc_list,...) { +for_each_intel_crtc(dev,crtc) { ... } Followed by a couple of fixups by hand (that spatch doesn't match the cases where list_for_each_entry() is not followed by a set of '{', '}', but I couldn't figure out a way to leave the '{' out of the iterator match). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Kill vblank waits after pipe enable on gmch platformsVille Syrjälä2014-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pipe might not start to actually run until the port has been enabled (depends on the platform and port type). So don't try to wait for vblank after we enabled the pipe but haven't yet enabled the port. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=77297 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Disable/enable planes as the first/last thing during modeset on ↵Ville Syrjälä2014-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gmch platforms We already moved the plane disable/enable to happen as the first/last thing on every other platforms. Follow suit with gmch platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Frob drm_vblank_on conflict, as usual.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: CHV doesn't have CRT outputVille Syrjälä2014-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No CRT output on CHV, so don't call intel_crt_init(). v2: Don't disable CRT on HAS. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Add DPLL state readout supportVille Syrjälä2014-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add chv_crtc_clock_get() to read out the DPLL settings. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Fix compile due to bikeshedded headers in an earlier patch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Pipe select change for DP and HDMIChon Ming Lee2014-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With additional of pipe C, current 1 bit registers for pipe select for HDMI and DP are no longer able to gather for 3 pipes. As a result, new bits location in the same registers are added. For HDMI, VLV uses bit 30, CHV uses bit 24-25. For DP, VLV uses bit 30, CHV uses bit 16-17. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Add update and enable pll for CherryviewChon Ming Lee2014-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added programming PLL for CHV based on "Application note for 1273 CHV Display phy". v2: -Break the common lane reset into another patch. -Break the clock calculation into another patch. -The changes are based on Ville review. -Rework based on DPIO register define naming convention change. -Break the dpio write into few lines to improve readability. -Correct the udelay during chv_enable_pll. -clean up some magic numbers with some new define. -program the afc recal bit which was missed. v3: Based on Ville review - minor correction of the bit defination - add deassert/propagate data lane reset v4: Corrected the udelay between dclkp enable and pll enable. Minor comment and better way to clear the TX lane reset. v5: Squash in fixup from Rafael Barbalho. [vsyrjala: v6: Polish the defines (Imre)] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: find the best divisor for the target clock v4Chon Ming Lee2014-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the chv clock limit, find the best divisor. The divisor data has been verified with this spreadsheet. P1273_DPLL_Programming Spreadsheet. v2: Rebase the code and change the chv_find_best_dpll based on new standard way to use intel_PLL_is_valid. Besides, clean up some extra variables. v3: Ville suggest better fixed point for m2 calculation. v4: -Add comment for the limit is compute using fast clock. (Ville) -Don't pass the request clock to chv_clock, as the same function will be use clock readout, which doens't have request clock. (Ville) -Add and use DIV_ROUND_CLOSEST_ULL to consistent with other clock calculation. (Ville) -Fix the dp m2 after m2 has stored fixed point. (Ville) Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> [vsyrjala: Avoid div-by-zero in chv_clock()] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Trigger phy common lane resetChon Ming Lee2014-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During cold boot, the display controller needs to deassert the common lane reset. Only do it once during intel_init_dpio for both PHYx2 and PHYx1. Besides, assert the common lane reset when disable pll. This still to be determined whether need to do it by driver. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> [vsyrjala: Don't disable DPIO PLL when using DSI] [vsyrjala: Don't call vlv_disable_pll() by accident on CHV] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Move part of a moved comment back as suggested by Imre since it's valid for both byt and chv.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915/chv: Update Cherryview DPLL changes to support Port D. v2Chon Ming Lee2014-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The additional DPLL registers added to support Port D. Besides, add some new PHY control and status registers based on B-spec. v2: Based on Ville review - Corrected DPIO_PHY_STATUS offset and name. - Rebase based on upstream change after introduce enum dpio_phy and enum dpio_channel. v3: Rebased on top of Antti's 3-pipe prep patch. Note that the new offsets for the DPLL registers aren't in place yet, so this introduces a slight regression. But since 3 pipe support isn't fully enabled yet anyaway in -internal this shouldn't matter too much. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-13 15:00:35 -0400