Only two patches this time around. One trivial and one locking fix.
* 'gma500-next' of git://github.com/patjak/drm-gma500:
drm/gma500: Lock struct_mutex around cursor updates
drivers: gpu: Mark function as static in cdv_intel_dp.c
Add a few new debugfs files which allow changing the watermark memory
latency values during runtime. This can be used to determine the if the
original BIOS provided latency values are no good.
v2: Drop superfluous plane name from output
Take modeset locks around the latency value read/write
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Damien Lespiau <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Only early VLV steppings needed thist. Should no longer be relevant.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
WaApplyL3ControlAndL3ChickenMode is only relevant to early HSW
steppings..
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
WaDisableRCZUnitClockGating was needed with early HSW steppings only.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Someone copy pasted the comment from the SNB code w/o reading it.
We never actually implemented the workaround to disable RCPB unit
clock gating on IVB. It would have been needed for early steppings,
but we don't care about those anymore, so just remove the stale
comment.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Can't find any mention of WaDisableVDSUnitClockGating ever being
relevant for SNB. Remove it.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
There are cases where we want to know if there is a full, or aliased
PPGTT. Currently, in fact the only distinction we ever need to make is
when we're using full PPGTT.
This patch is simply to promote readability and clarify for the
confusing existing usage where "aliasing" meant aliasing and full.
v2: Remove USES_ALIASING_PPGTT since there are currently no cases where
we need to check if we're using aliasing, but not full PPGTT. (Daniel)
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
The 'offset' field of the 'scatterlist' structure was wrongly
programmed with the offset value from the base of stolen area,
whereas this field indicates the offset from where the interested
data starts within the first PAGE pointed to by 'scattterlist'
structure. As a result when a new GEM object allocated from stolen
area is mapped to GTT, it could lead to an overwrite of GTT entries
as the page count calculation will go wrong, refer the function
'sg_page_count'.
v2: Modified the commit message. (Chris)
Signed-off-by: Akash Goel <[email protected]>
Reviewed-by: Jesse Barnes <[email protected]>
Cc: [email protected]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71908
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69104
Signed-off-by: Daniel Vetter <[email protected]>
Commit 92b6f89f6b8f (drm: Add separate Kconfig option for fbdev helpers)
happened in parallel with the inclusion of Armada DRM into mainline,
and so missed this update. Add the necessary select statement to avoid
build errors.
Signed-off-by: Russell King <[email protected]>
Having to use i915.i915_foo is inconsistent and a bit on the verbose
side. Drop the prefix per Daniel's request, who also says this is not
ABI we need to maintain.
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
At least I couldn't find it in the Haswell Bspec any more and we've
tried to test-boot a Haswell machine with num_pipes forced to 0 (i.e.
hit the PCH_NOP path) and the unclaimed register logic complained.
So restrict this dance to just ivb platforms.
v2: Art pointed out that the bits simply moved on hsw+
v3: Buy code terseneness with a notch of sublety as suggested by
Chris.
v4: Frob the right bit, spotted by Art.
Cc: Chris Wilson <[email protected]>
Cc: Arthur Ranyan <[email protected]>
Cc: Dave Airlie <[email protected]>
Reviewed-by: Art Runyan <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
A lot of the WM functions are only reading from that structure and are
already using const. While converting the code to use dev_priv instead
of dev, I noticed a few places where we can give that hint.
Signed-off-by: Damien Lespiau <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.
Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".
The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:
$ git grep "i915\." -- drivers/gpu/drm/i915
v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
WaMiSetContext_Hang tells us that a MI_NOOP must follow MI_SET_CONTEXT.
The other thing WaMiSetContext_Hang seems to say is that URB_FENCE isn't
allowed to straddle two cachelines. But we don't issue those from the
kernel so we don't care.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
WaApplyL3ControlAndL3ChickenMode is only listed for IVB and HSW in
W/A database and BSpec.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
The w/a database lists both WaPsdDispatchEnable and
WaDisablePSDDualDispatchEnable for VLV. They appear to be the same
thing, so list both names.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Many times in the past we have concluded that the cause of the GPU hang
has been that the hw status page was stale, usually because the GPU and
CPU disagreed over the address of the page. Having stumbled across yet
another issue that seems to be related to the HWSP, it is time to
include that information in the GPU error dump.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Currently we report through our error state only the rings that have
been initialised (as detected by ring->obj). This check is done after
the GPU reset and ring re-initialisation, which means that the software
state may not be the same as when we captured the hardware error and we
may not print out any of the vital information for debugging the hang.
This (and the implied object leak) is a regression from
commit 3d57e5bd12
Author: Ben Widawsky <[email protected]>
Date: Mon Oct 14 10:01:36 2013 -0700
drm/i915: Do a fuller init after reset
Note that we are already starting to get bug reports with incomplete
error states from 3.13, which also hampers debugging userspace driver
issues.
v2: Prevent a NULL dereference on 830gm/845g after a GPU reset where
the scratch obj may be NULL.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Ben Widawsky <[email protected]>
Cc: Ville Syrjälä <[email protected]>
References: https://bugs.freedesktop.org/show_bug.cgi?id=74094
Cc: [email protected] # please don't delay since it's a
vital support/debug feature for the intel gfx stack in general
Reviewed-by: Ville Syrjälä <[email protected]>
[danvet: Add a bit of fluff to make it clear we need this expedited in
stable.]
Signed-off-by: Daniel Vetter <[email protected]>
This debugfs interface will allow intel-gpu-tools test case
to verify if screen has been updated properly on cases like PSR.
v2: Accepted all Daniel's suggestions:
* grab modeset lock
* loop over connector and check DPMS on
* return errors
* use _eDP1 suffix for easy future extension
* don't cache crc_supported neither latest crc
* return crc as a full array and read it at once with aux.
* use 0 to turn TEST_SINK off.
* split the drm_helpers definitions in another patch.
v3: Accepted 2 Damien's suggestion: remove h from printf hexa
and return ENODEV when eDP not present instead of EAGAIN.
v4: Accepted 2 Jani' s suggestion: 1 path for unlock and remove
_retry from aux read.
v5: removing last missing useless _retry (by Damien)
Cc: Daniel Vetter <[email protected]>
Cc: Damien Lespiau <[email protected]>
Cc: Jani Nikula <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Damien Lespiau <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
This address will be used to verify panel CRC for test and
validation purposes.
Signed-off-by: Rodrigo Vivi <[email protected]>
[danvet: Fix whitespace fail.]
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Having a 4 byte register at 0x321b seems unlikely as that's not
4 byte aligned. Since later platforms have more or less the same FBC
registers with new names, assume that FBC_FENCE_OFF is at 0x3218 just
like DPFC_FENCE_YOFF.
This feels like a simple typo in BSpec. 321Bh looks a lot like 3218h
after all.
Should still be tested on real hardware of course. But I don't have
any mobile gen4 systems.
Signed-off-by: Ville Syrjälä <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
The debug message telling FBC1 has been enabled is missing a newline.
Add it.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
On CTG and IVB+ we don't try to preserve any bits from the
DPFC_CONTROL register. Follow suit on ILK/SNB.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
We will anyway re-enable FBC normally after resume, so trying to save
and restore the register makes little sense.
We do need to preserve the FBC1 interval bits in FBC_CONTROL since
we only initialize them during driver load, and try to preserve them
after that.
v2: s/I915_HAS_FBC/HAS_FBC/ and fix the check for gen4
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
We set up all the bits for DPFC_CONTROL but forgot to actually
write them to the register. Oops.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
The ILK/SNB docs don't really mention the the DPFC_HT_MODIFY bit.
CTG docs clearly state that it should be set only when tracking
back buffer modification in persistent mode. The bit is supposed
to be set by software after the first CPU modification to the
back buffer, and it would get automagically cleared by the hardware
on the next page flip.
Since we only track front buffer modification we don't need to set
this bit. GTT modification tracking still appears to work on ILK
and SNB with the bit unset. I don't have a CTG to verify how that
behaves.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
The ILK/SNB docs are a bit unclear what the persistent mode does, but
the CTG docs clearly state that it was meant to be used when we're
tracking back buffer modifications. We never do that, so leave it in
non-persistent mode.
Signed-off-by: Ville Syrjälä <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
We use nuking instead of render tracking on IVB+, so there's
no point in writing IVB_FBC_RT_BASE.
v2: Drop the IVB_FBC_RT_BASE write too
v3: Move the SNB stuff elsewhere, leaving only IVB+ here
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Because whatever.*
* This should contain a fairly long list of issues and still
unresolved resgressions, but I didn't really get a vote.
Signed-off-by: Daniel Vetter <[email protected]>
I want to see these without having full debugs enabled.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
[danvet: fix the gen8 irq handler as spotted by Paulo in his review.]
Signed-off-by: Daniel Vetter <[email protected]>
Currently we print all pipe underruns on GMCH platforms. Hook up the
same logic we use on PCH platforms where we disable the underrun
reporting after the first underrun.
Underruns don't actually generate interrupts themselves on GMCH
platforms, we just can detect them whenever we service other
interrupts. So we don't have any enable bits to worry about. We just
need to remember to clear the underrun status when enabling underrun
reporting.
Note that the underrun handling needs to be moved to the non-locked
pipe_stats[] loop in the interrupt handlers to avoid having to rework
the locking in intel_set_cpu_fifo_underrun_reporting().
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
This is useful for debugging as we then know that the first entry is
always the global GTT, and all later entries the per-process GTT VM.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Not removing pm qos request and free memory for it can cause crash,
when some other driver use pm qos. For example, this oops:
BUG: unable to handle kernel paging request at fffffffffffffff8
IP: [<ffffffff81307a6b>] plist_add+0x5b/0xd0
Call Trace:
[<ffffffff810acf25>] pm_qos_update_target+0x125/0x1e0
[<ffffffff810ad071>] pm_qos_add_request+0x91/0x100
[<ffffffffa053ec14>] e1000_open+0xe4/0x5b0 [e1000e]
was caused by earlier i915 probe failure:
[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00003004 tail 00000000 start 00003000
[drm:i915_driver_load] *ERROR* failed to init modeset
i915: probe of 0000:00:02.0 failed with error -5
Bug report:
http://bugzilla.redhat.com/show_bug.cgi?id=1057533
Reported-by: Giandomenico De Tullio <[email protected]>
Cc: [email protected]
Signed-off-by: Stanislaw Gruszka <[email protected]>
[danvet: Drop unnecessary code movement.]
Signed-off-by: Daniel Vetter <[email protected]>
Forgot to convert to using the refclk variable when I added refclk
readout support, and Paulo noticed the resulting calculation was off due
to the way p & r are stored.
Reported-by: Paulo Zanoni <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Tested-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
This statenment became false here:
commit 4fc688ce79
Author: Jesse Barnes <[email protected]>
Date: Fri Nov 2 11:14:01 2012 -0700
drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex
Signed-off-by: Ben Widawsky <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Now that we have DDI support, we can check these all the time.
Signed-off-by: Jesse Barnes <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
