summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_drv.h
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/i915: enable only the needed power domains during modesetImre Deak2013-10-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()Ville Syrjälä2013-10-151-0/+1
| | | | | | | | | | | | | | | | | 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>
* drm/i915: Add intel_pipe_wm and prepare for watermark pre-computeVille Syrjälä2013-10-151-0/+12
| | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/i915: rename intel_fb.c to intel_fbdev.cDaniel Vetter2013-10-111-4/+4
| | | | | | | | | | | 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>
* drm/i915: Kconfig option to disable the legacy fbdev supportDaniel Vetter2013-10-111-7/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/i915: Rename primary_disabled to primary_enabledVille Syrjälä2013-10-101-1/+1
| | | | | | | | 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>
* drm/i915: Keep intel_drv.h tidyDaniel Vetter2013-10-101-3/+2
| | | | | | | | | | | | 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>
* drm/i915: Rename intel_flush_display_plane to intel_flush_primary_planeVille Syrjälä2013-10-101-1/+1
| | | | | | | | | | | | | 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>
* drm/i915: Enable/disable IPS when primary is enabled/disabledVille Syrjälä2013-10-101-0/+2
| | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'airlied/drm-next' into drm-intel-nextDaniel Vetter2013-10-101-3/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915/dp: get rid of intel_dp->link_configurationJani Nikula2013-10-091-3/+0
| | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Boost RPS frequency for CPU stallsChris Wilson2013-10-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Make intel_resume_power_well() staticDamien Lespiau2013-10-011-1/+0
| | | | | | | | | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Use crtc_clock with the adjusted modeDamien Lespiau2013-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: remove "extern" keywords from intel_drv.h functionsPaulo Zanoni2013-10-011-206/+192
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: make hsw_{disable, restore}_lcpll staticPaulo Zanoni2013-10-011-3/+0
| | | | | | | | | | | | | | | | 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>
* | drm/i915: make intel_crtc_fb_gamma_{set, get} staticPaulo Zanoni2013-10-011-4/+0
| | | | | | | | | | | | | | 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>
* | drm/i915: make intel_crtc_load_lut staticPaulo Zanoni2013-10-011-1/+0
| | | | | | | | | | | | | | 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>
* | drm/i915: make intel_pipe_has_type staticPaulo Zanoni2013-10-011-1/+0
| | | | | | | | | | | | | | | | 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>
* | drm/i915: reorganize intel_drv.hPaulo Zanoni2013-10-011-196/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Add HSW CRT output readout supportVille Syrjälä2013-10-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Ditch INTELFB_CONN_LIMITDaniel Vetter2013-10-011-1/+0
|/ | | | | | | | | | | | | | | 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>
* Merge tag 'v3.12-rc2' into drm-intel-nextDaniel Vetter2013-09-241-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linux 3.12-rc2 to prep for a bunch of -next patches: - Header cleanup in intel_drv.h, both changed in -fixes and my current -next pile. - Cursor handling cleanup for -next which depends upon the cursor handling fix merged into -rc2. All just trivial conflicts of the "changed adjacent lines" type: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Track pfit enable state separately from sizeChris Wilson2013-09-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Detangle the additional state of whether or not the hw has the pfit enabled from whether it has zero size. This allows us to cleanly distinguish in the code when we expect the pfit to be enabled (for Haswell pc8), and when the BIOS is confused and needs sanitizing. Reported-by: shui yanwei <yangweix.shui@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68251 Tested-by: shui yanwei <yangweix.shui@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is doneVille Syrjälä2013-09-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When transitioning away from vgacon the system tries to save the current contents of the VGA memory, so that it can be cleanly handed off to fbcon (or whatever comes afterwards). The recent change commit 81b5c7bc8de3e6f63419139c2fc91bf81dea8a7d Author: Alex Williamson <alex.williamson@redhat.com> Date: Wed Aug 28 09:39:08 2013 -0600 i915: Update VGA arbiter support for newer devices caused i915 to disable VGA memory decode for the IGD when i915 is initializing. Unfortunately that happens before the vgacon->fbcon handoff so vgacon_save_screen() will read out all ones from the VGA memory. After the handoff fbcon will inherit the bogus state from vgacon, and pre-fills the fb with matching contents. The end result is a white rectangle in the top left corner of the screen, the size of which matches the now inactive VGA console. To remedy the situation delay the disabling of VGA memory until the vgacon->fbcon handoff has happened. Also rename i915_enable_vga to i915_enable_vga_mem to make the relationship between these functions clearer. Cc: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Add intel_display_power_{get, put} to request power for specific ↵Ville Syrjälä2013-09-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | domains Add APIs to get/put power well references for specific purposes. v2: Split the i915_request change to another patch 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>
* | drm/i915: Change i915_request power well handlingVille Syrjälä2013-09-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reorganize the internal i915_request power well handling to use the reference count just like everyone else. This way all we need to do is check the reference count and we know whether the power well needs to be enabled of disabled. v2: Split he intel_display_power_{get,put} change to another patch. Add intel_resume_power_well() to make sure we enable the power well on resume 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>
* | drm/i915: Move double wide mode handling into pipe_configVille Syrjälä2013-09-171-0/+2
| | | | | | | | | | | | | | | | | | Determine the need for double wide mode already in compute_config stage as we need that information to figure out if horizontal coordinates need to be adjusted. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Document the inteded use of requested_modeVille Syrjälä2013-09-171-0/+5
| | | | | | | | | | | | | | | | Try to clarify the purpose of requested_mode. Signed-off-by: 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>
* | drm/i915: Add explicit pipe src size to pipe configVille Syrjälä2013-09-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. In many places where we end up using pipe source size, we should actually use the primary plane size, but we don't currently store that information explicitly. As long as we treat primaries as full screen only, we can get away with this. Eventually when we move primaries over to drm_plane, we need to fix it all up. v2: Add a comment to explain what pipe_src_{w,h} are Add a note about primary planes to commit message Signed-off-by: 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>
* | drm/i915: Make intel_crtc_active() available outside intel_pm.cVille Syrjälä2013-09-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move intel_crtc_active() to intel_display.c and make it available elsewhere as well. intel_edp_psr_match_conditions() already has one open coded copy, so replace that one with a call to intel_crtc_active(). v2: Copy paste a big comment from danvet's mail explaining when we can ditch the extra checks Signed-off-by: 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>
* | drm/i915: Fix port_clock and adjusted_mode.clock readout all overVille Syrjälä2013-09-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that adjusted_mode.clock no longer contains the pixel_multiplier, we can kill the get_clock() callback and instead do the clock readout in get_pipe_config(). Also i9xx_crtc_clock_get() can now extract the frequency of the PCH DPLL, so use it to populate port_clock accurately for PCH encoders. For DP in port A the encoder is still responsible for filling in port_clock. The FDI adjusted_mode.clock extraction is kept in place for some extra sanity checking, but we no longer need to pretend it's also the port_clock. In the encoder get_config() functions fill out adjusted_mode.clock based on port_clock and other details such as the DP M/N values, HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then do an extra sanity check to make sure the dotclock we derived from the FDI configuratiuon matches the one we derive from port_clock. DVO doesn't exist on PCH platforms, so it doesn't need to anything but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so none of the changes apply there. v2: Use hdmi_reg color format to detect 12bpc HDMI case v3: Set adjusted_mode.clock for LVDS too v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get, eliminate the useless link_freq variable. 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>
* | drm/i915: Add intel_dotclock_calculate()Ville Syrjälä2013-09-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extract the code to calculate the dotclock from the link clock and M/N values into a new function from ironlake_crtc_clock_get(). The new function can be used to calculate the dotclock for both FDI and DP cases. Also simplify the code a bit along the way. v2: Don't forget about non-pch encoders in ironlake_crtc_clock_get() 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>
* | drm/i915: Add state readout and checking for has_dp_encoder and dp_m_nVille Syrjälä2013-09-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add functions to read out the CPU and PCH transcoder M/N values, and use them to fill out the pipe config dp_m_n information. And while at it populate has_dp_encoder too. Also refactor ironlake_get_fdi_m_n_config() to simply call the new intel_cpu_transcoder_get_m_n() function. v2: Remember the DDI 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>
* | drm/i915: Make adjusted_mode.clock non-pixel multipliedVille Syrjälä2013-09-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It would be easier if adjusted_mode.clock would be the pipe pixel clock, and it actually is, except for the cases where pixel_multiplier > 1. So let's change intel_sdvo to use port_clock as the multiplied clock, and then we can leave adjusted_mode.clock as pipe pixel clock. v2: Improve port_clock documentation Rebased on top of SDVO pixel_multiplier fixes 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>
* | drm/i915: Pass crtc to intel_update_watermarks()Ville Syrjälä2013-09-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | Passing the appropriate crtc to intel_update_watermarks() should help in avoiding needless work in the future. v2: Avoid clash with internal 'crtc' variable in some wm functions Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: expose intel_ddi_get_encoder_port()Jani Nikula2013-09-041-0/+1
| | | | | | | | | | | | | | | | In preparation for followup work. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add basic MIPI DSI output supportJani Nikula2013-09-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does not include any panel specific sub-encoders yet. v2: Fix fixed mode handling (Daniel) v3: Mostly based on Ville's review comments. - Fix MIPI_HS_TX_TIMEOUT. - DPI_ENABLE only for video mode. - Drop ULPS usage for now, use DEVICE_READY only. - Set MIPI_INIT_COUNT based on txclkesc. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add MIPI DSI output type and subtypesJani Nikula2013-09-041-1/+5
|/ | | | | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix pipe config warnings when dealing with LVDS fixed modeVille Syrjälä2013-09-031-1/+1
| | | | | | | | | | | | | | | intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode only partially. Notably it forgot to copy over the sync flags. The LVDS code however programmed the hardware with the sync flags from fixed mode, and then later the pipe config comparison obviously failed as we filled out the adjusted_mode in get_config from the real registers. Just call drm_mode_copy() in intel_fixed_panel_mode() to copy over the whole thing, and then just use adjusted_mode in the LVDS code to figure out which sync settings the hardware needs. Also constify the fixed_mode argument to intel_fixed_panel_mode(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: allow package C8+ states on Haswell (disabled)Paulo Zanoni2013-08-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows PC8+ states on Haswell. These states can only be reached when all the display outputs are disabled, and they allow some more power savings. The fact that the graphics device is allowing PC8+ doesn't mean that the machine will actually enter PC8+: all the other devices also need to allow PC8+. For now this option is disabled by default. You need i915.allow_pc8=1 if you want it. This patch adds a big comment inside i915_drv.h explaining how it works and how it tracks things. Read it. v2: (this is not really v2, many previous versions were already sent, but they had different names) - Use the new functions to enable/disable GTIMR and GEN6_PMIMR - Rename almost all variables and functions to names suggested by Chris - More WARNs on the IRQ handling code - Also disable PC8 when there's GPU work to do (thanks to Ben for the help on this), so apps can run caster - Enable PC8 on a delayed work function that is delayed for 5 seconds. This makes sure we only enable PC8+ if we're really idle - Make sure we're not in PC8+ when suspending v3: - WARN if IRQs are disabled on __wait_seqno - Replace some DRM_ERRORs with WARNs - Fix calls to restore GT and PM interrupts - Use intel_mark_busy instead of intel_ring_advance to disable PC8 v4: - Use the force_wake, Luke! v5: - Remove the "IIR is not zero" WARNs - Move the force_wake chunk to its own patch - Only restore what's missing from RC6, not everything 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>
* drm/i915: wrap GEN6_PMIMR changesPaulo Zanoni2013-08-231-0/+3
| | | | | | | | | | | Just like we're doing with the other IMR changes. One of the functional changes is that not every caller was doing the POSTING_READ. 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>
* drm/i915: wrap GTIMR changesPaulo Zanoni2013-08-231-0/+3
| | | | | | | | | | | | Just like the functions that touch DEIMR and SDEIMR, but for GTIMR. The new functions contain a POSTING_READ(GTIMR) which was not present at the 2 callers inside i915_irq.c. The implementation is based on ibx_display_interrupt_update. 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>
* drm/i915: Make intel_set_mode() staticDamien Lespiau2013-08-091-2/+0
| | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove intel_modeset_disable()Damien Lespiau2013-08-091-1/+0
| | | | | | | Caught by the dead code police! Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make intel_encoder_dpms() staticDamien Lespiau2013-08-091-1/+0
| | | | | | | And also fix a small typo in the intel_encoder_dpms() comment. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove stale prototypesDamien Lespiau2013-08-091-2/+0
| | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Pass plane and crtc to intel_update_sprite_watermarksVille Syrjälä2013-08-081-1/+2
| | | | | | | | | | | We're going to want to know the crtc in the watermark code to avoid doing more work than we have to. We should also pass the plane we're disabling so that we know where to stick our watermark parameters without having to go look the plane up. 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>
* drm/i915: Pass crtc to our update/disable_plane hooksVille Syrjälä2013-08-081-1/+3
| | | | | | | | | We're going to want to know which CRTC we're dealing with, so pass it down to the update/disable_plane hooks. 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>
* drm/i915: Split plane watermark parameters into a separate structVille Syrjälä2013-08-081-6/+8
| | | | | | | | | | | | | | Give a name to the plane watermark related data we have currently stored under intel_plane->wm. We also observe that this data is more or less the same that we have in the hsw_pipe_wm_parameters structure, so use it there as well. v2: Make pahole happier Reviewed-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>
OpenPOWER on IntegriCloud