summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-10-01drm: Make exposing stereo modes a per-connector opt-inDamien Lespiau
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 <daniel.vetter@ffwll.ch> 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>
2013-10-01drm: Carry over the stereo flags when adding the alternate modeDamien Lespiau
This allows to expose the alternate clock versions of the stereo modes. 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>
2013-10-01drm: Make drm_match_cea_mode() return the underlying 2D VIC for 3d modesDamien Lespiau
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ä <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>
2013-10-01drm: Set the relevant infoframe field when scanning out a 3D modeDamien Lespiau
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ä <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>
2013-10-01drm: Reject modes with more than 1 stereo flags setDamien Lespiau
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ä <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>
2013-10-01drm: Extract add_hdmi_mode() out of do_hdmi_vsdb_modes()Damien Lespiau
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ä <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>
2013-10-01drm/edid: Expose mandatory stereo modes for HDMI sinksDamien Lespiau
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ä <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>
2013-10-01drm: Add a STEREO_3D capability to the SET_CLIENT_CAP ioctlDamien Lespiau
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ä <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>
2013-10-01drm: Add HDMI stereo 3D flags to struct drm_mode_modeinfoDamien Lespiau
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ä <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>
2013-10-01drm: Add a SET_CLIENT_CAP ioctlDamien Lespiau
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ä <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>
2013-10-01drm: Move the GET_CAP macros next to the corresponding ioctl structureDamien Lespiau
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: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915/vlv: fix up broken precision in vlv_crtc_clock_getChris Wilson
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>
2013-10-01drm/i915/vlv: add VLV specific clock_get function v3Jesse Barnes
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>
2013-10-01drm/i915: Add a tracepoint for using a semaphoreChris Wilson
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>
2013-10-01drm/i915: Show WT caching in debugfsChris Wilson
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>
2013-10-01drm/i915: Fix VLV eDP timing v2Chon Ming Lee
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>
2013-10-01drm/i915: Move the conditional seqno query into the tracepointChris Wilson
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>
2013-10-01drm/i915: Convert active API to VMABen Widawsky
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>
2013-10-01drm/i915: Provide a cheap ggtt vma lookupBen Widawsky
"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>
2013-10-01drm/i915: trace vm eviction instead of everythingBen Widawsky
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>
2013-10-01drm/i915: remove "extern" keywords from intel_drv.h functionsPaulo Zanoni
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>
2013-10-01drm/i915: make hsw_{disable, restore}_lcpll staticPaulo Zanoni
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>
2013-10-01drm/i915: make intel_crtc_fb_gamma_{set, get} staticPaulo Zanoni
By moving them to intel_fb.c. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: make intel_crtc_load_lut staticPaulo Zanoni
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>
2013-10-01drm/i915: make intel_pipe_has_type staticPaulo Zanoni
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>
2013-10-01drm/i915: reorganize intel_drv.hPaulo Zanoni
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>
2013-10-01drm/i915: backlight combination mode bit is gen4 onlyJani Nikula
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>
2013-10-01drm/i915: Add HSW CRT output readout supportVille Syrjälä
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>
2013-10-01drm/i915: clean up and simplify i9xx_crtc_mode_set wrt PLL handlingJani Nikula
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>
2013-10-01drm/i915: Add some debug spam for intialising SDVOChris Wilson
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>
2013-10-01drm/i915: Delay the release of the forcewake by a jiffieChris Wilson
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>
2013-10-01drm/i915: precendence bug in GT_PARITY_ERROR()Dan Carpenter
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>
2013-10-01drm/i915: Fix intel_crtc_mode_get() mode clockVille Syrjälä
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 18442d08786472c63a0a80c27f92b033dffc26de 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>
2013-10-01drm/i915: Calculate PSR register offsets from base + genBen Widawsky
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>
2013-10-01drm/i915/dp: read DPCD PSR capability only on eDPJani Nikula
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>
2013-10-01drm/i915: Drop explicit plane restoration during resumeVille Syrjälä
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>
2013-10-01drm/i915: Call intel_uncore_early_sanitize() during resumeVille Syrjälä
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>
2013-10-01drm/i915: Move power well resume earlierVille Syrjälä
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>
2013-10-01drm/i915: Move power well init earlier during driver loadVille Syrjälä
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>
2013-10-01drm/i915: Redisable VGA before the modeset on resumeVille Syrjälä
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>
2013-10-01drm/i915: Fix unclaimed register access due to delayed VGA memory disableVille Syrjälä
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 6e1b4fdad5157bb9e88777d525704aba24389bee 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>
2013-10-01drm/i915: Rip out SUPPORTS_EDPDaniel Vetter
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>
2013-10-01drm/i915: don't init DP or HDMI when not supported by DDI portPaulo Zanoni
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>
2013-10-01drm/i915: add some assertions about VBT DDI port typesPaulo Zanoni
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>
2013-10-01drm/i915: check the DDC and AUX bits of the VBT on DDI machinesPaulo Zanoni
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>
2013-10-01drm/i915: use the HDMI DDI buffer translations from VBTPaulo Zanoni
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>
2013-10-01drm/i915: VBT's child_device_config changes over timePaulo Zanoni
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>
2013-10-01drm/i915: Do not unlock upon error in i915_gem_idle()Chris Wilson
We never took the lock ourselves and all callers expect the struct_mutex to be locked upon return (be it success or error), thereore dropping the lock along the error paths looks to be a vestigial error from commit db1b76ca6a79c774074ae87bee7afc0825a478f5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 9 16:51:37 2013 +0200 drm/i915: don't frob mm.suspended when not using ums 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>
2013-10-01drm/i915: Use unsigned for overflow checks in execbufDaniel Vetter
There's actually no real risk since we already check for stricter constraints earlier (using UINT_MAX / sizeof (struct drm_i915_gem_exec_object2) as the limit). But in eb_create we use signed integers, which steals a factor of 2. Luckily struct drm_i915_gem_exec_object2 for this to not matter. Still, be consistent and use unsigned integers. Similar use unsinged integers when checking for overflows in the relocation entry processing. I've also added a new subtests to igt/gem_reloc_overflow to also test for overflowing args->buffer_count values. v2: Give the variables again tighter scope to make it clear that the computation is purely local and doesn't leak out to the 2nd block. Requested by Chris Wilson. Cc: 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>
2013-10-01drm/i915: Ditch INTELFB_CONN_LIMITDaniel Vetter
And the gratious overallocation of crtcs. Seems to go back to the ums days of yonder ... We also still need it to make the fbdev emulation happy, but I don't think there's really a need. Especially since the current fbdev emulation doesn't actually support cloning. v2: Use sizeof(*pointer) pattern (Jani). Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit (git 2.34.1) at 2025-07-16 03:07:39 +0000