This reverts commit 6e1b4fdad5.
This is part of a revert due to a userspace breakage, better explained in the revert of 1a1a4cbf4906a13c0c377f708df5d94168e7b582.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Detangle the additional state of whether or not the hw has the pfit
enabled from whether it has zero size. This allows us to cleanly
distinguish in the code when we expect the pfit to be enabled (for
Haswell pc8), and when the BIOS is confused and needs sanitizing.
Reported-by: shui yanwei <yangweix.shui@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68251
Tested-by: shui yanwei <yangweix.shui@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When transitioning away from vgacon the system tries to save the
current contents of the VGA memory, so that it can be cleanly handed
off to fbcon (or whatever comes afterwards).
The recent change
commit 81b5c7bc8d
Author: Alex Williamson <alex.williamson@redhat.com>
Date: Wed Aug 28 09:39:08 2013 -0600
i915: Update VGA arbiter support for newer devices
caused i915 to disable VGA memory decode for the IGD when i915 is
initializing. Unfortunately that happens before the vgacon->fbcon
handoff so vgacon_save_screen() will read out all ones from the
VGA memory.
After the handoff fbcon will inherit the bogus state from vgacon,
and pre-fills the fb with matching contents. The end result is
a white rectangle in the top left corner of the screen, the size
of which matches the now inactive VGA console.
To remedy the situation delay the disabling of VGA memory until
the vgacon->fbcon handoff has happened.
Also rename i915_enable_vga to i915_enable_vga_mem to make
the relationship between these functions clearer.
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode
only partially. Notably it forgot to copy over the sync flags. The LVDS code however programmed the hardware with the sync flags from fixed mode, and then later the pipe config comparison obviously failed as we
filled out the adjusted_mode in get_config from the real registers.
Just call drm_mode_copy() in intel_fixed_panel_mode() to copy over the
whole thing, and then just use adjusted_mode in the LVDS code to figure
out which sync settings the hardware needs.
Also constify the fixed_mode argument to intel_fixed_panel_mode().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch allows PC8+ states on Haswell. These states can only be
reached when all the display outputs are disabled, and they allow some
more power savings.
The fact that the graphics device is allowing PC8+ doesn't mean that
the machine will actually enter PC8+: all the other devices also need
to allow PC8+.
For now this option is disabled by default. You need i915.allow_pc8=1
if you want it.
This patch adds a big comment inside i915_drv.h explaining how it
works and how it tracks things. Read it.
v2: (this is not really v2, many previous versions were already sent,
but they had different names)
- Use the new functions to enable/disable GTIMR and GEN6_PMIMR
- Rename almost all variables and functions to names suggested by
Chris
- More WARNs on the IRQ handling code
- Also disable PC8 when there's GPU work to do (thanks to Ben for
the help on this), so apps can run caster
- Enable PC8 on a delayed work function that is delayed for 5
seconds. This makes sure we only enable PC8+ if we're really
idle
- Make sure we're not in PC8+ when suspending
v3: - WARN if IRQs are disabled on __wait_seqno
- Replace some DRM_ERRORs with WARNs
- Fix calls to restore GT and PM interrupts
- Use intel_mark_busy instead of intel_ring_advance to disable PC8
v4: - Use the force_wake, Luke!
v5: - Remove the "IIR is not zero" WARNs
- Move the force_wake chunk to its own patch
- Only restore what's missing from RC6, not everything
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>
Just like we're doing with the other IMR changes.
One of the functional changes is that not every caller was doing the
POSTING_READ.
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>
Just like the functions that touch DEIMR and SDEIMR, but for GTIMR.
The new functions contain a POSTING_READ(GTIMR) which was not present
at the 2 callers inside i915_irq.c.
The implementation is based on ibx_display_interrupt_update.
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>
And also fix a small typo in the intel_encoder_dpms() comment.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're going to want to know the crtc in the watermark code to avoid
doing more work than we have to. We should also pass the plane we're
disabling so that we know where to stick our watermark parameters
without having to go look the plane up.
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>
We're going to want to know which CRTC we're dealing with, so pass it
down to the update/disable_plane hooks.
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>
Give a name to the plane watermark related data we have currently
stored under intel_plane->wm.
We also observe that this data is more or less the same that we have
in the hsw_pipe_wm_parameters structure, so use it there as well.
v2: Make pahole happier
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
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>
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>
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>
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 21d8a4756a
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>
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>
This backmerges Linus' merge commit of the latest drm-fixes pull:
commit 549f3a1218
Merge: 42577ca058ca4a
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 a7cd1b8fea
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 21a8e6a485
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
... 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>
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>
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>
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>
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>
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>
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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRmpexAAoJEHm+PkMAQRiGrRIH/1uWFW38RvaCV/PXm/ia6Z+x
BfBJfBIvPxGwb4n7aQNQlhU25xkfrPZ6szO4WiBH5/KPH3xYi2I2OZ1AzffkYqMF
BWkPmsPK6EsTdp16zsi6JtH2aXArG4SpYA7ZamPvDkmfigHuiZg7GlL/9eHTRPNV
P7Q8JToOrcnP8RoGgNj0uFiQeQbc62Kmoq7WuPtUhVlpQCCCknXgOJiYgz9w6Xe9
/i79YFS8WRrzAquExT1NbIOh4ZMqB9MvuroaVWy8JDDLUyz7QUvOCe3tCDNguwgi
FdWvU6nfkdQq5SLaWCWXDE9Rp/pL1MvfBn9vCOwFcp42aw0aQ0PgJVIXvsqufd0=
=jgDI
-----END PGP SIGNATURE-----
Merge tag 'v3.10-rc2' into drm-intel-next-queued
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>
