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ä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Some stereo modes, like frame packing, need a larger CRTC viewport than
the "natural" underlying 2D mode and thus drm_crtc_check_viewport()
needs to query the adjusted mode to use the correct h/vdisplay.
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Both setcrtc and page_flip are checking that the framebuffer is big
enough for the defined crtc viewport (x, y, hdisplay, vdisplay). Factor
that code out in a single function.
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.
v2: Use crtc_vtotal and multiply the clock by 2 instead of
reconstructing it (Ville Syrjälä)
Suggested-by: Daniel Vetter <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Just like the various timings, make it possible to have a clock field
what we can tweak before giving it to hardware.
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Just like with interlaced or double scan modes, make stereo modes a
per-connector opt-in to give a chance to driver authors to make it work
before enabling it.
Suggested-by: Daniel Vetter <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.
v2: Make s3d_structure_from_display_mode() less subtle (Ville Syrjälä)
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
When setting a stereo 3D mode, there can be only one bit set describing
the layout of the frambuffer(s). So reject invalid modes early.
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
So we respect a nice design of having similar functions at the same
level, in this case:
do_hdmi_vsdb_modes()
- add_hdmi_mandatory_stereo_modes()
- add_hdmi_mode()
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx
v2: Rename freq to vrefresh, make the mandatory structure a bit more
compact, fix some white space issues and add a couple of const
(Ville Syrjälä)
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
This capability allows user space to control the delivery of modes with
the 3D flags set. This is to not play games with current user space
users not knowing anything about stereo 3D flags and that could try
to set a mode with one or several of those bits set.
So, the plan is to remove the stereo modes from the list of modes we
give to DRM clients by default, and let them through if we are being
told otherwise.
stereo_allowed is bound to the drm_file structure to make it a
per-client setting, not a global one.
v2: Replace clearing 3D flags by discarding the stereo modes now that
they are regular modes.
v3: SET_CAP -> SET_CLIENT_CAP rename (Chris Wilson)
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
HDMI 1.4a defines a few layouts that we'd like to expose. This commits
add new modeinfo flags that can be used to list the supported stereo
layouts (when querying the list of modes) and to set a given stereo 3D
mode (when setting a mode).
v2: Add a drm_mode_is_stereo() helper
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
This ioctl can be used to turn some knobs in a DRM driver. The client
can ask the DRM core for an alternate view of the reality: it can be
useful to be able to instruct the core that the DRM client can handle
new functionnality that would otherwise break current ABI.
v2: Rename to ioctl from SET_CAP to SET_CLIENT_CAP (Chris Wilson)
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
It's a tiny bit more logical to find the different capabilities you can
use with the GET_CAP ioctl next to the structure rather than putting
them at the end of the file.
v2: Tab align the litterals (David Herrmann)
v3: Make it clearer that DRM_PRIME_CAP_EXPORT/IMPORT are flags of
DRM_CAP_PRIME.
v4: Rebase on top of latest bits (DRM_CAP_ASYNC_PAGE_FLIP was
introduced)
Reviewed-by: David Herrmann <[email protected]> (for v2)
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Add the missing cache-level to the describe_obj() function for debug and
error reporting.
Signed-off-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Chon Ming Lee <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
"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
<[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Also move it to the top of the file so we can remove the forward
declaration.
Signed-off-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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ä <[email protected]>
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 <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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 <[email protected]>
CC: Intel GFX <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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ä <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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ä <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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ä <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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ä <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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ä <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
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ä <[email protected]>
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ä <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
[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 <[email protected]>
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 <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
