summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_drv.h
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/i915: Remove the now obsolete infoframe definitionsDamien Lespiau2013-08-081-61/+0
| | | | | | | | | All the HDMI infoframe code has been ported to use video/hdmi.c, so it's time to say bye bye to this code. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/hdmi: Change the write_infoframe vfunc to take a buffer and a typeDamien Lespiau2013-08-081-1/+3
| | | | | | | | | | | | | | | First step in the move to the shared infoframe infrastructure, let's move the different infoframe helpers and the write_infoframe() vfunc to a type (enum hdmi_infoframe_type) and a buffer + len instead of using our struct dip_infoframe. v2: constify the infoframe pointer and don't mix signs (Ville Syrjälä) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Export intel_framebuffer_finiChris Wilson2013-08-061-0/+1
| | | | | | | | | | | | Rather than open-code the teardown of a framebuffer, export the routine from intel_display.c. This then make intel_fbdev symmetric in its use of the common intel_framebuffer routines to initialise and clean up the struct intel_framebuffer. (And new features need only be added in one location!) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add scaled paramater to update_sprite_watermarks()Ville Syrjälä2013-08-051-3/+4
| | | | | | | | | | For calculating watermarks we want to know whether sprites are scaled. Pass that information to update_sprite_watermarks() so that eventually we may do some watermark pre-computing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: clean up crtc timings computationDaniel Vetter2013-08-041-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the old days of the crtc helpers we've only had the encoder and crtc ->mode_fixup callbacks. So when the lvds connector wanted to adjust the crtc timings it had to set a driver-private mode flag to tell the crtc mode fixup code to not overwrite them with the generic ones. When converting things to the new infrastructure I've kept the entire logic and only moved the flag to pipe_config->timings_set. But this logic is pretty tricky and already caused regressions: commit 21d8a4756af5fdf4a42e79a77cf3b6f52678d443 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 12 08:07:30 2013 +0200 drm/i915: fix pfit regression for non-autoscaled resolutions So take advantage of the flexibility our own modeset infrastructure affords us and prefill default crtc timings. This allows us to rip out ->timings_set. Note that we overwrite things again when retrying the pipe config computation due to bandwidth constraints to avoid bogus crtc timings if the encoder only does relative adjustments (which is how the pfit code works). Only a theoretical concern though since platforms where we retry (pch-split platforms) do not need adjustements (since only the old gmch pfit needs that). But let's better be safe than sorry. Since we now initialize the crtc timings before calling the encoder->compute_config functions the crtc initialization in the gmch pfit code is now redudant and so can be removed. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add a paragraph to the commit message to explain why we can ditch the crtc timings initialization call from the gmch pfit code, to answer a question from Rodrigo's review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Colocate all GT access routines in the same fileChris Wilson2013-07-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Currently, the register access code is split between i915_drv.c and intel_pm.c. It only bares a superficial resemblance to the reset of the powermanagement code, so move it all into its own file. This is to ease further patches to enforce serialised register access. v2: Scan for random abuse of I915_WRITE_NOTRACE v3: Take the opportunity to rename the GT functions as uncore. Uncore is the term used by the hardware design (and bspec) for all functions outside of the GPU (and CPU) cores in what is also known as the System Agent. v4: Rebase onto SNB rc6 fixes Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Wrestle patch into applying and inline intel_uncore_early_sanitize (plus move the old comment to the new function). Also keep the _santize postfix for intel_uncore_sanitize.] [danvet: Squash in fixup spotted by Chris on irc: We need to call intel_pm_init before intel_uncore_sanitize since the later will call cancel_work on the delayed rps setup work the former initializes.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge commit 'Merge branch 'drm-fixes' of ↵Daniel Vetter2013-07-251-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~airlied/linux' This backmerges Linus' merge commit of the latest drm-fixes pull: commit 549f3a1218ba18fcde11ef0e22b07e6365645788 Merge: 42577ca 058ca4a Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Jul 23 15:47:08 2013 -0700 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux We've accrued a few too many conflicts, but the real reason is that I want to merge the 100% solution for Haswell concurrent registers writes into drm-intel-next. But that depends upon the 90% bandaid merged into -fixes: commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 19 20:36:51 2013 +0100 drm/i915: Serialize almost all register access Also, we can roll up on accrued conflicts. Usually I'd backmerge a tagged -rc, but I want to get this done before heading off to vacations next week ;-) Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_gem.c v2: For added hilarity we have a init sequence conflict around the gt_lock, so need to move that one, too. Spotted by Jani Nikula. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Preserve the DDI_A_4_LANES bit from the biosStéphane Marchesin2013-07-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes on eDP. This fixes eDP on hsw with > 2 lanes. Also s/port_reversal/saved_port_bits/ since the current name is confusing. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add functions to disable and restore LCPLLPaulo Zanoni2013-07-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For now there are no callers, but these functions are going to be needed for the code that allows Package C8+. Other future features may also require this code. Also merge the commit which introduced assert_can_disable_lcpll and had the following commit message: Most of the hardware needs to be disabled before LCPLL is disabled, so let's add a function to assert some of items listed in the "Display Sequences for LCPLL disabling" documentation. The idea is that hsw_disable_lcpll should not disable the hardware, the callers need to take care of calling hsw_disable_lcpll only once everything is already disabled. v2: - Rebase. - Fix D_COMP wait timeout. v3: - Use wait_for_atomic_use (Ben) - Remove/add a useless/needed POSTING_READ (Ben) - Early return in case LCPLL is already restored (Ben) - Add ndelay(100) (Ben) v4: - Merge the commit that added assert_can_disable_lcpll (Ben) - Add interrupt assertions (Ben) Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix compile fail since there's no HAS_LP_PCH yet.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add update function to disable/enable-back PSRRodrigo Vivi2013-07-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Required function to disable PSR when going to console mode. But also can be used whenever PSR mode entry conditions changed. v2: Add it before PSR Hook. Update function not really been called yet. v3: Fix coding style detected by checkpatch by Paulo Zanoni. v4: do_enable must be static as Paulo noticed. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Enable/Disable PSRRodrigo Vivi2013-07-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding Enable and Disable PSR functionalities. This includes setting the PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config, enabling PSR in the sink via DPCD register and finally enabling PSR on the host. This patch is based on initial PSR code by Sateesh Kavuri and Kumar Shobhit but in a different implementation. v2: * moved functions around and changed its names. * removed VSC DIP unset from disable. * remove FBC wa. * don't mask LSPS anymore. * incorporate new crtc usage after a rebase. v3: Make a clear separation between Sink (Panel) and Source (HW) enabling. v4: Fix identation and other style issues raised by checkpatch (by Paulo). v5: Changes according to Paulo's review: static on write_vsc; avoid using dp_to_dev when already calling dp_to_dig_port; remove unecessary TP default time setting; remove unecessary interrupts disabling; remove unecessary wait_for_vblank when disabling psr; v6: remove unecessary wait_for_vblank when writing vsc; v7: adding setup once function to avoid unnecessarily write to vsc and set debug_ctl every time we enable or disable psr. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Credits-by: Sateesh Kavuri <sateesh.kavuri@intel.com> Credits-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> [danvet: Apply Paulo's suggestion for unconditionally clearing the control register when writing the DIP.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Read the EDP DPCD and PSR CapabilityShobhit Kumar2013-07-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | v2: reuse of just created is_edp_psr and put it at right place. v3: move is_edp_psr above intel_edp_disable v4: remove parentheses. Noticed by Paulo. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Move fbc members out of lineBen Widawsky2013-07-011-7/+0
| | | | | | | | | | | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Resolve conflict with Damien's FBC_CHIP_DEFAULT no fbc reason.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: asserts for lvds pre_enableDaniel Vetter2013-07-011-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lots of bangin my head against the wall^UExperiments have shown that we really need to enable the lvds port before we enable plls. Strangely that seems to include the fdi rx pll on the pch. Note that the pch pll assert can fire since the lvds port has it's own special clock source settings in the DPLL register, which means it will never have a shared dpll (since there's only one LVDS port). Anyway, encode this new evidence with a few nice WARNs. v2: Incorporate review comments from Imre. - Explain why lvds can't have a shared dpll. - Update the WARN output. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Make intel_enable_fbc() staticDamien Lespiau2013-07-011-1/+0
|/ | | | | | | This function has no user outside of intel_pm.c. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: correct intel_dp_get_config() function for DevCPTXiong Zhang2013-07-011-1/+2
| | | | | | | | | | | | | | | | On DevCPT, the control register for Transcoder DP Sync Polarity is TRANS_DP_CTL, not DP_CTL. Without this patch, Many call trace occur on CPT machine with DP monitor. The call trace is like: *ERROR* mismatch in adjusted_mode.flags(expected X,found X) v2: use intel-crtc to simple patch, suggested by Daniel. Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> [danvet: Extend the encoder->get_config comment to specify that we now also depend upon intel_encoder->base.crtc being correct. Also bikeshed s/intel_crtc/crtc/.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65287 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: propagate errors from intel_dp_init_connectorPaulo Zanoni2013-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | In case we detect a "ghost eDP", intel_edp_init_connector frees both the connector and encoder and then returns. On Haswell, intel_ddi_init then tries to use the freed encoder on the HDMI initialization path since the following commit: commit 21a8e6a4853b2ed39fa4c5188a710f2cf1b92026 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 10 23:28:35 2013 +0200 drm/i915: don't setup hdmi for port D edp in ddi_init So now on intel_ddi_init we check for the "ghost eDP" case and return without trying to initialize HDMI. This way we won't try to read the freed "intel_encoder" struct in the next "if" statement. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: stop killing pfit on i9xxDaniel Vetter2013-06-181-1/+1
| | | | | | | | | | | | | | | Nowadays (i.e. with Valleyview) we also have edp on non-PCH_SPLIT platforms, so just checking for LVDS is not good enough. Secondly we have full pfit pipe config tracking, so we'll correctly disable the pfit as part of the initial modeset. For fastboot we need a bit of work here to correctly kill unsupported configs (if e.g. the pfit is used on anything else than the built-in panel). But since that's not yet supported we don't need to worry. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: hw state readout and cross-checking for shared dpllsDaniel Vetter2013-06-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Just the plumbing, all the modeset and enable code has not yet been switched over to use the new state. It seems to be decently broken anyway, at least wrt to handling of the special pixel mutliplier enabling sequence. Follow-up patches will clean up that mess. Another missing piece is more careful handling (and fixup) of the fp1 alternate divisor state. The BIOS most likely doesn't bother to program that one to what we expect. So we need to be more careful with comparing that state, both for cross checking but also when checking for dpll sharing when acquiring shared dpll. Otherwise fastboot will deny a few shared dpll configurations which would otherwise work. v2: We need to memcpy the pipe config dpll hw state into the pll, for otherwise the cross-check code will get angry. v3: Don't forget to read the pch pll state in the crtc get_pipe_config function for ibx/ilk platforms. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: disable sdvo pixel multiplier cross-check for HAS_PCH_SPLITDaniel Vetter2013-06-121-1/+2
| | | | | | | | | | | | | | | | | | We don't (yet) have proper pixel multiplier readout support on pch split platforms, so the cross check will naturally fail. v2: Fix spelling in the comment, spotted by Ville. v3: Since the ordering constraint is pretty tricky between the crtc get_pipe_config callback and the encoder->get_config callback add a few comments about it. Prompted by a discussion with Chris Wilson on irc about why this does work anywhere else than on i915g/gm. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move shared_dpll into the pipe configDaniel Vetter2013-06-101-2/+3
| | | | | | | | | | | | | | | | | | | | | With the big sed-job prep work done this is now really simple. With the exception that we only assign the right shared dpll id in the ->mode_set callback but also depend upon the old one still being around. Until that mess is fixed up we need to jump through a few hoops to keep the old value save. v2: Kill the funny whitespace spotted by Chris. v3: Move the shared_dpll pipe config fixup into this patch as noticed by Ville. Also unconditionally set the shared_dpll with the current one, since otherwise we won't handle direct pch port -> cpu edp transitions correctly. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: switch crtc->shared_dpll from a pointer to an enumDaniel Vetter2013-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dealing with discrete enum values is simpler for hw state readout and pipe config computations than pointers - having neat names instead of chasing pointers should look better in the code. This isn't a that good reason for pch plls, but on haswell we actually have 3 different types of plls: WRPLL, SPLL and the DP clocks. Having explicit names should help there. Since this also adds the intel_crtc_to_shared_dpll helper to further abstract away the crtc -> dpll relationship this will also help to make the next patch simpler, which moves the shared dpll into the pipe configuration. Also note that for uniformity we have two special dpll ids: NONE for pipes which need a shared pll but don't have one (yet) and private for when there's a non-shared pll (e.g. per-pipe or per-port pll). I've thought whether we should also add a 2nd enum for the type of the pll we want (for really generic pll selection code) but thrown that idea out again - likely there's too much platform craziness going on to be able to share the pll selection logic much. Since this touched all the shared_pll functions a bit I've also done an s/intel_crtc/crtc/ replacement on a few of them. v2: Kill DPLL_ID_NONE. It's probably better to call it DPLL_ID_INVALID and use it to check that the compute config stage assigns a dpll to every pipe. But since that code isn't ready yet until we move the dpll selection out of the ->mode_set callback, there's no use for it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: s/pch_pll/shared_dpll/Daniel Vetter2013-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | For fastboot we need some support to read out the sharing state of plls, at least for platforms where they can be shared (or freely assigned at least). Now for ivb we already have pretty extensive infrastructure for tracking pch plls, and it took us an aweful lot of tries to get that remotely right. Note that hsw could also share plls, but even now they're already freely assignable. So we need this on more than just ivb. So on top of the usual fastboot fun pll sharing seems to be an additional step up in fragility. Hence a common infrastructure for all shared/freely assignable display plls seems to be in order. The plan is to have a bit of dpll hw state readout code, which can be used individually, but also to fill in the pipe config. The hw state cross check code will then use that information to make sure that after every modeset every pipe still is connected to a pll which still has the correct configuration - a lot of the pch pll sharing bugs where due to incorrect sharing. We start this endeavour with a simple s/pch_pll/shared_dpll/ rename job. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Track when we dirty the scanout with render commandsChris Wilson2013-06-071-1/+2
| | | | | | | | | This is required for tracking render damage for use with FBC and will be used in subsequent patches. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: pipe config quirk infrastructure plus sdvo mode.flags fixDaniel Vetter2013-06-061-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For various reasons the hw state readout might not be able to faithfully match the hw state: - broken hw (like the case which motivated this patch here where the sdvo encoder does not implemented mandatory functionality correctly). - platforms which are not supported fully with the pipe config infrastructure - if our code doesn't support a given hw configuration natively, e.g. special restrictions on the per-pipe panel fitters when they're used in high-quality scaling modes. In all these cases both fastboot and the hw state cross checker need to be aware of these cases and act accordingly. To be able to do this add a new quirk flag to the pipe config structure. The specific case at hand is an sdvo encoder which doesn't implement the get_timings function, so adjusted_mode flags will be wrong. The strange thing though is that the encoder _does_ work, even though it doesn't implement any of the timings functions (so neither get nor set, neither for input nor output timings). Not that non-compliant sdvo encoder are any surprise at all ... v2: - Don't read random garbage from the dtd if the get_timings call failed (suggested by Chris). - Still check the interlaced flag, that's read out from someplace else. We want maximal paranoia, after all. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* i915/drm: Add private api for power well usageWang Xingchao2013-06-061-0/+4
| | | | | | | | | | | | | Haswell Display audio depends on power well in graphic side, it should request power well before use it and release power well after use. I915 will not shutdown power well if it detects audio is using. This patch protects display audio crash for Intel Haswell C3 stepping board. Signed-off-by: Wang Xingchao <xingchao.wang@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Disable/restore all sprite planes around modesetVille Syrjälä2013-06-061-0/+1
| | | | | | | | | | | | | | | | | Disable/restore sprite planes around mode-set just like we do for the primary and cursor planes. Now that we have working sprite clipping, this actually works quite decently. Previosuly we didn't even bother to disable sprites when changing mode, which could lead to a corrupted sprite appearing on the screen after a modeset (at least on my IVB). Not sure if all hardware generations would be so forgiving when enabled sprites end up outside the pipe dimensons. v2: Disable rather than enable sprites in ironlake_crtc_disable() 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: consolidate and tighten encoder cloning checksDaniel Vetter2013-06-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only lvds/tv did actually check for cloning or not, but many more places should. Notices because my ivb tried to enable both cpu edp and vga on the first crtc - the resulting confusion between has_pch_encoder, has_dp_encoder but not actually being a pch dp encoder resulting in hilarity (hitting a BUG). We _really_ need an igt to random-walk our modeset space more exhaustively. The bug seems to have been exposed due to a race in the hw load detection support for VGA: Right after a hotplug VGA was still detected as connected, but obviously reading the EDID wasn't possible any more. Hence why restarting X a bit later fixed things. Due to the 1024x756 fallback resolution suddenly more outputs had the same resolution. On top of that SNA was confused with the possible_clones mask, trying to clone outputs which cannot be cloned. That bug is now fixed with commit fc1e0702b25e647cb423851fb7228989fec28bd6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed May 29 11:25:28 2013 +0100 sna: fixup up possible_clones kms->X impedance mismatch v2: Kill intel_encoder_check_is_cloned, spotted by Paulo. v3: Drop the now unused pipe param. v4: Kill the stray printk Chris spotted. v5: Elaborate on how the bug in userspace happened and why it was racy to reproduce. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: store adjusted dotclock in adjusted_mode->clockDaniel Vetter2013-06-041-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... not the port clock. This allows us to kill the funny semantics around pixel_target_clock. Since the dpll code still needs the real port clock, add a new port_clock field to the pipe configuration. Handling the default case for that one is a bit tricky, since encoders might not consistently overwrite it when retrying the crtc/encoder bw arbitrage step in the compute config stage. Hence we need to always clear port_clock and update it again if the encoder hasn't put in something more specific. This can't be done in one step since the encoder might want to adjust the mode first. I was a bit on the fence whether I should subsume the pixel multiplier handling into the port_clock, too. But then I decided against this since it's on an abstract level still the dotclock of the adjusted mode, and only our hw makes it a bit special due to the separate pixel mulitplier setting (which requires that the dpll runs at the non-multiplied dotclock). So after this patch the adjusted_mode accurately describes the mode we feed into the port, after the panel fitter and pixel multiplier (or line doubling, if we ever bother with that) have done their job. Since the fdi link is between the pfit and the pixel multiplier steps we need to be careful with calculating the fdi link config. v2: Fix up ilk cpu pll handling. v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config to make it clearer that we transmit the adjusted_mode without the pixel multiplier taken into account. The old code multiplied the the available link bw with the pixel multiplier, which results in the same fdi configuration, but is much more confusing. v4: Rebase on top of Imre's is_cpu_edp removal. v5: Rebase on top of Paulo's haswell watermark fixes, which introduce a new place which looked at the pixel_clock and so needed conversion. v6: Split out prep patches as requested by Paulo Zanoni. Also rebase on top of the fdi dotclock handling fix in the fdi lanes/bw computation code. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: implement IPS featurePaulo Zanoni2013-05-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Intermediate Pixel Storage is a feature that should reduce the number of times the display engine wakes up memory to read pixels, so it should allow deeper PC states. IPS can only be enabled on ULT pipe A with 8:8:8 pipe pixel formats. With eDP 1920x1080 and correct watermarks but without FBC this moves my PC7 residency from 2.5% to around 38%. v2: - It's tied to pipe A, not port A - Add pipe_config support (Chris) - Add some assertions (Chris) - Rebase against latest dinq v3: - Don't ever set ips_enabled to false (Daniel) - Only check for ips_enabled at hsw_disable_ips (Daniel) v4: - Add hsw_compute_ips_config (Daniel) - Use the new dump_pipe_config (Daniel) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add haswell_update_sprite_wmPaulo Zanoni2013-05-311-0/+12
| | | | | | | | | | | | | | | | | | | On Haswell, whenever we change the sprites we need to completely recalculate all the watermarks, because the sprites are one of the parameters to the LP watermarks, so a change on the sprites may trigger a change on which LP levels are enabled. So on this commit we store all the parameters we need to store for proper recalculation of the Haswell WMs and then call haswell_update_wm. Notice that for now our haswell_update_wm function is not really using these parameters we're storing, but on the next commits we'll use these parameters. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add "enable" argument to intel_update_sprite_watermarksPaulo Zanoni2013-05-311-1/+1
| | | | | | | | | | | | | | | | | Because we want to call it from the "sprite disable" paths, since on Haswell we need to update the sprite watermarks when we disable sprites. For now, all this patch does is to add the "enable" argument and call intel_update_sprite_watermarks from inside ivb_disable_plane. This shouldn't change how the code behaves because on sandybridge_update_sprite_wm we just ignore the "!enable" case. The patches that implement Haswell watermarks will make use of the changes introduced by this patch. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: group sideband register accessors to a new fileJani Nikula2013-05-231-4/+0
| | | | | | | | | | | Group both the HSW/LPT SBI interface and VLV IOSF sideband register accessor functions into a new file. No functional changes. v2: also move intel_sbi_{read,write} (Daniel) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove intel_update_linetime_watermarksPaulo Zanoni2013-05-211-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | The spec says the linetime watermarks must be programmed before enabling any display low power watermarks, but we're currently updating the linetime watermarks after we call intel_update_watermarks (and only at crtc_mode_set, not at crtc_{enable,disable}). So IMHO the best way guarantee the linetime watermarks will be updated before the low power watermarks is inside the update_wm function, because it's the function that enables low power watermarks. And since Haswell is the only platform that has linetime watermarks, let's completely kill the "intel_update_linetime_watermarks" abstraction and just use the intel_update_watermarks abstraction by creating haswell_update_wm. For now haswell_update_wm is still calling sandybridge_update_wm, but in the future I plan to implement a function specific to Haswell. v2: - Rename patch - Disable LP watermarks before changing linetime WMs (Chris) - Add a comment explaining that this is just temporary code. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add encoder get_config function v5Jesse Barnes2013-05-211-0/+4
| | | | | | | | | | | | | | | | | | | | | We can use this for fetching encoder specific pipe_config state, like mode flags, adjusted clock, etc. Just used for mode flags atm, so we can check the pipe config state at mode set time. v2: get_config when checking hw state too v3: fix DVO and LVDS mode flags (Ville) get SDVO DTD for flag fetch (Ville) v4: use input timings (Ville) correct command used (Ville) remove gen4 check (Ville) v5: get DDI flag config too Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4) Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.10-rc2' into drm-intel-next-queuedDaniel Vetter2013-05-211-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linux 3.10-rc2 since the various (rather trivial) conflicts grew a bit out of hand. intel_dp.c has the only real functional conflict since the logic changed while dev_priv->edp.bpp was moved around. Also squash in a whitespace fixup from Ben Widawsky for i915_gem_gtt.c, git seems to do something pretty strange in there (which I don't fully understand tbh). Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: hsw: fix link training for eDP on port-AImre Deak2013-05-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to BSpec the link training sequence for eDP on HSW port-A should be as follows: 1. link training: clock recovery 2. link training: equalization 3. link training: set idle transmission mode 4. display pipe enable 5. link training: disable (set normal mode) Contrary to this at the moment we don't do step 3. and we do step 5. before step 4. Fix this by setting idle transmission mode for eDP at the end of intel_dp_complete_link_train and adding a new intel_dp_stop_link_training function to disable link training. With these changes we'll end up with the following functions corresponding to the above steps: intel_dp_start_link_train -> step 1. intel_dp_complete_link_train -> step 2., step 3. intel_dp_stop_link_train -> step 5. For port-A we'll call intel_dp_stop_link_train only after enabling the pipe, for everything else we'll call it right after intel_dp_complete_link_train to preserve the current behavior. Tested on HSW/HSW-ULT. In v2: - Due to a HW issue we must set idle transmission mode for port-A too before enabling the pipe. Thanks for Arthur Runyan for explaining this. - Update the patch subject to make it clear that it's an eDP fix, DP is not affected. v3: - rename intel_dp_link_train() to intel_dp_set_link_train(), use 'val' instead 'l' as var name. (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: make SDVO TV-out work for multifunction devicesDaniel Vetter2013-05-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | We need to track this correctly. While at it shovel the boolean to track whether the sdvo is in tv mode or not into pipe_config. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997 Tested-by: Pierre Assal <pierre.assal@verint.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63609 Tested-by: cancan,feng <cancan.feng@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: remove is_pch_edp() helpers and state variableImre Deak2013-05-101-2/+0
| | | | | | | | | | | | | | There are no more users for these, so remove them. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: use enc_to_intel_dp() instead of opencoding the sameImre Deak2013-05-101-7/+5
| | | | | | | | | | Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: HSW: allow PCH clock gating for suspendImre Deak2013-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | For the device to enter D3 we should enable PCH clock gating. v2: - use HAS_PCH_LPT instead of IS_HASWELL (Ville, Paolo) - rename lpt_allow_clock_gating to lpt_suspend_hw (Paolo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add intel_display_power_enabledPaulo Zanoni2013-05-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should replace intel_using_power_well. The idea is that we're adding the requested power domain as an argument, so this might enable the code to look less platform-specific and also allows us to easily add new domains in case we need. v2: Add more domains to enum intel_display_power_domain v3: Even more domains requested Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: make intel_cpt_verify_modeset staticDaniel Vetter2013-05-061-1/+0
| | | | | | | | | | | | | | | | Only one caller. Also drop the intel_ prefix as is now customary for platform specific and static functions. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: make set_m_n functions staticDaniel Vetter2013-05-061-4/+0
| | | | | | | | | | | | | | | | | | | | This is possible thanks to moving the m/n stuff into pipe_config. Unfortunately we need to move them a bit to avoid forward declarations. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move lvds_border_bits to pipe_configDaniel Vetter2013-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pipe_config is the new dev_priv! More seriously, this is actually better since a pipe_config can be thrown away if the modeset compute config stage fails. Whereas any state stored in dev_prive needs to be painstakingly restored, since otherwise a dpms off/on will wreak massive havoc. Yes, that even applies to state only used in ->mode_set callbacks, since we need to call those even for dpms on when the Haswell power well cleared everything out. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: implement fdi auto-ditheringDaniel Vetter2013-04-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit into this, among them the default 1080p mode. The solution is to dither down the pipe a bit so that everything fits, which this patch implements. But ports compute their state under the assumption that the bpp they pick will be the one selected, e.g. the display port bw computations won't work otherwise. Now we could adjust our code to again up-dither to the computed DP link parameters, but that's pointless. So instead when the pipe needs to adjust parameters we need to retry the pipe_config computation at the encoder stage. Furthermore we need to inform encoders that they should not increase bandwidth requirements if possible. This is required for the hdmi code, which prefers the pipe to up-dither to either of the two possible hdmi bpc values. LVDS has a similar requirement, although that's probably only theoretical in nature: It's unlikely that we'll ever see an 8bpc high-res lvds panel (which is required to hit the 2 fdi lane limit). eDP is the only thing which could increase the pipe_bpp setting again, even when in the retry-loop. This could hit the WARN. Two reasons for not bothering: - On many eDP panels we'll get a black screen if the bpp settings don't match vbt. So failing the modeset is the right thing to do. But since that also means it's the only way to light up the panel, it should work. So we shouldn't be able to hit this WARN. - There are still opens around the eDP panel handling, and maybe we need additional tricks. Before that happens it's imo no use trying to be too clever. Worst case we just need to kill that WARN or maybe fail the compute config stage if the eDP connector can't get the bpp setting it wants. And since this can only happen with an fdi link in between and so for pch eDP panels it's rather unlikely to blow up, if ever. v2: Rebased on top of a bikeshed from Paulo. v3: Improve commit message around eDP handling with the stuff things with Imre. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: split up fdi_set_m_n into computation and hw setupDaniel Vetter2013-04-291-1/+2
| | | | | | | | | | | | | | | | | | | | And also move the computed m_n values into the pipe_config. This is a prep step to move the fdi state computation completely into the prepare phase of the modeset sequence. Which will allow us to handle fdi link bw constraints in a better way. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move intel_crtc->fdi_lanes to pipe_configDaniel Vetter2013-04-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | We need this for two reasons: - Correct handling of shared fdi lanes on ivb with fastboot. - Handling fdi link bw limits when we only have two fdi lanes by dithering down a bit. Just search&replace in this patch, no functional change at all. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move PCH pfit controls into pipe_configJesse Barnes2013-04-251-5/+13
| | | | | | | | | | | | | | | | And put the pfit stuff into substructs while we're at it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: factor out GMCH panel fitting code and use for eDP v3Jesse Barnes2013-04-251-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gets the panel fitter working on eDP on VLV, and should also apply to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one panel as eDP anyway). A few cleanups are still possible on top of this, for example the LVDS border control could be placed in the LVDS encoder structure and updated based on the result of the panel fitter calculation. Multi-pipe fitting isn't handled correctly either if we ever get a config that wants to try the panel fitter on more than one output at a time. v2: use pipe_config for storing pfit values (Daniel) add i9xx_pfit_enable function for use by 9xx and VLV (Daniel) v3: fixup conflicts and lvds_dither check Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: fix up botched conflict resolution from Jesse: - border = LVDS_BORDER_ENABLE was lost for CENTER scaling - comment about gen2/3 panel fitter scaling was lost - dev_priv->lvds_dither reintroduced.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud