This will be changed once the gen8 code is fully implemented.
v2: Use ENOSYS instead of ENXIO as suggested by Chris.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Somehow this got missed or dropped during development. The simulator
does not use forcewake, so it's entirely possible it never worked
correctly. After the mmio rework, this will end up in an OOPs, and the
system will not boot.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Use IS_GEN8 instead of IS_BROADWELL.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current
DPIO register definition doesn't have a structure way to break them
down. As a result it is not easy to match the PHY/PLL registers with the
configdb document. Rename those registers based on the configdb for easy
cross references, and without the need to check the offset in the header
file.
New format is as following.
<platform name>_<DPIO component><optional lane #>_DW<dword # in the
doc>_<optional channel #>
For example,
VLV_PCS_DW0 - Group access to PCS for lane 0 to 3 for PCS DWORD 0.
VLV_PCS01_DW0_CH0 - PCS access to lane 0/1, channel 0 for PCS DWORD 0.
Another example is
VLV_TX_DW0 - Group access to TX lane 0 to 3 for TX DWORD 0
VLV_TX0_DW0 - Refer to TX Lane 0 access only for TX DWORD 0.
There is no functional change on this patch.
v2: Rebase based on previous patch change.
v3: There may be configdb different version that document the start DW
differently. Add a comment to clarify. Fix up some mismatch start DW
for second PLL block. (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bit a bit -fixes pull request in the merge window than usual dua to two
feauture-y things:
- Display CRCs are now enabled on all platforms, including the odd DP case
on gm45/vlv. Since this is a testing-only feature it should ever hurt,
but I figured it'll help with regression-testing -fixes. So I left it
in and didn't postpone it to 3.14.
- Display power well refactoring from Imre. Would have caused major pain
conflict with the bdw stage 1 patches if I'd postpone this to -next.
It's only an relatively small interface rework, so shouldn't cause pain.
It's also been in my tree since almost 3 weeks already.
That accounts for about two thirds of the pull, otherwise just bugfixes:
- vlv backlight fix from Jesse/Jani
- vlv vblank timestamp fix from Jesse
- improved edp detection through vbt from Ville (fixes a vlv issue)
- eDP vdd fix from Paulo
- fixes for dvo lvds on i830M
- a few smaller things all over
Note: This contains a backmerge of v3.12. Since the -internal branch
always applied on top of -nightly I need that unified base to merge bdw
patches. So you'll get a conflict with radeon connector props when pulling
this (and nouveau/master will also conflict a bit when Ben doesn't
rebase). The backmerge itself only had conflicts in drm/i915.
There's also a tiny conflict between Jani's backlight fix and your sysfs
lifetime fix in drm-next.
* tag 'drm-intel-fixes-2013-11-07' of git://people.freedesktop.org/~danvet/drm-intel: (940 commits)
drm/i915/vlv: use per-pipe backlight controls v2
drm/i915: make backlight functions take a connector
drm/i915: move opregion asle request handling to a work queue
drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV
drm/i915: Make intel_dp_is_edp() less specific
drm/i915: Give names to the VBT child device type bits
drm/i915/vlv: enable HDA display audio for Valleyview2
drm/i915/dvo: call ->mode_set callback only when the port is running
drm/i915: avoid unclaimed registers when capturing the error state
drm/i915: Enable DP port CRC for the "auto" source on g4x/vlv
drm/i915: scramble reset support for DP port CRC on vlv
drm/i915: scramble reset support for DP port CRC on g4x
drm/i916: add "auto" pipe CRC source
...
Conflicts:
MAINTAINERS
drivers/gpu/drm/i915/intel_panel.c
drivers/gpu/drm/nouveau/core/subdev/mc/base.c
drivers/gpu/drm/radeon/atombios_encoders.c
drivers/gpu/drm/radeon/radeon_connectors.c
GEN8 removes the GT FIFO which we've all come to know and love. Instead
it offers a wider range of optimized registers which always keep a
shadowed copy, and are fed to the GPU when it wakes.
How this is implemented in hardware is still somewhat of a mystery. As
far as I can tell, the basic design is as follows:
If the register is not optimized, you must use the old forcewake
mechanism to bring the GT out of sleep. [1]
If register is in the optimized list the write will signal that the
GT should begin to come out of whatever sleep state it is in.
While the GT is coming out of sleep, the requested write will be stored
in an intermediate shadow register.
Do to the fact that the implementation details are not clear, I see
several risks:
1. Order is not preserved as it is with GT FIFO. If we issue multiple
writes to optimized registers, where order matters, we may need to
serialize it with forcewake.
2. The optimized registers have only 1 shadowed slot, meaning if we
issue multiple writes to the same register, and those values need to
reach the GPU in order, forcewake will be required.
[1] We could implement a SW queue the way the GT FIFO used to work if
desired.
NOTE: Compile tested only until we get real silicon.
v2:
- Use a default case to make future platforms also work.
- Get rid of IS_BROADWELL since that's not yet defined, but we want to
MMIO as soon as possible.
v3: Apply suggestions from Mika's review:
- s/optimized/shadowed/
- invert the logic of the helper so that it does what it says (the
code itself was correct, just confusing to read).
v4:
- Squash in lost break.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make the cur_delay limiting code a bit less prone to typo errors
by using clamp_t().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Polling to make sure the current GPU frequency matches the last
requested frequency should not be necessay, and if there's some
throttling involved, the two might not match anyway.
Since we're still seeing this trigger occasionally, and it just
introduces a rather pointless 10 ms delay, it seems like better
to kill it off.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The RPS register writing routines use the current value of min/max to
set certain limits and interrupt gating. If we set those afterwards, we
risk setting up the hw incorrectly and losing power management events,
and worse, trigger some internal assertions.
Reorder the calling sequences to be correct, and remove the then
unrequired clamping from inside set_rps(). And for a bonus, fix the bug
of calling gen6_set_rps() from Valleyview.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The max frequency reporting is not correct. But there is already an existing
valleyview_rps_max_freq and valleyview_rps_min_freq to get the
frequency. Use that for i915_cur_delayinfo.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the same wait_for_vblank code for CTG that we use for ILK+.
Also fix the name of the frame counter register while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the hardware frame counter reads 0xffffff and we're already past
vblank start, we'd return 0x1000000 as the vblank counter value. Once
we'd cross into the next frame's active portion, the vblank counter
would wrap to 0. So we're reporting two different vblank counter values
for the same frame.
Fix the problem by masking the cooked value by 0xffffff to make sure
the counter wraps already after vblank start.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual
data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333.
Some premium VLV sku will get the DDR_DATA_RATE set as 11. As a result,
the turbo frequency reporting will be incorrect without this workaround.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Fixed the botched locking on init_hw failure in i915_reset (Ville)
Call cleanup_ringbuffer on failed context create in init_hw (Ville)
v3: Add dev argument ti clean_ringbuffer
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the connector and pipe passed around, we can now set the backlight
on the right pipe on VLV/BYT.
v2: drop combination mode check for VLV (Jani)
add save/restore code for VLV backlight regs (Jani)
check for existing modulation freq when initializing backlight regs (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67245
Tested-by: Joe Konno <joe.konno@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We'll be looking at more than just mem_freq from dev_priv, so
just pass the whole thing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're currently miscalculating the VLV graphics clock a little bit.
This is caused by rounding the step to integer MHz, which does not
match reality. Change the formula to match the GUnit HAS to give
more accurate answers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV/BYT, backlight controls a per-pipe, so when adjusting the
backlight we need to pass the correct info. So make the externally
visible backlight functions take a connector argument, which can be used
internally to figure out the pipe backlight to adjust.
v2: make connector pipe lookup check for NULL crtc (Jani)
fixup connector check in ASLE code (Jani)
v3: make sure we take the mode config lock around lookups (Daniel)
v4: fix double unlock in panel_get_brightness (Daniel)
v5: push ASLE work into a work queue (Daniel)
v6: separate ASLE work to a prep patch, rebase (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Doing this has been long overdue anyway, but now we really need it in
preparation for per connector backlight handling.
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>
valleyview_modeset_global_pipes() may add pipes that are getting fully
disabled to prepare_pipes bitmask. The rest of the code doesn't expect
this, so clear out any such pipes from the prepare_pipes bitmask.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a mismatch between our vblank enable code and our IRQ
handler. Also, since vblank start events come in before page flips
reliably, it also fixes the kms_flip plain-flip test on my BYT system.
Spotted-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move the ktime_get() clock readouts and potential preempt_disable()
calls from drm core into kms driver to make it compatible with the
api changes in the drm core.
The intel-kms driver needs to take the uncore.lock inside
i915_get_crtc_scanoutpos() and intel_pipe_in_vblank().
This is incompatible with the preempt_disable() on a
PREEMPT_RT patched kernel, as regular spin locks must not
be taken within a preempt_disable'd section. Lock contention
on the uncore.lock also introduced too much uncertainty in vblank
timestamps.
Push the ktime_get() timestamping for scanoutpos queries and
potential preempt_disable_rt() into i915_get_crtc_scanoutpos(),
so these problems can be avoided:
1. First lock the uncore.lock (might sleep on a PREEMPT_RT kernel).
2. preempt_disable_rt() (will be added by the rt-linux folks).
3. ktime_get() a timestamp before scanout pos query.
4. Do all mmio reads as fast as possible without grabbing any new locks!
5. ktime_get() a post-query timestamp.
6. preempt_enable_rt()
7. Unlock the uncore.lock.
This reduces timestamp uncertainty on a low-end HP Atom Mini netbook
with Intel GMA-950 nicely:
Before: 3-8 usecs with spikes > 20 usecs, triggering query retries.
After : Typically 1 usec (98% of all samples), occassionally 2 usecs
(2% of all samples), with maximum of 3 usecs (a handful).
v2: Fix formatting of new multi-line code comments.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Either the docs were wrong or the values have changed since the old days
before we had wheels.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's possible that the CCK clock could run at a different rate than the
DDR clock, so use the same method to get CCK as the GMBUS code does when
calculating the new CDclk divider in the VLV display code.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV/BYT, we can adjust the CDclk frequency up or down based on the
max pixel clock we need to drive. Lowering it can save power, while
raising it is necessary to support high resolution.
Add a new callback in modeset_affected_pipes and a
modeset_global_resources function to perform this adjustment as
necessary.
v2: use punit interface for 320 and 266 MHz CDclk adjustments (Ville)
v3: reset GMBUS dividers too, since we changed CDclk (Ville)
v4: jump to highest voltage when going to 400MHz CDclk (Jesse)
v5: drop duplicate define (Ville)
use shifts by 1 for fixed point (Ville)
drop new callback (Daniel)
v6: fixup adjusted_mode.clock -> adjusted_mode.crtc_clock again (Ville)
document Bunit reg access better (Ville)
v7: pass modeset_pipes and pipe_config to global_pipes so we get the right
clock data (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't want it delayed with the RPS work.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No PCI ids yet, so nothing should happen.
Rebase-Note: This one needs replacement ;-)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All the bits in the VBT child device type have some speciifc meaning,
so looking for an exact match isn't always the right thing. On some
VLVs for example the device type for eDP panels is 0x1806.
If we mask out the bits that could concievably change between different
eDP panels, we are left with the set of bits that should still
tell us if the port is eDP or not.
v2: Use the named bits for VBT child device type
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051
Tested-by: Robert Hooker <robert.hooker@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
This patch defines HD-Audio configuration registers and enables display audio
from HDA controller for Valleyview2.
v2: fix missing offset VLV_DISPLAY_BASE
v3: rename patch from 'enable HDMI audio' to 'enable HDA display audio', since
it's for both HDMI and DP audio
v4: use enc_to_dig_port() to get port number, instead of using Haswell specific
function intel_ddi_get_encoder_port()
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the change in the modeset sequence this shouldn't be required
any more since the ->mode_set callback now gets called when the dvo
port is fully up and running.
Also limit the retry loop to 10 tries to avoid hanging the machine
while holding important modeset locks.
Cc: Thomas Richter <thor@math.tu-berlin.de>
Tested-by: Thomas Richter <thor@math.tu-berlin.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ns2501 controller seems to need the dpll and dvo port to accept
the timing update commands. Quick testing on my x30 here seems to
indicate that other dvo controllers don't mind. So let's move the
->mode_set callback to a place where we have the port up and running
already.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Thomas Richter <thor@math.tu-berlin.de>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I want to merge in the new Broadwell support as a late hw enabling
pull request. But since the internal branch was based upon our
drm-intel-nightly integration branch I need to resolve all the
oustanding conflicts in drm/i915 with a backmerge to make the 60+
patches apply properly.
We'll propably have some fun because Linus will come up with a
slightly different merge solution.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/intel_crt.c
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
All rather simple adjacent lines changed or partial backports from
-next to -fixes, with the exception of the thaw code in i915_dma.c.
That one needed a bit of shuffling to restore the intent.
Oh and the massive header file reordering in intel_drv.h is a bit
trouble. But not much.
v2: Also don't forget the fixup for the silent conflict that results
in compile fail ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even though we only check for unclaimed registers while we're writing
registers, if we read a bad register we'll still trigger a CPU error
interrupt, and we'll print an "Unclaimed register" DRM_ERROR due to
that. To avoid this error, just avoid touching power domains that are
not enabled.
Use kzalloc so we're sure all the disabled domains will be zeroed on
the error state file. We already print the information that is enough
to discover if the power well is enabled on the error state file, so
this should not be a problem.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69747
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that DP port CRCs are stable, we can use it for generic CRC tests.
Yay, the auto CRC source should now work everywhere!
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They've moved the DC balance reset bit around. Again I don't think we
need it, but better safe than sorry and maybe HDMI port CRC will prove
useful for checking infoframes or hdmi audio.
v2: Apply the suggestions from Damien's review.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to reset the DP scrambler on every vsync to get stable CRCs.
And since we can't use the normal pipe CRC on DP ports on g4x we
really need them to be able to test modesetting issues on (e)DP
outputs.
Note that the DC balance reset is for SDVO port CRCs so we don't
strictly need it. But better safe than sorry (and it's a nice template
in case we ever want to grab port CRCs for e.g. audio checking).
v2: Apply the suggestions from Damien's review.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On gmch platforms the normal pipe source CRC registers don't work for
DP and TV encoders. And on newer platforms the single pipe CRC has
been replaced by a set of CRC at different stages in the platform.
Now most of our userspace tests don't care one bit about the exact
CRC, they simply want something that reflects any changes on the
screen. Hence add a new auto target for platform agnostic tests to
use.
v2: Pass back the adjusted source so that it can be shown in debugfs.
v3: I seem to be unable to get a stable CRC for DP ports. So let's
just disable them for now when using the auto mode. Note that
testcases need to be restructured so that they can dynamically skip
connectors. They also first need to set up the desired mode
configuration, since otherwise the auto mode won't do the right thing.
v4: Don't leak the modeset mutex on error paths.
v5: Spelling fix for the i9xx auto_source function.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That explains why I was seeing 2 consecutive "Turning eDP VDD off"
messages.
Regression introduced by:
commit bf13e81b90
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Sep 6 07:40:05 2013 +0300
drm/i915: add support for per-pipe power sequencing on vlv
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In
commit 6efdf354dd
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Oct 16 17:25:52 2013 +0300
the check for i915_disable_power_well flag was removed by overlook,
so add it back now.
Reported-by: Paulo Zanoni <paulo.zanoni@intel.com>
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>
Incorrect definition DPIO_TX3_SWING_CTL4.
From Ville's review: "Based on the specs, the typo meant that HDMI B
ended up using "incorrect" de-emphasis for the TMDS data lanes."
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add comment from Ville's review about the impact.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now we only print messages when we actually enable VDD and when we
actually disable VDD.
The changes in the last commit triggered a big number of messages
while the driver was being initialized, and I thought we were toggling
things on/off too many times, but that was not really true: we were
just being too verbose.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the eDP output is disabled, then we try to use /dev/i2c-X file to
do i2c transations, we get a WARN from intel_dp_check_edp() saying
we're trying to do AUX communication with the panel off. So this
commit reorganizes the code so we enable the VDD at
intel_dp_i2c_aux_ch() instead of just the callers inside i915.ko.
This fixes the i2c subtest from the pc8 test of intel-gpu-tools on
machines that have eDP panels.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Use a for_each_loop and add the corresponding #defines.
- Drop the _ILK postfix on the existing DE_PIPE_VBLANK macro for
consistency with everything else.
- Also use macros (and add the missing one for plane flips) for the
ivb display interrupt handler.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Drop the useless parens that Ville spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Request by Ville in his review of the CRC stuff. This converts
everything but ilk_display_irq_handler since that needs a bit more
than a simple search&replace to look nice.
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>
The bbstate contains useful bits of debugging information such as
whether the batch is being read from GTT or PPGTT, or whether it is
allowed to execute privileged instructions.
v2: Only record BB_STATE for gen4+
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise QA will report this as a real hang when running igt
ZZ_missed_irq.
v2: Actually test the right stuff and really shut up the DRM_ERROR
output ...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70747
Tested-by: lu hua <huax.lu@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similarly rename the other related functions in the power domain
interface.
Higher level driver code calling these functions knows only about power
domains, not the underlying power wells which may be different on
different platforms. Also these functions really init/cleanup/resume
power domains and only through that all related power wells, so rename
them accordingly.
Note that I left i915_{request,release}_power_well as is, since that
really changes the state only of a single power well (and is HSW
specific). It should also get a better name once we make it more
generic by controlling things through a new audio power domain.
v4:
- use intel prefix instead of i915 everywhere (Paulo)
- use a $prefix_$block_$action format (Daniel)
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>
Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.
For example when we change the fdi lines from 2 to 3 without switching
off outputs in-between we'll never see the crucial on->off transition
in the ->modeset_global_resources hook the current logic relies on.
Patch version 2 got this right by instead also checking whether the
pipe is indeed active. But that in turn broke things when pipes have
been turned off through dpms since the bifurcate enabling is done in
the ->crtc_mode_set callback.
To address this issues discussed with Ville in the patch review move
the setting of the bifurcate bit into the ->crtc_enable hook. That way
we won't wreak havoc with this state when userspace puts all other
outputs into dpms off state. This also moves us forward with our
overall goal to unify the modeset and dpms on paths (which we need to
have to allow runtime pm in the dpms off state).
Unfortunately this requires us to move the bifurcate helpers around a
bit.
Also update the commit message, I've misanalyzed the bug rather badly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507
Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Cc: stable@vger.kernel.org
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>
We store cursor_x/y as int16_t internally, but the user provided
coordinates are int32_t. Clamp the coordinates so that they don't
overflow the int16_t. Since the cursor is only 64x64 in size, the
clamping can't cause any visual changes.
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>
The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
having LVDS but the hardware is not populated. This patch adds them to
the list of such systems. Patch is against 3.11.4
v2: Patch revised to match the D425KT exactly as the D425KTW does have
LVDS. According to Intel's documentation, the D410PTL and D410PLTW
don't.
Signed-off-by: Rob Pearce <rob@flitspace.org.uk>
Cc: stable@vger.kernel.org
[danvet: Pimp commit message to my liking and add cc: stable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.
There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.
The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.
Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.
The bug raised its head since
commit 657445fe86
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat May 4 10:09:18 2013 +0200
Revert "drm/i915: revert eDP bpp clamping code changes"
which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.
Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.
We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
Tested-by: Ulf Winkelvos <ulf@winkelvos.de>
Tested-by: jkp <jkp@iki.fi>
CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Call intel_ddi_get_config() to get the pipe_bpp settings from
DDI.
The sync polarity settings from DDI are irrelevant for CRT
output, so override them with data from the ADPA register.
Note: This is already merged in drm-intel-next-queued as
commit 6801c18c0a
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Tue Sep 24 14:24:05 2013 +0300
drm/i915: Add HSW CRT output readout support
but is required for the following edp bpp bugfix.
v2: Extract intel_crt_get_flags()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691
Tested-by: Qingshuai Tian <qingshuai.tian@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On CTG+ read out the pipe bpp setting from hardware and fill it into
pipe config. Also check it appropriately.
v2: Don't do the pipe_bpp extraction inside the PCH only code block on
ILK+.
Avoid the PIPECONF read as we already have read it for the
PIPECONF_EANBLE check.
Note: This is already in drm-intel-next-queued as
commit 42571aefaf
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Sep 6 23:29:00 2013 +0300
drm/i915: Add support for pipe_bpp readout
but is needed for the following bugfix.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The only real need for this field was in
i915_{request,release}_power_well, but there we can get at it by a
container_of magic. Also since in the future we'll have multiple power
wells each with its own power_well struct it makes sense to remove the
field from there where it'd be just redundancy.
Suggested-by: Paulo Zanoni <paulo.zanoni@intel.com>
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>
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.
This logic is supported by intel_set_power_well() in the power domain
framework. It would be nice to simplify the API, so that we only have
get/put functions and make it more explicit on the higher level how this
"power well on during init" logic works. This will make it also easier
if in the future we want to shorten the time the power wells are on.
For this add a new device private flag tracking whether we have the
power wells on because of init/suspend and use only
intel_display_power_get()/put(). As nothing else uses
intel_set_power_well() we can remove it.
This also fixes
commit 6efdf354dd
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Oct 16 17:25:52 2013 +0300
drm/i915: enable only the needed power domains during modeset
where removing intel_set_power_well() resulted in not releasing the
reference on the power well that was taken during init and thus leaving
the power well on all the time. Regression reported by Paulo.
v2:
- move the init_power_on flag to the power_domains struct (Daniel)
v3:
- add note about this being a regression fix too (Paulo)
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>
In the future we'll need to support multiple power wells, so prepare for
that here. Create a new power domains struct which contains all
power domain/well specific fields. Since we'll have one lock protecting
all power wells, move power_well->lock to the new struct too.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Production HSW does not need it. I confirmed this with Art.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Production IVB does not need it. I confirmed this with Art.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All our registers which are written through the MCHBAR are defined
descriptively as an offset to the MCHBAR. We had 3 outliers here.
Convert these as well so all registers which are offsets are MCHBAR can
be easily identified/found within the code.
With this, convert DCLK to also follow this format.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- CRC support from Damien and He Shuang. Long term this should allow us to
test an awful lot modesetting corner cases automatically. So for me as
the maintainer this is really big.
- HDMI audio fix from Jani.
- VLV dpll computation code refactoring from Ville.
- Fixups for the gpu booster from last time around (Chris).
- Some cleanups in the context code from Ben.
- More watermark work from Ville (we'll be getting there ...).
- vblank timestamp improvements from Ville.
- CONFIG_FB=n support, including drm core changes to make the fbdev
helpers optional.
- DP link training improvements (Jani).
- mmio vtable from Ben, prep work for future hw.
* tag 'drm-intel-next-2013-10-18' of git://people.freedesktop.org/~danvet/drm-intel: (132 commits)
drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp
drm/i915: remove dead code in ironlake_crtc_mode_set
drm/i915: crc support for hsw
drm/i915: fix CRC debugfs setup
drm/i915: wait one vblank when disabling CRCs
drm/i915: use ->get_vblank_counter for the crc frame counter
drm/i915: wire up CRC interrupt for ilk/snb
drm/i915: add CRC #defines for ilk/snb
drm/i915: extract display_pipe_crc_update
drm/i915: don't Oops in debugfs for I915_FBDEV=n
drm/i915: set HDMI pixel clock in audio configuration
drm/i915: pass mode to ELD write vfuncs
cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n
drm/i915: check gem bo size when creating framebuffers
drm/i915: Use unsigned long for obj->user_pin_count
drm/i915: prevent tiling changes on framebuffer backing storage
drm/i915: grab dev->struct_mutex around framebuffer_init
drm/i915: vlv: fix VGA hotplug after modeset
drm: add support for additional stereo 3D modes
drm/i915: preserve dispaly init order on ByT
...
So drm was abusing device lifetimes, by having embedded device structures
in the minor and connector it meant that the lifetime of the internal drm
objects (drm_minor and drm_connector) were tied to the lifetime of the device
files in sysfs, so if something kept those files opened the current code
would kfree the objects and things would go downhill from there.
Now in reality there is no need for these lifetimes to be so intertwined,
especailly with hotplugging of devices where we wish to remove the sysfs
and userspace facing pieces before we can unwind the internal objects due
to open userspace files or mmaps, so split the objects out so the struct
device is no longer embedded and do what fbdev does and just allocate
and remove the sysfs inodes separately.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel pointed out that it was hard to get anything lockless to work
correctly, so don't even try for this non critical piece of code and
just use a spin lock.
v2: Make intel_pipe_crc->opened a bool
v3: Use assert_spin_locked() instead of a comment (Daniel Vetter)
v4: Use spin_lock_irq() in the debugfs functions (they can only be
called from process context),
Use spin_lock() in the pipe_crc_update() function that can only be
called from an interrupt handler,
Use wait_event_interruptible_lock_irq() when waiting for data in the
cicular buffer to ensure proper locking around the condition we are
waiting for. (Daniel Vetter)
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adding stuff to the bottom of struct drm_i915_driver_private is
nowadays considered uncool.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far the modeset code enabled all power domains if it needed any. It
wasn't a problem since HW generations so far only had one always-on
power well and one dynamic power well that can be enabled/disabled. For
domains powered by always-on power wells (panel fitter on pipe A and the
eDP transcoder) we didn't do anything, for all other domains we just
enabled the single dynamic power well.
Future HW generations will change this, as they add multiple dynamic
power wells. Support for these will be added later, this patch prepares
for those by making sure we only enable the required domains.
Note that after this change on HSW we'll enable all power domains even
if it was the domain for the panel fitter on pipe A or the eDP
transcoder. This isn't a problem since the power domain framework
already checks if the domain is on an always-on power well and doesn't
do anything in this case.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We'll need the same functionality for other HW generations. The support
for these will be added by upcoming patches.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no hard need for this to be a spin lock, as we don't take these
locks in irq context from anywhere. An upcoming patch will add calls to
punit read/write functions from within regions protected by this lock
and those functions need a mutex in turn. As a solution for that convert
the spin lock to be a mutex.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is just cleaner this way and makes it easier to add support for
other HW generations with always-on power wells powering a different
set of domains.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Upcoming patches will add tracking for a set of power domains via a
bitmask; to make things simple there remove the current gap in the
enum values.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Give them an _irq_handler postfix, like all the other irq stuff.
- Shuffle the DEBUG_FS=n dummy functions around a bit. This is prep
work to extract all the crc debug stuff into intel_display_testing.c
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Really simple, and we don't even have working frame numbers.
v2: Actually enable it ...
v3: Review from Ville:
- Unconditionally enable the border in the CRC checksum for
consistency with gen3+.
- Handle the "none" source to be able to disable the CRC machinery
again.
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>
On pre-gen5 and vlv we can't use the pipe source when TV-out or a DP
port is connected to the pipe. Hence we need to expose new CRC
sources.
Also simplify the existing pipe source platform code a bit by
rejecting all unhandled sources by default.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The PIPE_B #define was missing the display mmio offset. Use the
_PIPE_INC macro instead, it's simpler.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And throw in a tiny for_each_pipe refactoring for gen2.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A bit a mess, since with DP/TV outputs we can't use the pipe CRC.
Also, no plane CRCs, so we need to update the basic testcases.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Should work down to gen2. The #defines for the interrupt sources are
already there in PIPESTAT and are the same on all gmch platforms for
gen2 up to vlv.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the nice Kernel macro, it makes the code much more readable.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we use intel_enable_rc6() now for more than just when we're
enabling RC6, we'll see this message many times, and it is just
confusing.
As an example, calc_residency calls this function whenever poked via
sysfs. This leaves the impression in dmesg that we're constantly
re-enabling RC6.
While at it, move the defines and description from drv.h to intel_pm.c,
since these are only ever used in that code.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is useful with the follow-up patch that frobs
dev_priv->vbt.edp_bpp, and the value no longer comes directly from
VBT.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot currently explain why the latent GPU writes
occur.
In the technical sense, this patch is a workaround in that we have an
issue we can't explain, and the patch indirectly solves the issue.
However, it's really better than a workaround because we understand why
it works, and it really should be a safe thing to do in all cases.
The noticeable effect other than the debug messages would be an increase
in the suspend time. I have not measure how expensive it actually is.
I think it would be good to spend further time to root cause why we're
seeing these latent writes, but it shouldn't preclude preventing the
fallout.
NOTE: It should be safe (and makes some sense IMO) to also keep the
VALID bit unset on resume when we clear_range(). I've opted not to do
this as properly clearing those bits at some later point would be extra
work.
v2: Fix bugzilla link
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321
Tested-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Tested-By: Todd Previte <tprevite@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need this to work around a corruption when the boot kernel image
loads the hibernated kernel image from swap on Haswell systems -
somehow not everything is properly shut off.
This is just the prep work, the next patch will implement the actual
workaround.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add a commit message suitable for -fixes and add cc: stable]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jun 5 13:34:23 2013 +0200
drm/i915: consolidate pch pll enable sequence
I've removed all the code from this if block, but somehow forgotten to
kill the block itself.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
hw designers decided to change the CRC registers and coalesce them all
into one. Otherwise nothing changed. I've opted for a new hsw_ version
to grab the crc sample since hsw+1 will have the same crc registers,
but different interrupt source registers. So this little helper
function will come handy there.
Also refactor the display error handler with a neat pipe loop.
v2: Use for_each_pipe.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've set up all files, but removed only those for which we have a
pipe. Which leaves the one for pipe C on machines with less than 2
pipes, breaking module reload.
v2: We can't get at the drm device this early (wtf), so just register
all the files and also remove them all again.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This avoids a spurious spurious interrupt warning.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We enable the interrupt unconditionally and only control it
through the enable bit in the CRC control register.
v2: Extract per-platform helpers to compute the register values.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also add a new _PIPE_INC macro which takes an base plus increment.
Much less likely to botch the job by missing an s/A/B/ somewhere.
v2: They've moved the bitfield. Argh!
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ringbuffer update logic should always be the same, but different
platforms have different amounts of CRC registers. Hence extract it.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Failed to properly test this.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The HDMI audio expects HDMI pixel clock to be set in the audio
configuration. We've currently just set 0, using 25.2 / 1.001 kHz
frequency, which fails with some modes.
v2: Now with a commit message.
Reference: http://mid.gmane.org/CAGpEb3Ep1LRZETPxHGRfBDqr5Ts2tAc8gCukWwugUf1U5NYv1g@mail.gmail.com
Reference: http://mid.gmane.org/20130206213533.GA16367@hardeman.nu
Reported-by: David Härdeman <david@hardeman.nu>
Reported-by: Jasper Smet <josbeir@gmail.com>
Tested-by: Jasper Smet <josbeir@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will be needed for setting the HDMI pixel clock for audio
config. No functional changes.
v2: Now with a commit message.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's better to catch such fallout early, and this way we can rely on
the checking done by the drm core on fb->heigh/width at modeset time.
If we ever support planar formats on intel we might want to look into
a common helper to do all this, but for now this is good enough.
v2: Take tiling into account, requested by Ville.
v3: Fix tile height on gen2, spotted by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: 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>
At least on linux sizeof(long) == sizeof(void*) and the thinking
is that you can grab about as many references as there's memory.
Doesn't really matter, just a bit of OCD since the fixed size data
type in a pure in-kernel datastructure look off.
v2: Ville asked for an overflow check since no one prevents userspace
from incrementing the pin count forever.
v3: s/INT/LONG/, noticed by Chris.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-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>
Assuming that all framebuffer related metadata is invariant simplifies
our userspace input data checking. And current userspace always first
updates the tiling of an object before creating a framebuffer with it.
This allows us to upconvert a check in pin_and_fence to a WARN.
In the future it should also be helpful to know which buffer objects
are potential scanout targets for e.g. frontbuffer rendering tracking
and similar things.
Note that SNA shipped for one prerelease with code which will be
broken through this patch. But users shouldn't notice since it's
purely an optimization and will transparently fall back to allocating
a new fb. i-g-t also had offending code (now fixed), but we don't
really care about breaking the test-suite.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Grumpily-reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We look at gem state (like obj->tiling/obj->stride), we better have
the relevant locks.
Right now this doesn't matter much since most of these checks are
a curtesy to safe buggy userspace, but I'd like to freeze the tiling
once we have framebuffer objects attached. And then locking matters.
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>
Since
commit 912d812e84
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Oct 11 20:08:23 2012 +0200
drm/i915/crt: don't set HOTPLUG bits on !PCH
on VLV we don't detect any VGA unplug event after a modeset, since there we
reset the ADPA hotplug bits. Fix it by preserving the hotplug bits on VLV as
well.
Signed-off-by: Imre Deak <imre.deak@intel.com>
[danvet: For consistency use gen >= 5 like in Chris' exact same fix
in intel_crt_reset.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch changes HDMI port registration order for the BayTrail platform.
The story is that in kernel version 3.11 i915 supported only one HDMI port -
the HDMIB port. So this port ended up being HDMI-1 in user-space.
But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT'
introduced HDMIC port support. And added HDMIC registration prior to HDMIB,
so HDMIB became HDMI-2 and HDMIC became HDMI-1.
Well, this is fine as far as the kernel is concerned. i915 does not give any
guarantees to the numbering, and has never given them.
However, this breaks wayland setup in Tizen IVI. We have only one single HDMI
port on our hardware, and it is connected to HDMIB. Our configuration relies on
the fact that it is HDMI-1.
Well, certainly this is user-space problem which was exposed with Jesse's
patch. However, there is a reason why we have to do this assumption - we use
touchscreen monitors and we have to associate event devices with the monitors,
and this is not easy to do dynamically, so we just have a static setup.
Anyway, while the user-space setup will have to be fixed regardless, let's
chane the HDMI port registration order so that HDMIB stays HDMI-1, just like it
was in 3.11. Simply because there is no strong reason for changing the order in
the kernel, and it'll help setups like ours in sense that we'll have more time
for fixing the issue properly.
Also amend the commentary which looks a bit out-of-date.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
[danvet: Drop the commment, SDVOC is gone and we have a proper HDMIC
define now.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yet other direct usages of the pipe number instead of pipe_name().
We've been tracking them lately but managed to miss these last ones.
v2: Catch them all! (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have two once very similar functions, i915_gpu_idle() and
i915_gem_idle(). The former is used as the lower level operation to
flush work on the GPU, whereas the latter is the high level interface to
flush the GEM bookkeeping in addition to flushing the GPU. As such
i915_gem_idle() also clears out the request and activity lists and
cancels the delayed work. This is what we need for unloading the driver,
unfortunately we called i915_gpu_idle() instead.
In the process, make sure that when cancelling the delayed work and
timer, which is synchronous, that we do not hold any locks to prevent a
deadlock if the work item is already waiting upon the mutex. This
requires us to push the mutex down from the caller to i915_gem_idle().
v2: s/i915_gem_idle/i915_gem_suspend/
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: xunx.fang@intel.com
[danvet: Only set ums.suspended for !kms as discussed earlier. Chris
noticed that this slipped through.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no functional change on this patch. Only rename several
hdmi encoder function name which suppose to use only by valleyview from
intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We not only want const strings, but a const array of them. Reported by
checkpatch.pl
Cc: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also use #ifdef to keep consistent with all other such cases.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's time to declare them ready. Unleash the beast.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It doesn't really make sense to have two processes dequeueing the CRC
values at the same time. Forbid that usage.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
seq_file is not quite the right interface for these ones. We have a
circular buffer with a new entry per vblank on one side and a process
wanting to dequeue the CRC with a read().
It's quite racy to wait for vblank in user land and then try to read a
pipe_crc file, sometimes the CRC interrupt hasn't been fired and we end
up with an EOF.
So, let's have the read on the pipe_crc file block until the interrupt
gives us a new entry. At that point we can wake the reading process.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Following commit needs drm_add_fake_info_node() higher in the file to
avoid having a forward declaration. Move this helper near the top of the
file.
This also makes the next commit diff a bit easier to review.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This shouldn't happen as the buffer is freed after disable pipe CRCs,
but better be safe than sorry.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the same spirit than:
drm/i915: Generalize the CRC command format for future work
Let's move from writing 'A plane1' to 'pipe A plane1' to
i915_pipe_crc_ctl. This will allow us to extend the interface to
transcoders or DDIs in the future.
Let's rename the CRC control file to be more generic.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's move from writing 'A plane1' to 'pipe A plane1' to
i915_pipe_crc_ctl. This will allow us to extend the interface to
transcoders or DDIs in the future.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So we don't eat that memory when not needed.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So we don't read out stale CRCs from a previous run left in the buffer.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This way we can have some init/fini code on those transitions.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are a few good properties to a circular buffer, for instance it
has a number of entries (before we were always dumping the full buffer).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Note the "return -ENODEV;" in pipe_crc_set_source(). The ctl file is
disabled until the end of the series to be able to do incremental
improvements.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are several points in the display pipeline where CRCs can be
computed on the bits flowing there. For instance, it's usually possible
to compute the CRCs of the primary plane, the sprite plane or the CRCs
of the bits after the panel fitter (collectively called pipe CRCs).
v2: Quite a bit of rework here and there (Damien)
Signed-off-by: Shuang He <shuang.he@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Fix intermediate compile file reported by Wu Fengguang's
kernel builder.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've sent this patch several times for various reasons. It essentially
cleans up a lot of code where we need to do something per ring, and want
to query whether or not the ring exists on that hardware.
It has various uses coming up, but for now it shouldn't be too
offensive.
v2: Big conflict resolution on Damien's DEV_INFO_FOR_EACH stuff
v3: Resolved vebox addition
v4: Rebased after months of disuse. Also made failed ringbuffer init
cleaner.
v5: Remove the init cleaner from v4. There is a better way to do it.
(Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I had this lying around from he original PPGTT series, and thought we
might try to get it in by itself.
With the introduction of context refcounting we never explicitly
ref/unref the backing object. As such, the previous fix was a bit wonky.
Aside from fixing the above, this patch also puts us in good shape for
an upcoming patch which allows a failure to occur in between
context_init and the first do_switch.
CC: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I had this lying around from he original PPGTT series, and thought we
might try to get it in by itself.
It's convenient to just call i915_gem_init_hw at reset because we'll be
adding new things to that function, and having just one function to call
instead of reimplementing it in two places is nice.
In order to accommodate we cleanup ringbuffers in order to bring them
back up cleanly. Optionally, we could also teardown/re initialize the
default context but this was causing some problems on reset which I
wasn't able to fully debug, and is unnecessary with the previous context
init/enable split.
This essentially reverts:
commit 8e88a2bd59
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jun 19 18:40:00 2012 +0200
drm/i915: don't call modeset_init_hw in i915_reset
It seems to work for me on ILK now. Perhaps it's due to:
commit 8a5c2ae753
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Mar 28 13:57:19 2013 -0700
drm/i915: fix ILK GPU reset for render
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using the 5/6 DDB split make sense only when sprites are enabled.
So check that before we waste any cycles computing the merged
watermarks with the 5/6 DDB split.
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>
Makes the behaviour of the function more clear.
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>
Makes the intention more clear.
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>
We want to be able to use the masks to decode the register contents
regardless of the hardware generation. So just expand the masks to
cover all available bits, even if those are reserved on some
generations.
v2: Don't extend WM1_LP_SR_MASK so far, for the *future*
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>
This debug print just adds overhead to the watermark merging process,
and doesn't really give enough information to be useful. Just kill
and let's add something much better a bit later.
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>
Fill out the HSW watermark s/w tracking structures with the current
hardware state in intel_modeset_setup_hw_state(). This allows us to skip
the HW state readback during watermark programming and just use the values
we keep around in dev_priv->wm. Reduces the overhead of the watermark
programming quite a bit.
v2: s/init_wm/wm_get_hw_state
Remove stale comment about sprites
Make DDB partitioning readout safer
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix whitespace fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently hsw_write_vm_values() may write to certain watermark
registers needlessly. For instance if only, say, LP3 changes,
the current code will again disable all LP1+ watermarks even
though only LP3 needs to be reconfigured.
Add an easy to read function that will compute the dirtyness of the
watermarks, and use that information to further optimize the watermark
programming.
v2: Disable LP1+ watermarks around changing LP0 watermarks for Paulo
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>
To make it easier to check what watermark updates are actually
necessary, keep copies of the relevant bits that match the current
hardware state.
Also add DDB partitioning into hsw_wm_values as that's another piece
of state we want to track.
We don't read out the hardware state on init yet, so we can't really
start using this yet, but it will be used later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Paulo asked for a comment around the memcmp to say that we
depend upon zero-initializing the entire structures due to padding.
But a later patch in this series removes the memcmp again. So this is
ok as-is.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The fbc_wm_enabled member in intel_wm_config is useless for the time
being. The original idea for it was that we'd pre-compute it and so
that the WM merging process could know whether it needs to worry
about FBC watermarks at all.
But we don't have a convenient way to pre-check for the possibility
of FBC being used. intel_update_fbc() should be split up for that.
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>
On HSW the LP1,LP2,LP3 levels are either 1,2,3 or 1,3,4. We make the
conversion from LPn to to the level at one point current. Later we're
going to do it in a few places, so move it to a separate function.
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>
Using the 5/6 DDB split make sense only when sprites are enabled.
So check that before we waste any cycles computing the merged
watermarks with the 5/6 DDB split.
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>
Move the watermark max computations into haswell_update_wm(). This
allows keeping the 1/2 vs. 5/6 split code in one place, and avoid having
to pass around so many things. We also save a bit of stack space by only
requiring one copy of struct hsw_wm_maximums.
Also move the intel_wm_config out from hsw_compute_wm_parameters() and
pass it it. We'll have some need for it in haswell_update_wm() later.
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>
Let's try to keep using the intermediate intel_pipe_wm representation
for as long as possible. It avoids subtle knowledge about the
internals of the hardware registers when trying to choose the
best watermark configuration.
While at it replace the memset() w/ zero initialization.
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>
I want to convert hsw_find_best_result() to use intel_pipe_wm, so we
need to move the merging to happen outside hsw_compute_wm_results().
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>
No point in re-computing the watermarks for all pipes, when only one
pipe has changed. The watermarks stored under intel_crtc.wm.active are
still valid for the other pipes. We just need to redo the merging.
We can also skip the merge/update procedure completely if the new
watermarks for the affected pipe come out unchanged.
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>
Introduce a new struct intel_pipe_wm which contains all the
watermarks for a single pipe. Use it to unify the LP0 and LP1+
watermark computations so that we can just iterate through the
watermark levels neatly and call ilk_compute_wm_level() for each.
Also add another tool ilk_wm_merge() that merges the LP1+ watermarks
from all pipes. For that, embed one intel_pipe_wm inside intel_crtc that
contains the currently valid watermarks for each pipe.
This is mainly preparatory work for pre-computing the watermarks for
each pipe and merging them at a later time. For now the merging still
happens immediately.
v2: Add some comments about level 0 DDB split and intel_wm_config
Add WARN_ON for level 0 being disabled
s/lp_wm/merged
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>
Needed to prevent display corruption in high res panels.
v2: use correct unit names (Rodrigo)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Ulrich Drepper <drepper@gmail.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gen2 doesn't have a hardware frame counter that can be read out. Just
provide a stub .get_vblank_counter() that always returns 0 instead of
trying to read non-existing registers.
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>
Gen2 doesn't have the pixelcount register that gen3 and gen4 have.
Instead we must use the scanline counter like we do for ctg+.
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>
The DSL register increments at the start of horizontal sync, so it
manages to miss the entire active portion of the current line.
Improve the get_scanoutpos accuracy a bit when the scanout position is
close to the start or end of vblank. We can do that by double checking
the DSL value against the vblank status bit from ISR.
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: mario.kleiner.de@gmail.com
Tested-by: mario.kleiner.de@gmail.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The reported scanout position must be relative to the end of vblank.
Currently we manage to fumble that in a few ways.
First we don't consider the case when vtotal != vbl_end. While that
isn't very common (happens maybe only w/ old panel fitting hardware),
we can fix it easily enough.
The second issue is that on pre-CTG hardware we convert the pixel count
to horizontal/vertical components at the very beginning, and then forget
to adjust the horizontal component to be relative to vbl_end. So instead
we should keep our numbers in the pixel count domain while we're
adjusting the position to be relative to vbl_end. Then when we do the
conversion in the end, both vertical _and_ horizontal components will
come out correct.
v2: Change position to int from u32 to avoid sign issues
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: mario.kleiner.de@gmail.com
Tested-by: mario.kleiner.de@gmail.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have all the information we need in the mode structure, so going and
reading it from the hardware is pointless, and slower.
We never populated ->get_vblank_timestamp() in the UMS case, and as that
is the only way we'd ever call ->get_scanout_position(), we can
completely ignore UMS in i915_get_crtc_scanoutpos().
Also reorganize intel_irq_init() a bit to clarify the KMS vs. UMS
situation.
v2: Drop UMS code
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: mario.kleiner.de@gmail.com
Tested-by: mario.kleiner.de@gmail.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rounding down when calculating the dot/vco frequencies doesn't make much
sense. Round to closest should give slightly nicer answers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At the moment we have 3 paths that lead to actually_set_backlight(),
from modesetting, ACPI/OpRegion requests and our very own
intel_backlight interface, and we have no way of distinguishing them in
the debug log. So add a debug breadcrumb to explain the source of the
backlight changes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The old style frame counter increments at the start of active video.
However for i915_get_vblank_counter() we want a counter that increments
at the start of vblank.
Fortunately the low frame counter register also contains the pixel
counter for the current frame. We can can compare that against the
vblank start pixel count to determine if we need to increment the
frame counter by 1 to get the correct answer.
Also reorganize the function pointer assignments in intel_irq_init() a
bit to avoid confusing people.
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This file is all about the legacy fbdev support. If we want to extract
framebuffer functions, we better put those into a separate file.
Also rename functions accordingly, only two have used the intel_fb_
prefix anyway.
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Boots Just Fine (tm)!
The only glitch seems to be that at least on Fedora the boot splash
gets confused and doesn't display much at all.
And since there's no ugly console flickering anymore in between, the
flicker while switching between X servers (VT support is still enabled)
is even more jarring.
Also, I'm unsure whether we don't need to somehow kick out vgacon, now
that nothing else gets in the way. But stuff seems to work, so I
don't care. Also everything still works as well with VGA_CONSOLE=n
Also the #ifdef mess needs a bit of a cleanup, follow-up patches will
do just that.
To keep the Kconfig tidy, extract all the i915 options into its own
file.
v2:
- Rebase on top of the preliminary hw support option and the
intel_drv.h cleanup.
- Shut up warnings in i915_debugfs.c
v3: Use the right CONFIG variable, spotted by Chon Ming.
Cc: Lee, Chon Ming <chon.ming.lee@intel.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Supposedly VLV uses the CTG+ style frame counter registers instead of
the old gen3/4 style. Add the magic offset to the correct registers.
We should already be taking the correct codepaths for
.get_vblank_counter() and .get_scanout_position().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So digging out the right ones is a little easier.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On gen7+, CACHE_MODE_0 moved, so we're clobbering some other reg rather
than restoring CACHE_MODE_0. Don't do that.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current pre-gen4 pipe off code might break out of the loop
due to the timeout, but then the fail to print the warning.
Refactor the code a bit to use wait_for() to avoid the problem,
and that we also re-check the condition after the timeout has
expired.
v2: Use wait_for()
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>
The spec says the default timeout should be 2ms, but on my machine
this doesn't seem to be enough. Sometimes it works, sometimes I get
these messages when booting:
- SWSCI request timed out
- SWSCI request already in progress
And my guess is that the "already in progress" message is because the
first one is still happening.
I did some experiments on my machine (that has CONFIG_HZ=1000) and the
wait_for function usually takes 4-6 jiffies to finish, but I've seen
up to 9. So increase the timeout to 50ms. We only expect to wait for
the actual amount of time the operation takes, so even a huge timeout
shouldn't delay us more than what the hardware actually requires.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 81b5c7bc8d.
Adding drm/i915 into the vga arbiter chain means that X (in a piece of
well-meant paranoia) will do a get/put on the vga decoding around
_every_ accel call down into the ddx. Which results in some nice
performance disasters [1]. This really breaks userspace, by disabling
DRI for everyone, and stops OpenGL from working, this isn't limited
to just the i915 but both the integrated and discrete GPUs on
multi-gpu systems, in other words this causes untold worlds of pain,
Ville tried to come up with a Great Hack to fiddle the required VGA
I/O ops behind everyone's back using stop_machine, but that didn't
really work out [2]. Given that we're fairly late in the -rc stage for
such games let's just revert this all.
One thing we might want to keep is to delay the disabling of the vga
decoding until the fbdev emulation and the fbcon screen is set up. If
we kill vga mem decoding beforehand fbcon can end up with a white
square in the top-left corner it tried to save from the vga memory for
a seamless transition. And we have bug reports on older platforms
which seem to match these symptoms.
But again that's something to play around with in -next.
References: [1] http://lists.x.org/archives/xorg-devel/2013-September/037763.html
References: [2] http://www.spinics.net/lists/intel-gfx/msg34062.html
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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>
As we delay the initial RPS enabling (upon boot and after resume), there
is a chance that we may start to render and trigger RPS boosts before we
set up the punit. Any changes we make could result in inconsistent
hardware state, with a danger of causing undefined behaviour. However,
as the boosting is a optional tweak to RPS, we can simply ignore it
whilst RPS is not yet enabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Educate the users why i915 won't load on gen6+ and nomodeset.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=61671
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Untangling me-too reports that actually aren't is really messy. And we
need to make sure the blame is put where it should be right from the
start ;-)
v2: Improve the wording from Ben's suggestions.
Cc: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Frob the message as suggested by Paulo on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Enabling rps (turbo setup) was put in a work queue because it may
take quite awhile. This change flushes the work queue to initialize
rps values before use by sysfs or debugfs. Specifically,
rps.delayed_resume_work is flushed before using rps.hw_max,
rps.max_delay, rps.min_delay, or rps.cur_delay.
This change fixes a problem in sysfs where show functions using
uninitialized values show incorrect values and store functions
using uninitialized values in range checks incorrectly fail to
store valid input values. This change also addresses similar use
before initialized problems in debugfs.
Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We lost the ability to capture the first error for a stuck ring in the
recent hangcheck robustification. Whilst both error states are
interesting (why does the GPU not recover is also essential to debug),
our primary goal is to fix the initial hang and so we need to capture
the first error state upon taking hangcheck action.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's try to avoid these confusing negated booleans.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Regression introduced by:
commit 311a20949f
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
drm/i915: don't init DP or HDMI when not supported by DDI port
Since the commit above it is possible to have a DDI encoder that has
the HDMI connector but not the DP connector (in case the port doesn't
support DP). In this case, we must properly free the DP connector.
We just leak this once, so it's not a big deal.
Reported by kmemleak.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The DP spec allows this, and requires it when full link training is
started with non-minimum voltage swing and/or non-zero pre-emphasis.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For future platforms we'll need to initialize our MMIO function pointers
even earlier. Specifically, we'll need to be able to have register
reads/writes at GTT initialization (in i915_gem_gtt_init). Similarly,
these platforms also have MMIO differences based on the PCH id, so
while moving stuff around, also move the PCH initialization.
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Mention the function where we need register access.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At the end of haswell_crtc_enable we have an intel_wait_for_vblank
with a big comment, and the message suggests it's a workaround for
something we don't really understand. So I removed that wait and
started getting HW state readout error messages saying that the IPS
state is not what we expected.
I investigated and concluded that after you write IPS_ENABLE to
IPS_CTL, the bit will only actually become 1 on the next vblank. So
add code to wait for the IPS_ENABLE bit. We don't really need this
wait right now due to the wait I already mentioned, but at least this
one has a reason to be there, while the other one is just to
workaround some problem: we may remove it in the future.
The wait also acts as a POSTING_READ which we missed.
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>
Something already got misplaced (although it's from a patch from
before Paulo's cleanup). Move it to the right spot.
v2: Remove the line to keep a neat block, requested by Paulo.
Reported-by: Paulo Zanoni <przanoni@gmail.com>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that MMIO has been split up into gen specific functions it is
obvious when HAS_FPGA_DBG_UNCLAIMED, HAS_FORCE_WAKE are needed. As such,
we can remove this extraneous condition.
As a result of this, as well as previously existing function pointers
for forcewake, we no longer need the has_force_wake member in the device
specific data structure.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to the previous patch which implemented GEN specific reads; this
patch does the same for writes. Writes have a bit of adding complexity
due to the FPGA_DBG feature of HSW plus:
gen[2-4]: nothing special
gen5: ILK dummy write
gen[6-7]: forcewake shenanigans
gen[HSW}: forcewake shenanigans + FPGA_DBG
I was a bit torn about whether or not to combine 6-HSW as one function,
since the FPGA_DBG is cleanly separated, and it wouldn't make the 6-7
MMIO too messy. In the end, I chose the clearest possible solution which
splits out HSW.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Extracting the MMIO read functionality makes per gen handling a bit
simpler, and the overall function a lot easier to read. The increasing
complexity of reads doesn't get too bad as the generation number
increases:
gen[2-4]: Nothing special
gen5: ILK dummy write workaround
gen6+: forcewake shenanigans
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just to make the churn and code duplication in upcoming patches a bit
less, turn code which is common to all GEN MMIO functions into a macro.
v2: Fix typo in subject
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for having per GEN MMIO functions, create, and start
using MMIO functions in our uncore data structure. This simply makes the
transition easier by allowing us to just plug in the per GEN stuff
later.
For simplicity, I moved the intel_uncore_init() function down since
those rely on static functions defined lower in the file. This is most
of the churn in this patch.
I made one unrelated change here by using off_t datatype for the offset
of the register to write. I like the clarity that this brings to the
code. If I did it as a separate patch, I am pretty certain it would get
bikeshedded to oblivion.
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to be able to have virtual functions for the MMIO, we need to
use the raw access function. To keep things simple, just move this to
our early_sanitize code in uncore.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For upcoming patches which will have GEN specific MMIO functions, we'll
need to initialize the uncore data structure earlier than we do today.
If we do not do this, the following will be problematic:
intel_uncore_sanitize
intel_disable_gt_powersave
gen6_disable_rps
I915_WRITE(GEN6_RC_CONTROL, 0); <--- MMIO
intel_uncore_init // initializes MMIO
By initializing the function pointers first, we should be safe.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least on my i830M here it reliably results in hard system hangs
nowadays. This is much worse than falling back to software rendering,
so I think we should simply rip this out.
After all we don't have any gpu reset for gen3 either, and there are a
lot more of those still around.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In truly crazy circumstances shmem might give us the wrong type of
page. So be a bit paranoid and double check this.
Reviewer: Damien Lespiau <damien.lespiau@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
References: http://lkml.org/lkml/2011/7/11/238
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The PIPEA quirk is specifically for the issue with the PIPEB PLL on
830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA
running. i845 doesn't even have the second PLL or pipe, and enabling
the quirk results in a blank DVO LVDS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The policy's max frequency is not equal to the CPU's max frequency. The
ring frequency is derived from the CPU frequency, and not the policy
frequency.
One example of how this may differ through sysfs. If the sysfs max
frequency is modified, that will be used for the max ring frequency
calculation.
(/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq). As far as I
know, no current governor uses anything but max as the default, but in
theory, they could. Similarly distributions might set policy as part of
their init process.
It's ideal to use the real frequency because when we're currently scaled
up on the GPU. In this case we likely want to race to idle, and using a
less than max ring frequency is non-optimal for this situation.
AFAIK, this patch should have no impact on a majority of people.
This behavior hasn't been changed since it was first introduced:
commit 23b2f8bb92
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Jun 28 13:04:16 2011 -0700
drm/i915: load a ring frequency scaling table v3
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Flush the primary plane changes when enabling/disabling the primary
plane in response to sprite visibility.
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>
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>
The new names make it clearer which plane we're talking about.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Resolve small conflict with the haswell_crtc_disable_planes
extraction.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The intel_flush_primary_plane name actually tells us which plane
we're talking about.
Also reorganize the internals a bit and add a missing POSTING_READ()
to make sure the hardware has seen the changes by the time we
return from the function.
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>
IPS should be OK as long as one plane is enabled on the pipe, but
it does seem to cause problems when going between primary only and
sprite only.
This needs more investigations, but for now just disable IPS whenever
the primary plane is disabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Disable fbc before disabling the primary plane, and enable fbc after
the primary plane has been enabled again.
Also use intel_disable_fbc() to disable FBC to avoid the pointless
overhead of intel_update_fbc(), and especially avoid having to clean
up and set up the stolen mem compressed buffer again.
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>
If the setplane operation fails, we shouldn't save the user's requested
plane coordinates. Since we adjust the coordinates during the clipping
process, make a copy of the originals, and once the operation has
succeeded save them for later reuse when the plane gets re-enabled.
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>
Move the variable initialization to where the variables are declared,
and kill a pointless to_intel_crtc() cast when we already have the
casted pointer.
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>
Let's not use goto when a simple if suffices. This is not error handling
code or anything, so the goto looks out of place.
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 used to call the entire intel specific update_plane hook while
holding struct_mutex. Actually we only need to hold struct_mutex while
pinning/unpinning the obj. The plane state itself is protected by the
kms locks, and as the object is pinned we can dig out the offset and
tiling information from it without fearing that it would change
underneath us.
So now we don't need to drop and reacquire the lock around the
wait_for_vblank. Also we will need another wait_for_vblank in the IVB
specific update_plane hook, and this way we don't need to worry about
struct_mutex there either.
Also move the intel_plane->obj=NULL assignment outside strut_mutex in
disable_plane to make it clear that it's not protected by struct_mutex.
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 allow cursors to be set up when the pipe is disabled. Do the same for
sprites as well.
We need to be somewhat careful with the primary disable logic as we
don't want to accidentally enable the primary plane on a disabled pipe.
v2: Skip primary enable/disable and plane registers
writes on disabled pipe
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>
If the primary gets marked as disabled while the pipe is off for
instance, we should still re-enable it when the pipe is turned on,
unless the sprite covers it fully also in that configuration.
Unfortunately we do the plane visibility checks only in the sprite code,
which is executed after the primary enabling when turning the pipe off.
Ideally we should compute the plane visibility before touching the
hardware at all, but for now just set the primary_disabld flag
in intel_{enable,disable}_plane.
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>
If channel equalization succeeds, there's no indication something went
wrong in clock recovery (unless debug is enabled). We should shout about
the failures and fix them instead of hiding them under the carpet.
This has allowed bugs like [1] stay dormant for a long time.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=70117
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The VGACNTRL register contains a bunch of other stuff besides
the VGA_DISP_DISABLE bit. When we write the register we always set those
other bits to zero, so normally the current check would work.
However on HSW disabling and re-enabling the power well will reset the
VGACNTRL register to its default value, which has several of the other
bits set as well.
So only look at the VGA_DISP_DISABLE bit when checking whether the VGA
plane needs re-disabling.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Everyone else uses intel_PLL_is_valid(), so make VLV use it as well.
We don't have any special p and m limits on VLV, so skip those tests,
and we also need to skip the m1<=m2 test line PNV.
Reorganize the function a bit to move the n check alongside the rest of
the test for the non-derived dividers, and check the derived values
afterwards.
Note that this changes vlv_find_best_dpll() in two ways:
- The .vco comparison is now >max instead of >=max, and since we round
down when calculating that stuff, we may now allow frequencies slightly
above the max as we do on other platforms. The previous method
disallowed exactly max and anything above it.
- We now check the .dot frequency against the data rate limits, which we
didn't do before.
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>
If vlv_find_best_dpll() couldn't find suitable PLL settings,
just say so instead of lying to caller.
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>
After aligning the p1 divider limits, and removing the unused p and m
limits, intel_limits_vlv_dac and intel_limits_vlv_hdmi are identical.
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>
We don't use .dot_limit for anything on VLV, so don't populate it.
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>
We never check the p and m limits (which according to comments are
based on someone's guesswork), so just remove them.
VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm has no p and m
limits listed.
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>
VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm tells us that the
minimum p2 divider is 2. Use that limit on the code.
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>
According to VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm p1
can be 2-3 always.
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>
For some reason there's a sort of off by one issue with the p1 divider.
The actual p1 limits according to
VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm is 2-3, so we should
just say that instead of saying 1-3 and avoiding the 1 via the choice of
comparison operator.
I don't know why we're using different p1 limits for intel_limits_vlv_dac
and intel_limits_vlv_hdmi, but let's preserve that for now.
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>
We limit the maximum n divider value in order to make sure the PLL's
reference inout is at least 19.2 MHz. I assume that is done to satisfy
some hardware requirement.
However we never check whether that calculated limit is below the
maximum supoorted N divider value (7). In practice that is always true
since we only support 100 MHz reference clock, but making the code
safe against higher reference clocks seems like a reasoanble thing to
do.
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>
The p2 divider on VLV needs to be even when it's > 10. The current code
to make that happen is rather weird. Just make the step size adjustement
in the for loop decrement step.
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>
Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
an army of local variables.
Also extract the code to calculate the derived values into
vlv_clock().
v2: Split up the earlier fixes, extract vlv_clock()
v3: Initialize best_clock
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>
We do 'bestppm - 10' in vlv_find_best_dpll() but never check whether
that might underflow. Add such a check.
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>
Use div_u64() to make the ppm calculation in vlv_find_best_dpll() safe
against interger overflows.
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>
The interface uses an unsigned long, and we can use the unsigned counter
throughout our code, so do so. In the process, we notice one instance
where the shrink count is based on a heuristic rather than the result,
and another where we ask for too many pages to be purged.
v2: nr_to_scan needs to be promoted to a long as well, so just use
sc->nr_to_scan directly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we are waiting upon IO completion, inform the kernel through use
of the io_schedule() call rather than the regular schedule(). This
should allow the kernel to make better decisions regarding scheduling
and power management.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The conflict in intel_drv.h tripped me up a bit since a patch in dinq
moves all the functions around, but another one in drm-next removes a
single function. So I'ev figured backing this into a backmerge would
be good.
i915_dma.c is just adjacent lines changed, nothing nefarious there.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_drv.h
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's not really needed, rather just adds another place to hold
intermediate values that could go wrong, and it's not clear that the
training pattern set or training lane set should be written at this
point at all.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The user of these counters was killed in
commit d79cdc8312
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Aug 8 15:41:32 2013 +0200
drm: no-op out GET_STATS ioctl
so clean up the leftovers as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We can get the PCI vendor and device IDs via dev->pdev. So we can drop
the duplicated information.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_vblank_init() is too ugly. Make it a bit easier on the eye by
collecting all the per-crtc vblank counters, timestamps etc. to
a structure and just allocate an array of those.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
vblank_disable_allowed is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When booting with i915.fastboot=1, we always take tha code path and end
up undoing what we're trying to do with adjusted_mode.
Hopefully, as the fastboot hardware readout code is using adjusted_mode
as well, it should be equivalent.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of it just being on the mailing list, let's put Jesse's
explanation next to the code in question.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During system boot up, by default, the power gate for render, media and
display well still power gated. Normally, BIOS will turn off the power
gate. In the BIOS-less system, the driver need to turn off the power
gate very early during driver load.
v2: Move this to intel_uncore_sanitize to allow it to get call during
resume path. (Daniel)
v3: Remove redundant write 0 to DPIO_CTL, and use DPIO_RESET instead of
just 0x1 (Ville)
Add turn of power gate for display 2d/render well/media well.
v4: Remove toggle cmnreset in intel_uncore_sanitize. Cmnreset should
toggle after CRI clock source has been selected. Jesse DPIO reset patch
which toggle the cmnreset in intel_modeset_init_hw() should handle it.
(Ville)
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DPIO needs to have common reset de-asserted on soft resets like boot and
S3. In some cases, the BIOS will have done this for us, but it should
be safe to do at runtime as well, as long as we do it when the pipes are
otherwise off.
v2: update bit name to match docs better (Ville)
reset after CRI clock select (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=69166
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
for igt test case.
v2: remove trailing spaces and fix conflicts
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet:
- make it comipile
- s/IS_HASWELL/HAS_PSR/]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Power Well in use forces constantly PSR to exit.
On recent Kernel I noticed that PSR Performance Counter was always 0
indicating that PSR was never really achieved.
By masking LPSP, PSR can work normally and save power on Haswell.
Two bugs had been raised with PSR flag enabled:
- "Screen flickers when booted by enabling PSR in the kernel (i915.enable_psr=1) , the system is booting to a gray screen."
- "When booting the DUT with PSR feature enabled in the kernel (i915.enable_psr=1) , the system is booting to a gray screen."
Both bugs has been fixed by this patch.
v2: proper comment for -fixes
Tested-by: Selvaraj, Elavarasan <elavarasanx.selvaraj@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After applying wait-boost we often find ourselves stuck at higher clocks
than required. The current threshold value requires the GPU to be
continuously and completely idle for 313ms before it is dropped by one
bin. Conversely, we require the GPU to be busy for an average of 90% over
a 84ms period before we upclock. So the current thresholds almost never
downclock the GPU, and respond very slowly to sudden demands for more
power. It is easy to observe that we currently lock into the wrong bin
and both underperform in benchmarks and consume more power than optimal
(just by repeating the task and measuring the different results).
An alternative approach, as discussed in the bspec, is to use a
continuous threshold for upclocking, and an average value for downclocking.
This is good for quickly detecting and reacting to state changes within a
frame, however it fails with the common throttling method of waiting
upon the outstanding frame - at least it is difficult to choose a
threshold that works well at 15,000fps and at 60fps. So continue to use
average busy/idle loads to determine frequency change.
v2: Use 3 power zones to keep frequencies low in steady-state mostly
idle (e.g. scrolling, interactive 2D drawing), and frequencies high
for demanding games. In between those end-states, we use a
fast-reclocking algorithm to converge more quickly on the desired bin.
v3: Bug fixes - make sure we reset adj after switching power zones.
v4: Tune - drop the continuous busy thresholds as it prevents us from
choosing the right frequency for glxgears style swap benchmarks. Instead
the goal is to be able to find the right clocks irrespective of the
wait-boost.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we switched to always using a timeout in conjunction with
wait_seqno, we lost the ability to detect missed interrupts. Since, we
have had issues with interrupts on a number of generations, and they are
required to be delivered in a timely fashion for a smooth UX, it is
important that we do log errors found in the wild and prevent the
display stalling for upwards of 1s every time the seqno interrupt is
missed.
Rather than continue to fix up the timeouts to work around the interface
impedence in wait_event_*(), open code the combination of
wait_event[_interruptible][_timeout], and use the exposed timer to
poll for seqno should we detect a lost interrupt.
v2: In order to satisfy the debug requirement of logging missed
interrupts with the real world requirments of making machines work even
if interrupts are hosed, we revert to polling after detecting a missed
interrupt.
v3: Throw in a debugfs interface to simulate broken hw not reporting
interrupts.
v4: s/EGAIN/EAGAIN/ (Imre)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Don't use the struct typedef in new code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We missed adding a few cleanup steps for recent additions.
Reviewer: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch attempts to clean up the ring/IA scaling programming in the
following ways.
1. Fix the comment about the DDR frequency. The math is 266MHz, not
133MHz. Formula was right, docs are wrong.
2. Mask the DCLK register since I don't know how it is defined on future
platforms.
3. use mult_frac instead of magic math.
This helps for future platform enabling.
v2: Actually use the right patch. The v1 was a mix of things, none of
which was right. Note that due to rounding, we actually get different
values (slightly higher) for the effective ring frequency.
v3: Use 1.25 instead of 1.33 as the original code did. (Jesse)
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we ever end up doing the retry loop due to bandwidth constraints, we
would rewrite pipe_src_{w,n} based on adjusted_mode timings. But by that
time the encoder may have already replaced the adjusted_mode with a
fixed panel mode, which would then corrupt pipe_src_{w,h}.
v2: Use requested_mode and slap on a big comment from Daniel
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This workaround is described in the mode set sequence documentation.
When enabling planes for the second pipe, we need to wait for 2
vblanks on the first pipe. This should solve "a flash of screen
corruption if planes are enabled on second/third pipe during the time
that big FIFO mode is exiting". Watermarks are fun :)
v2: Save indentation levels
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>
Refactor the plane enabling/disabling into helper functions and move
the calls to happen as the first thing during .crtc_disable, and the
last thing during .crtc_enable.
Those are the two clear points where we are sure that the pipe is
actually running regardless of the encoder type or hardware
generation.
v2: Made by Paulo:
Remove the code touching everything but the Haswell functions. We
need this change on Haswell right now since it fixes a FIFO underrun
that we get on pipe A while we enable pipe B (see the workaround
notes on the Haswell mode set sequence documentation). We can bring
back the code to gens 2-7 later, once they're tested.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The global integrated clock source bit resides in DPLL B on VLV, but we
were treating it as a per-pipe resource. It needs to be set whenever
any PLL is active, so pull setting the bit out of vlv_update_pll and
into vlv_enable_pll. Also add a vlv_disable_pll to prevent disabling it
when pipe B shuts down.
I'm guessing on the references here, I expect this to bite any config
where multiple displays are active or displays are moved from pipe to
pipe.
v2: re-add bits in vlv_update_pll to keep from confusing the state checker
v3: use enum pipe checks (Daniel)
set CRI clock source early (Ville)
consistently set CRI clock source everywhere (Ville)
v4: drop unnecessary setting of bit in vlv enable pll (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=67245
References: https://bugs.freedesktop.org/show_bug.cgi?id=69693
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/1/PIPE_B/]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise using any atomic memory operation will lock up the GPU due
to a Haswell hardware bug.
v2: Use the _MASKED_BIT_ENABLE macro. Drop drm parameter definition.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: <stable@vger.kernel.org>
[danvet: Fix checkpatch fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During driver loading we are initializing rps.vlv_work in
valleyview_enable_rps() via the rps.delayed_resume_work delayed work.
This is too late since we are using vlv_work already via
i915_driver_load()->intel_uncore_sanitize()->
intel_disable_gt_powersave(). This at least leads to the following
kernel warning:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Fix this by initialzing vlv_work before we call intel_uncore_sanitize().
The regression was introduced in
commit 7dcd2677ea
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Wed Jul 17 10:22:58 2013 +0400
drm/i915: fix long-standing SNB regression in power consumption
after resume
though there was no good reason to initialize the static vlv_work from
another delayed work to begin with (especially since this will happen
multiple times).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69397
Tested-by: shui yangwei <yangweix.shui@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For some reason, every single time I try to run module_reload
something tries to read the connector sysfs files. This happens
after we destroy the encoders and before we destroy the connectors, so
when the sysfs read triggers the connector detect() function,
intel_conector->encoder points to memory that was already freed.
The bad backtrace is just:
[<ffffffff8163ca9a>] dump_stack+0x54/0x74
[<ffffffffa00c2c8e>] intel_dp_detect+0x1e/0x4b0 [i915]
[<ffffffffa001913d>] status_show+0x3d/0x80 [drm]
[<ffffffff813d5340>] dev_attr_show+0x20/0x60
[<ffffffff81221f50>] ? sysfs_read_file+0x80/0x1b0
[<ffffffff81221f79>] sysfs_read_file+0xa9/0x1b0
[<ffffffff811aaf1e>] vfs_read+0x9e/0x170
[<ffffffff811aba4c>] SyS_read+0x4c/0xa0
[<ffffffff8164e392>] system_call_fastpath+0x16/0x1b
But if you add tons of memory checking debug options to your Kernel
you'll also see:
- general protection fault: 0000
- BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten
- INFO: Allocated in intel_ddi_init+0x65/0x270 [i915]
- INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915]
Among a bunch of other error messages.
So this commit just destroys the sysfs files before both the encoder
and connectors are freed.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Neither the DP spec nor the compliance test spec state or imply that we
should write the DP_TRAINING_PATTERN_SET at every voltage swing and
pre-emphasis change. Indeed we probably shouldn't. So don't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Smoke-tested-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>
Per DP1.2 spec.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It indicates a probable BIOS bug, but it appears to be harmless, and
there's nothing the user can do about it anyway, so reduce to a debug
msg. I've filed a bug with the BIOS folks about it anyway, so hopefully
they'll fix whatever GT SB read they were doing when the GT was off.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69396
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to use the clock control reg to figure out how many CZ clks are in
30ns and use that as the basis for our RC6 residency calculations.
v2: use ULL everywhere for consistency (Chris)
factor out bias for clarity (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=69692
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And add some reg defines while we're at it. Since the units of the RC6
residency counter are actually in CZ clocks, we want to just use the
high bits or we'll overflow too frequently.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
vlv_find_best_dpll() has an open coded DIV_ROUND_CLOSEST(). Replace it
with the real thing.
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>
Use 'continue' to get rid of one indent level in vlv_find_best_dpll()
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>
CDCLK is used to generate the gmbus clock. This is normally done by
BIOS. Program the value if the BIOS-less system doesn't do it.
v2: Move this to intel_i2c_reset to allow reprogram the gmbus frequency
during resume. (Daniel)
v3: Change GMBUS_FREQ to GMBUSFREQ_VLV, and use VLV_DISPLAY_BASE.
(Ville).
Remove cdclk_ratio[] table, and calculate the cdclk ratio instead.
(Ville).
Change the shift then mask for reg read, to mask first, then shift.
(Ville).
Remove the gmbus frequency calculation = cdclk/1.01. Based on BIOS
programming, gmbus frequency = cdclk frequency. (Ville)
Add get_disp_clk_div, which can use to get cdclk/czclk divide.
v4: Fix the mmio_offset base for CZCLK_CDCLK_FREQ_RATIO, gmbus_freq
calculation, and duplicate check for gmbus_freq. (Ville)
In VLV, the spec is wrong about 4Mhz reference frequency for GMBUS. It
should be 1Mhz.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
[danvet: Add the comment Ville suggested. Also appease checkpatch a
bit.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Still digging up the actual VBT info for this, but wanted to get this
out there for testing, or in case others are also bugged by this.
This can happen if you boot with an external display connected. In that
case, the attached eDP backlight modulation frequency may not be
programmed, so we need to use something (in this case the value my BIOS
normally programs with just the internal display enabled).
v2: fix masking and magic value in read_blc_pwm_ctl (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67732
Tested-by: shui yangwei <yangweix.shui@intel.com> (v1)
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we ask to adjust the crtc timings for stereo modes, the correct
pipe_src_w and pipe_src_h can be found in crtc_vdisplay and crtc_hdisplay.
v2: Add comment about why pipe_src_w/h need to be set afert
set_crtcinfo() (Daniel Vetter)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When scanning out big stereo buffers that are actually bigger that their
natural 2D counterpart, we need to blow up the crtc timings as well.
Not that this is only done for frame packing as this is the only stereo
mode currently exposed needing this kind of ajdustements.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
struct drm_mode_display now has a separate crtc_ version of the clock to
be used when we're talking about the timings given to the harwadre (was
far as the mode is concerned).
This commit is really the result of a git grep adjusted_mode.*clock and
replacing those by adjusted_mode.crtc_clock. No functional change.
v2: Rebased on drm-intel-queued-next
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to dump the parameters given to the hardware, so let's use
crtc_clock here.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With some divider values we end up with the wrong result. So remove the
intermediates (like Ville suggested in the first place) to get the right
answer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Calculation is a little different than other platforms.
v2: update to use port_clock instead
rebase on top of Ville's changes
v3: update to new port_clock semantics - don't divide by
pixel_multiplier (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=67345
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!
v2: Rebrand it as a ring event, rather than an object event.
v3: Include the seqno in the tracepoint for posterity or something.
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>
Add the missing cache-level to the describe_obj() function for debug and
error reporting.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix the typo in previous commit for DP 1.62 divisor.
drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2
v2: sigh, the m1 div is 3.
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only wish to know the value of seqno when emitting the tracepoint, so
move the query from a parameter to the macro to inside the conditional
macro body so that the query is only evaluated when required.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even though we track object activity and not VMA, because we have the
active_list be based on the VM, it makes the most sense to use VMAs in
the APIs.
NOTE: Daniel intends to eventually rip out active/inactive LRUs, but for
now, leave them be.
v2: Remove leftover hunk from the previous patch which didn't keep
i915_gem_object_move_to_active. That patch had to rely on the ring to
get the dev instead of the obj. (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
"We do fairly often lookup the ggtt vma for an obj." - Chris Wilson. As
such, provide a function to offer slightly cheaper access to the vma.
Not performance tested. By my quick estimation it saves at least 3
pointer dereferences from the existing mechanism.
This patch mostly matches code from Chris in
<20130911221430.GB7825@nuc-i3427.alporthouse.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tracing vm eviction is really the event we care about. For the cases we
evict everything, we still will get the trace.
v2: Add the drm device to the trace since we might not be the only
device in the system. (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since I already reorganized the header file, Daniel requested me to
remove those keywords. It seems "checkpath.pl --strict" also doesn't
like "extern" on header files.
At least now we're consistent :)
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions were added before the final PC8 implementation, and
their callers moved to intel_display.c during the code review.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And move it so it doesn't need a forward declaration.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also move it to the top of the file so we can remove the forward
declaration.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel complained that we keep adding stuff to the bottom of the file,
so we constantly have conflicts. So reorganize everything and split
them file-by-file, also sorting the files in alphabetical order. This
way, patches touching different files will have a smaller chance of
conflicting. Of course, this commit will conflict with everybody on
the list :)
Also remove a few useless comments and make some things fit into 80
lines.
v2: - Conflict with intel_ddi_get_config
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not valid for later non-PCH split platforms such as VLV.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Call intel_ddi_get_config() to get the pipe_bpp settings from
DDI.
The sync polarity settings from DDI are irrelevant for CRT
output, so override them with data from the ADPA register.
v2: Extract intel_crt_get_flags()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691
Tested-by: Qingshuai Tian <qingshuai.tian@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Flat out skip anything to do with PLL if we have a DSI encoder (and thus
DSI PLL). Also skip PLL computation if the encoder has already set
clocks. This allows for some tidying up of the code, including a
superfluous call to intel_limit() for LVDS downclock path.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During SDVO initialisation it would be useful to a have a record of the
individual devices we try to enable and later probe - in particular to
be able to see which fail.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Obtaining the forcwake requires expensive and time consuming
serialisation. And we often try to obtain the forcewake multiple times
in very quick succession. We can reduce the overhead of these sequences
by delaying the forcewake release, and so not hammer the hw quite so
hard.
I was hoping this would help with the spurious
[drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
found on Haswell. Alas not.
v2: Fix teardown ordering - unmap the regs after turning off forcewake,
and make sure we do turn off forcewake - both found by Ville.
v3: As we introduce intel_uncore_fini(), use it to make sure everything
is disabled before we hand back to the BIOS.
Note: I have no claims for improved performance, stablity or power
comsumption for this patch. We should not be hitting the registers often
enough for this to improve benchmarks, but given the nature of our hw it
is likely to improve long term stability.
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>
The | operation has higher precedence than "?:" so the macro always
returns GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1.
This regression has been introduce in "drm/i915: Add second slice l3
remapping".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i9xx_crtc_clock_get() no longer populates adjusted_mode.clock, so we
must get the pixel clock from port_clock in intel_crtc_mode_get().
This bug caused Chris's 845g machine to lockup during boot, and it
was introduced in:
commit 18442d0878
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Sep 13 16:00:08 2013 +0300
drm/i915: Fix port_clock and adjusted_mode.clock readout all over
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69713
Tested-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>
Future generations will be changing these registers (thanks to design
for giving us an early heads up). To help abstract, create the
definition of the base of the register block, and define all registers
relative to that.
Design has promised to not change the offsets relative to the base.
v2: Also change IS_HASWELL checks to HAS_PSR
CC: Rodrigo Vivi <rodrigo.vivi@gmail.com>
CC: Intel GFX <intel-gfx@lists.freedesktop.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reduce AUX transactions for non-eDP.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already restore planes during the modeset operation, so no need to do
another loop over the planes and try to restore them again.
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>
Call intel_uncore_early_sanitize() first thing during resume to prevent
stale BIOS leftovers from being reported as unclaimed register access.
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>
i915_restore_state() -> i915_restore_display() will attempt to
re-disable VGA during resume. So the power well needs to be powered on
before that.
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>
intel_modeset_init() will already attempt to disable VGA. In order to do
that, it needs the power well to be on. So move the power well init
to happen before intel_modeset_init() during driver load.
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>
The VGA plane needs to be disabled before we start doing any
modeset operations on resume.
This should also guarantee that the power well will be enabled
when we call i915_redisable_vga() since it gets explicitly powered on
during resume, and will get powered back off during the modeset
operation if no longer needed.
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>
VGA registers live inside the power well on HSW, so in order to write
the VGA MSR register we need the power well to be on.
We really must write to the register to properly clear the
VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when
the power well is down. It seems that the implicit zeroing done by
the power well is not enough to propagate the VGA_MSR_MEM_EN bit to
whomever is actually responsible for the memory decode ranges.
If we leave VGA memory decode enabled, and then turn off the power well,
all VGA memory reads will return zeroes. But if we first disable VGA
memory deocde and then turn off the power well, VGA memory reads
return all ones, indicating that the access wasn't claimed by anyone.
For the vga arbiter to function correctly the IGD must not claim the
VGA memory accesses.
Previously we were doing the VGA_MSR register access while the power well
was excplicitly powered up during driver init. But ever since
commit 6e1b4fdad5
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Sep 5 20:40:52 2013 +0300
drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done
we delay the VGA memory disable until fbcon has initialized, and so
there's a possibility that the power well got turned off during the
fbcon modeset. Also vgacon_save_screen() will need the power well to be
on to be able to read the VGA memory.
So immediately after enabling the power well during init grab a refence
for VGA purposes, and after all the VGA handling is done, release it.
v2: Add intel_display_power_put() for the num_pipes==0 case
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix up the patch wiggle screw-up that I've done and which
Paulo catched. Also polish spelling in the patch headline.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It only controls the setting of the vbt.edp_support variable, which in
turn only controls one debug output plus can also force-disable the
lvds output.
Since the value only restricted this logic to mobile ilk there's the
slight risk that this will break lvds on desktop ilk or on snb/ivb
platforms. But with the vbt it's better when we know what's going on
here, so let's rip it out and see what happens.
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no reason to init a DP connector if the encoder just supports
HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
AUX transactions to detect if there's something there. Same goes for a
DP connector that doesn't support HDMI, but I'm not sure these
actually exist.
v2: - Use bit fields
- Remove useless identation level
- Replace DRM_ERROR with DRM_DEBUG_KMS
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our code makes a lot of assumptions regarding what each DDI port
actually supports, and the VBT should tell us what is really happening
in the hardware. So parse the information provided by the VBT and
check if any of our assumptions is wrong.
Our driver also has a history of not really trusting the VBT, so a
WARN here could mean that:
a) our coding assumptions are wrong
b) the VBT is wrong
c) we're incorrectly parsing the VBT
d) the checks are wrong
But I really hope we won't ever trigger any of those WARNs.
v2: Don't check the redundant "Capabilities" field from byte 24 since
it doesn't seem to be used.
v3: Rebase
v4: Replace WARN with DRM_DEBUG_KMS
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our code currently assumes that port X will use the DP AUX channel X
and the DDC pin X. The VBT should tell us how things are mapped, so
add some WARNs in case we discover our assumptions are wrong (or in
case the VBT is just wrong, which is also perfectly possible).
Why would someone wire port B to AUX C and DDC D?
v2: Rebase
v3: Convert WARNs to DRM_DEBUG_KMS
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently use the recommended values from BSpec, but the VBT
specifies the correct value to use for the hardware we have, so use
it. We also fall back to the recommended value in case we can't find
the VBT.
In addition, this code also provides some infrastructure to parse more
information about the DDI ports. There's a lot more information we
could extract and use in the future.
v2: - Move some code to init_vbt_defaults.
v3: - Rebase
- Clarify the "DVO Port" matching code
v4: - Use I915_MAX_PORTS
- Change the HAS_DDI checks
- Replace DRM_ERROR with DRM_DEBUG_KMS
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently treat the child_device_config as a simple struct, but
this is not correct: new BDB versions change the meaning of some
offsets, so the struct needs to be adjusted for each version.
Since there are too many changes (today we're in version 170!), making
a big versioned union would be too complicated, so child_device_config
is now a union of 3 things: (i) a "raw" byte array that's safe to use
anywhere; (ii) an "old" structure that's the one we've been using and
should be safe to keep in the SDVO and TV code; and (iii) a "common"
structure that should contain only fields that are common for all the
known VBT versions.
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>
