- 01 Oct, 2013 40 commits
-
-
Damien Lespiau authored
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ä <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>
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
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: -
Damien Lespiau authored
Just like the various timings, make it possible to have a clock field what we can tweak before giving it to hardware. Reviewed-by:
-
Damien Lespiau authored
This field is unused. Garbage collect it. Reviewed-by:
-
Damien Lespiau authored
This field was only accessed by the nouveau driver, but never set. So concluded we can rid of this one. Acked-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
This allows to expose the alternate clock versions of the stereo modes. Reviewed-by:
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
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: -
Damien Lespiau authored
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:
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
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 <dh.herrmann@gmail.com> (for v2) Signed-off-by: -
Chris Wilson authored
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:
-
Jesse Barnes authored
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=67345Signed-off-by: -
Chris Wilson authored
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 authored
Add the missing cache-level to the describe_obj() function for debug and error reporting. Signed-off-by:
-
Chon Ming Lee authored
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:
Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by:
-
Chris Wilson authored
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:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Ben Widawsky authored
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:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
"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:
-
Ben Widawsky authored
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:
-
Paulo Zanoni authored
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:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
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 authored
By moving them to intel_fb.c. Signed-off-by:
-
Paulo Zanoni authored
And move it so it doesn't need a forward declaration. Signed-off-by:
-
Paulo Zanoni authored
Also move it to the top of the file so we can remove the forward declaration. Signed-off-by:
-
Paulo Zanoni authored
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:
-
Jani Nikula authored
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ä authored
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=69691Tested-by:
Qingshuai Tian <qingshuai.tian@intel.com> Signed-off-by:
-
Jani Nikula authored
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:
-
Chris Wilson authored
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 authored
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:
-
Dan Carpenter authored
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:
-
Ville Syrjälä authored
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 18442d08 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=69713Tested-by:
-
Ben Widawsky authored
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:
-
