summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_ddi.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/bdw: check DPD on port D when setting the DDI buffersPaulo Zanoni2013-11-081-1/+6
| | | | | | | | | | | Use the eDP values on platforms where port D is eDP. This doesn't affect Haswell since it uses the same DDI buffer values for eDP and DP. Reviewed-by: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: add BDW DDI buf translations for eDPPaulo Zanoni2013-11-081-3/+32
| | | | | | | | | | | | | | | Broadwell has different DDI buffer translations for eDP and DP, so add support for the missing eDP and keep Haswell the same. A future patch addresses the suggestion from Art to check for eDP on port D and use the eDP values there, too. v2: Make checkpatch happy. Reviewed-by: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: Add BDW DDI buffer translation valuesArt Runyan2013-11-081-5/+48
| | | | | | | | | | | | | | | Many of the DDI buffer translation values have changed for BDW. Add new translation tables and selection between HSW and BDW. v2: s/BUG/WARN/ to avoid breaking future GENs. v3: Rebase on top of the hdmi translation table changes. v4: Fix up the multiline comment while at it. Signed-off-by: Art Runyan <arthur.j.runyan@intel.com> (v2) Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: get the correct LCPLL frequency on BroadwellPaulo Zanoni2013-11-081-7/+18
| | | | | | | | | | | | | v2: Rebased onto Paulo's MHz->kHz change. v3: Rebased on top of the Haswell pc8+ adjustements. v4: Use the exact 337.5MHz clock, should have been done as part of v2. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: on Broadwell, the panel fitter is on the pipePaulo Zanoni2013-11-081-5/+7
| | | | | | | | | | | | | | | | | So you can use the panel fitter while the power well is disabled and you also don't need to set the "pipe" bit. v2: Rebased on top of Jesse's pfit refactor, which moved pfit state into the pipe_config. v3: Rebase on top of the latest Haswell/panel fitter rework, which neatly resolves a FIXME we have in this patch here: v4: Rebase on top of the new power domain framework. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't leak dp_connector at intel_ddi_initPaulo Zanoni2013-10-101-20/+42
| | | | | | | | | | | | | | | | | | Regression introduced by: commit 311a20949f047a70935d6591010f42336f5402e7 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't init DP or HDMI when not supported by DDI port Since the commit above it is possible to have a DDI encoder that has the HDMI connector but not the DP connector (in case the port doesn't support DP). In this case, we must properly free the DP connector. We just leak this once, so it's not a big deal. Reported by kmemleak. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge remote-tracking branch 'airlied/drm-next' into drm-intel-nextDaniel Vetter2013-10-101-4/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+1
| | | | | | | | | | | | | | | | | | | | | | 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: Add HSW CRT output readout supportVille Syrjälä2013-10-011-2/+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: don't init DP or HDMI when not supported by DDI portPaulo Zanoni2013-10-011-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: use the HDMI DDI buffer translations from VBTPaulo Zanoni2013-10-011-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) patternDaniel Vetter2013-10-011-3/+3
|/ | | | | | | | | | | Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). 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-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+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: Add state readout and checking for has_dp_encoder and dp_m_nVille Syrjälä2013-09-131-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add support for pipe_bpp readoutVille Syrjälä2013-09-131-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On CTG+ read out the pipe bpp setting from hardware and fill it into pipe config. Also check it appropriately. v2: Don't do the pipe_bpp extraction inside the PCH only code block on ILK+. Avoid the PIPECONF read as we already have read it for the PIPECONF_EANBLE check. 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: Fix HSW sync flags to use pipe config adjusted_modeVille Syrjälä2013-09-101-2/+2
| | | | | | | | | | | | | | | | | | intel_ddi_enable_transcoder_func() picked the sync flags from crtc->mode instead of the pipe config adjusted_mode. Fix the problem and hopefully rid my HSW machine of the remaining pipe config warnings. 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-1/+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 the FCLK case to intel_ddi_get_cdclk_freqPaulo Zanoni2013-08-231-3/+6
| | | | | | | | | | We already have code to disable LCPLL and switch to FCLK, so we need this too. We still don't call the code to disable LCPLL, but we'll call it when we add support for Package C8+. 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: remove use_fdi_mode argument from intel_prepare_ddi_buffersPaulo Zanoni2013-08-061-12/+5
| | | | | | | | We set the mode based on the port, and we already pass the port as an argument. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: silence useless messages about DDI buffer translationPaulo Zanoni2013-08-061-9/+2
| | | | | | | | | | | | | | | | | | | These messages are not really useful since it's very easy to check which mode is used for each port: The values programmed are based on the port type, then assigned to the ddi_translations variable. Currently we use DP mode for ports A-D and FDI mode for port E. Also, when we add the code to enable/disable PC8+, intel_prepare_ddi_buffers will be called more often and will eat your dmesg buffers. While at it, fix the coding style of the "for" statement above. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Pimp commit message with Paulo's more detailed explanation of how the ddi translation buffer settings are computed, to answer a question from Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/ddi: use the native encoder ->mode_set callbackDaniel Vetter2013-08-041-23/+16
| | | | | | | Same conversion as for hdmi/dp. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge commit 'Merge branch 'drm-fixes' of ↵Daniel Vetter2013-07-251-4/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~airlied/linux' This backmerges Linus' merge commit of the latest drm-fixes pull: commit 549f3a1218ba18fcde11ef0e22b07e6365645788 Merge: 42577ca 058ca4a Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Jul 23 15:47:08 2013 -0700 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux We've accrued a few too many conflicts, but the real reason is that I want to merge the 100% solution for Haswell concurrent registers writes into drm-intel-next. But that depends upon the 90% bandaid merged into -fixes: commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 19 20:36:51 2013 +0100 drm/i915: Serialize almost all register access Also, we can roll up on accrued conflicts. Usually I'd backmerge a tagged -rc, but I want to get this done before heading off to vacations next week ;-) Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_gem.c v2: For added hilarity we have a init sequence conflict around the gt_lock, so need to move that one, too. Spotted by Jani Nikula. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Preserve the DDI_A_4_LANES bit from the biosStéphane Marchesin2013-07-131-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes on eDP. This fixes eDP on hsw with > 2 lanes. Also s/port_reversal/saved_port_bits/ since the current name is confusing. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Hook PSR functionalityRodrigo Vivi2013-07-181-0/+2
|/ | | | | | | | | | | | | | | | | | PSR must be enabled after transcoder and port are running. And it is only available for HSW. v2: move enable/disable to intel_ddi v3: The spec suggests PSR should be disabled even before backlight (by pzanoni) v4: also disabling and enabling whenever panel is disabled/enabled. v5: make it last patch to avoid breaking whenever bisecting. So calling for update and force exit came to this patch along with enable/disable calls. v6: Remove unused and unecessary psr_enable/disable calls, as notice by Paulo. CC: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Drop the psr exit code in the busy ioctl since I didn't merge that part of the infrastructure yet - it needs more thought.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix the "ghost eDP" encoder unwind pathPaulo Zanoni2013-06-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Because calling intel_dp_encoder_destroy inside intel_edp_init_connector is just wrong. This is the initialization path, so we should properly unwind all the initialization through the whole caller stack. On the intel_dp_encoder_destroy function we do the following: 1 - Call i2c_del_adapter 2 - Call drm_encoder_cleanup 3 - If edp: 3.1 - Cancel panel_vdd_work 3.2 - Call ironlake_panel_vdd_of_sync 4 - Free the encoder And here is how we unwind each specific step: 1 - We have intel_dp_init_connector -> intel_dp_i2c_init -> i2c_dp_aux_add_bus -> i2c_add_adapter, so we call i2c_del_dapter at intel_dp_init_connector 2 - Call it in the same function that called drm_encoder_init 3 - Call it in the same function that called INIT_DELAYED_WORK 4 - Free it in the same function that allocated it Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix the "ghost eDP" connector unwind pathPaulo Zanoni2013-06-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Because calling intel_dp_destroy inside intel_edp_init_connector is just wrong. This is the initialization path, so we should properly unwind all the initialization through the whole caller stack. On the intel_dp_destroy function we do the following: 1 - Free edid if it exists 2 - Call intel_panel_fini in case it's eDP 3 - Call drm_sysfs_connector_remove 4 - Call drm_connector_cleanup 5 - Free the connector And here is how we unwind each specific step: 1 - No need as we still didn't assign anything 2 - No need as we still didn't call intel_panel_init 3 - Call it in the same function that called drm_sysfs_connector_add 4 - Call it in the same function that called drm_connector_init 5 - Free it in the same function that allocated it Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: propagate errors from intel_dp_init_connectorPaulo Zanoni2013-06-281-1/+2
| | | | | | | | | | | | | | | | | | | | In case we detect a "ghost eDP", intel_edp_init_connector frees both the connector and encoder and then returns. On Haswell, intel_ddi_init then tries to use the freed encoder on the HDMI initialization path since the following commit: commit 21a8e6a4853b2ed39fa4c5188a710f2cf1b92026 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 10 23:28:35 2013 +0200 drm/i915: don't setup hdmi for port D edp in ddi_init So now on intel_ddi_init we check for the "ghost eDP" case and return without trying to initialize HDMI. This way we won't try to read the freed "intel_encoder" struct in the next "if" statement. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: set default value for config->pixel_multiplierDaniel Vetter2013-06-051-1/+0
| | | | | | | | | | | | | | This way we can simplify the code quite a bit. Also add a WARN in the sdvo code to complain about a bogus value and kill the readout code in intel_ddi.c that Jesse sneaked in. HW state readout for the pixel multiplier will work a bit differently in the end. v2: Rebase on top of the fdi pixel mutliplier handling fix. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: store adjusted dotclock in adjusted_mode->clockDaniel Vetter2013-06-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... not the port clock. This allows us to kill the funny semantics around pixel_target_clock. Since the dpll code still needs the real port clock, add a new port_clock field to the pipe configuration. Handling the default case for that one is a bit tricky, since encoders might not consistently overwrite it when retrying the crtc/encoder bw arbitrage step in the compute config stage. Hence we need to always clear port_clock and update it again if the encoder hasn't put in something more specific. This can't be done in one step since the encoder might want to adjust the mode first. I was a bit on the fence whether I should subsume the pixel multiplier handling into the port_clock, too. But then I decided against this since it's on an abstract level still the dotclock of the adjusted mode, and only our hw makes it a bit special due to the separate pixel mulitplier setting (which requires that the dpll runs at the non-multiplied dotclock). So after this patch the adjusted_mode accurately describes the mode we feed into the port, after the panel fitter and pixel multiplier (or line doubling, if we ever bother with that) have done their job. Since the fdi link is between the pfit and the pixel multiplier steps we need to be careful with calculating the fdi link config. v2: Fix up ilk cpu pll handling. v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config to make it clearer that we transmit the adjusted_mode without the pixel multiplier taken into account. The old code multiplied the the available link bw with the pixel multiplier, which results in the same fdi configuration, but is much more confusing. v4: Rebase on top of Imre's is_cpu_edp removal. v5: Rebase on top of Paulo's haswell watermark fixes, which introduce a new place which looked at the pixel_clock and so needed conversion. v6: Split out prep patches as requested by Paulo Zanoni. Also rebase on top of the fdi dotclock handling fix in the fdi lanes/bw computation code. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: hw state readout&check support for cpu_transcoderDaniel Vetter2013-05-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows us to drop a bunch of ugly hacks and finally implement what commit cc464b2a17c59adedbdc02cc54341d630354edc3 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Jan 25 16:59:16 2013 -0200 drm/i915: set TRANSCODER_EDP even earlier tried to achieve, but that was reverted again in commit bba2181c49f1dddf8b592804a1b53cc1a3cf408a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Mar 22 10:53:40 2013 +0100 Revert "drm/i915: set TRANSCODER_EDP even earlier" Now we should always have a consistent cpu_transcoder in the pipe_config. v2: Fix up the code as spotted by Paulo: - read the register for real - assign the right pipes - break out if the hw state doesn't make sense v3: Shut up gcc. 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>
* drm/i915: make intel_ddi_get_cdclk_freq return values in KHzPaulo Zanoni2013-05-211-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this, that 338 can finally become the correct 337500. Due to the change we need to adjust the intel_dp_aux_ch function to set the correct value, so adjust the division and also use DIV_ROUND_CLOSEST instead of the old "round down" behavior because the spec says the value "should be programmed to get as close as possible to the ideal rate of 2MHz". Quoting Paulo's follow-up to a question from Chris Wilson to explain what exactly will change: I use the 337500 value on the next patch, when setting the ips_linetime value. The correct frequency is 337500, not 338000. ips_linetime = DIV_ROUND_CLOSEST(mode->htotal * 1000 * 8, intel_ddi_get_cdclk_freq); For a mode with htotal of 2640 [0] we'll have: (i) (2640 * 1000 * 8) / 338000 = 62.48, resulting in 62 and (ii) (2640 * 1000 * 8) / 337500 = 62.57 resulting in 63. For the case inside intel_dp.c: Previously we were using 338. So with the old formula we were writing 338/2 = 169 to the register. And 337500 / 169 = 1997.04 (we use 337500 here because it's the real clock value). With the new value of 337500/2000 we'll have 168.75, which is 168 on the round-down case and 169 on the round-closest case. If we write 168 to the register, 337500 / 168 = 2008.92, and 2008.92 is more distant from 2000 than 1997.04. So with this patch we're changing the formula but still writing the same correct value to the DP AUX register. [0]: That's 1920x1080@50Hz on my DP monitor. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Pimp the commit message with Paulo's follow-up.] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add encoder get_config function v5Jesse Barnes2013-05-211-0/+23
| | | | | | | | | | | | | | | | | | | | | We can use this for fetching encoder specific pipe_config state, like mode flags, adjusted clock, etc. Just used for mode flags atm, so we can check the pipe config state at mode set time. v2: get_config when checking hw state too v3: fix DVO and LVDS mode flags (Ville) get SDVO DTD for flag fetch (Ville) v4: use input timings (Ville) correct command used (Ville) remove gen4 check (Ville) v5: get DDI flag config too Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4) Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.10-rc2' into drm-intel-next-queuedDaniel Vetter2013-05-211-0/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linux 3.10-rc2 since the various (rather trivial) conflicts grew a bit out of hand. intel_dp.c has the only real functional conflict since the logic changed while dev_priv->edp.bpp was moved around. Also squash in a whitespace fixup from Ben Widawsky for i915_gem_gtt.c, git seems to do something pretty strange in there (which I don't fully understand tbh). Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: hsw: fix link training for eDP on port-AImre Deak2013-05-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to BSpec the link training sequence for eDP on HSW port-A should be as follows: 1. link training: clock recovery 2. link training: equalization 3. link training: set idle transmission mode 4. display pipe enable 5. link training: disable (set normal mode) Contrary to this at the moment we don't do step 3. and we do step 5. before step 4. Fix this by setting idle transmission mode for eDP at the end of intel_dp_complete_link_train and adding a new intel_dp_stop_link_training function to disable link training. With these changes we'll end up with the following functions corresponding to the above steps: intel_dp_start_link_train -> step 1. intel_dp_complete_link_train -> step 2., step 3. intel_dp_stop_link_train -> step 5. For port-A we'll call intel_dp_stop_link_train only after enabling the pipe, for everything else we'll call it right after intel_dp_complete_link_train to preserve the current behavior. Tested on HSW/HSW-ULT. In v2: - Due to a HW issue we must set idle transmission mode for port-A too before enabling the pipe. Thanks for Arthur Runyan for explaining this. - Update the patch subject to make it clear that it's an eDP fix, DP is not affected. v3: - rename intel_dp_link_train() to intel_dp_set_link_train(), use 'val' instead 'l' as var name. (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Compute WR PLL dividers dynamicallyDamien Lespiau2013-05-101-403/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up to now, we were using a static table to match the clock frequency with a (r2,n2,p) triplet. Despite this table being big, it's by no mean comprehensive and we had to fall back to the closest frequency when the requested TMDS clock wasn't in the table. This patch computes (r2,n2,p) dynamically and get rid of The Big Table. v2: Replace the floating point constant 1e6 by 1000000 Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58497 Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) [danvet: s/ /^T/] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Add references to some workaround we implementDamien Lespiau2013-05-101-0/+2
| | | | | | | | | | | | | | | | | | We did not mention the workaround name when implementing those. This should help us track what we already implement. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: only disable DDI sound if intel_crtc->eld_vldPaulo Zanoni2013-05-101-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | We already have the same check on intel_enable_ddi. This patch prevents "unclaimed register" messages when the power well is disabled. V2: Reset intel_crtc->eld_vld to false after the mode_set function. V3: Add both "type != INTEL_OUTPUT_EDP" requested. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: don't setup hdmi for port D edp in ddi_initDaniel Vetter2013-05-061-14/+11
| | | | | | | | | | | | | | | | | | | | dp_init_connector adjusts the encoder type if it is a eDP panel. Use that to decide whether we should set up a hdmi connector or not. To do so reorder the hdmi connector setup sequence in ddi_init a bit. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: simplify DP/DDI port width macrosDaniel Vetter2013-05-021-32/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we ever leak a non-DP compliant port width through here, we have a pretty serious issue. So just rip out all these WARNs - if we need them it's probably better to have them at a central place where we compute the dp lane count. Also use the new DDI width macro for FDI mode. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: fixup the embarrassing s/intel_dp->DP/temp/ mistake Paulo spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: hw state readout support for pipe_config->fdi_lanesDaniel Vetter2013-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | v2: Introduce some nice #defines for the FDI lane width fields and put them to good use. Suggested by Ville. v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and use the shift #define also in the mask. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move intel_crtc->fdi_lanes to pipe_configDaniel Vetter2013-04-291-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | We need this for two reasons: - Correct handling of shared fdi lanes on ivb with fastboot. - Handling fdi link bw limits when we only have two fdi lanes by dithering down a bit. Just search&replace in this patch, no functional change at all. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move PCH pfit controls into pipe_configJesse Barnes2013-04-251-1/+1
| | | | | | | | | | | | | | | | And put the pfit stuff into substructs while we're at it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Remove mention of Haswell in DDI codeDamien Lespiau2013-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | We are trying to have more platform-orthogonal pieces of code. The DDI code shouldn't mention Haswell. v2: Fix the email address Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Print plane, pipe, port names as alphabetical insted of decimalVille Syrjälä2013-04-181-5/+5
|/ | | | | | | | Alway use the alphabetical names in debug/error messages for planes, pipes and ports, instead of using decimal numbers occasionally. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move cpu_transcoder to the pipe configurationDaniel Vetter2013-04-181-4/+4
| | | | | | | | | | | | | | | | | | | | For a bunch of reason we need to more accurately track this: - hw pipe state readout for Haswell needs the cpu transcoder. - We need to know the right cpu transcoder in a bunch of places in ->disable and other modeset callbacks. In the future we need to add hw state readout&check support, too. But to avoid ugly merge conflicts do the rote sed job now without any functional changes. v2: Preserve the cpu_transcoder value when overwriting crtc->config. Reported by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) [danvet: Removed rough whitespace that Chris spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix DDI get_hw_state return valueJesse Barnes2013-04-021-1/+1
| | | | | | | | | If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: precompute pipe bpp before touching the hwDaniel Vetter2013-03-281-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The procedure has now 3 steps: 1. Compute the bpp that the plane will output, this is done in pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also, this function clamps the pipe_bpp to whatever limit the EDID of any connected output specifies. 2. Adjust the pipe_bpp in the encoder and crtc functions, according to whatever constraints there are. 3. Decide whether to use dither by comparing the stored plane bpp with computed pipe_bpp. There are a few slight functional changes in this patch: - LVDS connector are now also going through the EDID clamping. But in a 2nd change we now unconditionally force the lvds bpc value - this shouldn't matter in reality when the panel setup is consistent, but better safe than sorry. - HDMI now forces the pipe_bpp to the selected value - I think that's what we actually want, since otherwise at least the pixelclock computations are wrong (I'm not sure whether the port would accept e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick the next higher bpc value, since otherwise there's no way to make use of the 12 bpc mode (since the next patch will remove the 12bpc plane format, it doesn't exist). Both of these changes are due to the removal of the pipe_bpp = min(display_bpp, plane_bpp); statement. Another slight change is the reworking of the dp bpc code: - For the mode_valid callback it's sufficient to only check whether the mode would fit at the lowest bpc. - The bandwidth computation code is a bit restructured: It now walks all available bpp values in an outer loop and the codeblock that computes derived values (once a good configuration is found) has been moved out of the for loop maze. This is prep work to allow us to successively fall back on bpc values, and also correctly support bpc values != 8 or 6. v2: Rebased on top of Paulo Zanoni's little refactoring to use more drm dp helper functions. v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color range work. v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed. v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked in a later patch though again. v6: Fix spelling in a comment. v7: Debug output improvements for the bpp computation. v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different things! v9: Reinstate the fix to properly ignore the firmware edp bpp ... this was lost in a rebase. v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have that. Still unsure whether this is the way to go, but at least 6bpc for a 8bpc hdmi output seems to work. v11: And g4x/vlv also lack 12bpc hdmi support, so only support high depth on DP. Adjust the code. v12: Rebased. v13: Split out the introduction of pipe_config->dither|pipe_bpp, as requested from Jesse Barnes. v14: Split out the special 6BPC handling for DP, as requested by Jesse Barnes. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: introduce pipe_config->dither|pipe_bppDaniel Vetter2013-03-281-4/+4
| | | | | | | | | We want to compute this earlier. To avoid a big complicated patch, this patch here just does the big search&replace and still calls the old functions at the same places. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add pipe_config->has_pch_encoderDaniel Vetter2013-03-281-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is used way too often in the enable/disable paths. And will be even more useful in the future. Note that correct semantics of this change highly depend upon correct updating of intel_crtc->config: Like with all other modeset state, we need to call ->disable with the old config, but ->mode_set and ->enable with the new config. v2: Do not yet use the flag in the ->disable callbacks - atm we don't yet have support for the information stored in the pipe_config in the hw state readout code, so this will be wrong at boot-up/resume. v3: Rebased on top of the hdmi/dp ddi encoder merging. v4: Fixup stupid rebase error which lead to a NULL vfunc deref. v5: On haswell the VGA port is on the PCH! v6: s/IS_HASWELL/HAS_DDI/, spotted by Paulo Zanoni. Also add a missing parameter name in a function declaration. v7: Don't forget to git add ... Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud