summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2012-11-11drm/i915: reset intel_encoder->type when DP or HDMI is detectedPaulo Zanoni
When intel_hdmi_detect detects a monitor, set intel_encoder->type with INTEL_OUTPUT_HDMI. Same for DP. This should not break the current code because these variables never change. This will be used after we create the DDI encoder because it will have both DP and HDMI connectors. We won't support eDP+HDMI on the same port, so if an encoder is eDP we should expect it to always remain eDP and never change. 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>
2012-11-11drm/i915: split intel_dp_init into encoder and connector piecesPaulo Zanoni
Same reason as the previous HDMI commit: the DDI code will have its own encoder init function but still use the DP and HDMI connectors. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: kill the unnecessarily added line that Damien spotted in review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: split intel_hdmi_init into encoder and connector piecesPaulo Zanoni
We want to split the HDMI connector and encoder initialization because in the future the DDI code will have its own "encoder init" function, but it will still call intel_hdmi_init_connector. The DDI encoder will actually have two connectors attached to it: HDMI and DP. The best way to look at this patch is to imagine that we're renaming intel_hdmi_init to intel_hdmi_init_connector and removing the encoder-specific pieces and placing them into intel_hdmi_init. 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>
2012-11-11drm/i915: create intel_digital_port and use itPaulo Zanoni
The goal is to have one single encoder capable of controlling both DP and HDMI outputs. This patch just adds the initial infrastructure, no functional changes. Previously, both intel_dp and intel_hdmi were intel_encoders. Now, these 2 structs do not have intel_encoder as members anymore. The new struct intel_digital_port has intel_encoder as a member, and it also includes intel_dp and intel_hdmi as members. In other words: see the changes inside intel_drv.h: it's the most important change, everything else is only to make it compile and work. For now, each intel_digital_port is still only able to control one of HDMI or DP, but not both together. In the future we should also try to merge the common fields from intel_dp and intel_hdmi (e.g., port). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Add the missing ' ' spotted by Damien Lespiau.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: add intel_dp_to_dev and intel_hdmi_to_devPaulo Zanoni
When we add struct intel_digital_port, there will be no direct way of going from intel_{dp,hdmi} to drm_device: we will need to call container_of(). This patch adds functions to go from intel_{dp,hdmi} to drm_device. The main goal here is to greatly reduce the size of the next patch, where we will change the implementation of the functions we just added here (among other things). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: simplify assignments inside intel_dp.cPaulo Zanoni
- Replace container_of with enc_to_intel_dp. - Walk through less structures when making assignments. - Rename some variables to keep our naming standards. As a bonus, this will reduce the usage of "struct intel_dp", making the future patch that introduces intel_digital_port smaller and easier to review. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: Fix HSW power well control state readZhenyu Wang
Fix power well control state by reading real register offset. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: Flush using only the correct base address registerDamien Lespiau
We were writing DSP_ADDR and DSP_SURF unconditionally. This did not trigger an unclaimed write before HSW as the address of DSP_ADDR has been repurposed as DSP_LINOFF. On HSW, though, DSP_LINOFF has been removed and then writting to it triggers an unclaimed write. This patch writes to DSP_ADDR or DSP_SURF to flush the display plane configuration depending on the gen we're running on. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: implement WaDisableRenderCachePipelinedFlushDaniel Vetter
Comment says for eaglelake/cantiga, but it's listed in the ilk table, too. So apply it to both. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: implement WaIssueDummyWriteToWakeupFromRC6Daniel Vetter
Or at least our best understanding of it. v2: Fixup commit message and put the wa name into the comment block. And actually update the commit, too. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: adjust sprite base addressDamien Lespiau
Just like in: commit c2c75131244507c93f812862fdbd4f3a37139401 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 5 12:17:30 2012 +0200 drm/i915: adjust framebuffer base address on gen4+ but this time, for the sprite planes. This ensures that the sprite offset are always inside the supported hardware limits since it becomes the offset into a page and we adjust the base address to a page boundary. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: Fix sprite offset on HSWDamien Lespiau
HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET register. v2: Remove a useless level of indentation (Paulo Zanoni) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: Fix primary plane offset on HSWDamien Lespiau
Haswell consolidates DSP_TILEOFF and DSP_LINOFF into DSP_OFFSET (aka PRI_OFFSET). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: Error out when trying to set a y-tiled as a spriteDamien Lespiau
v2: Use a switch for consistency (Chris Wilson) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915/tv: Use intel_flush_display_plane() to flush the primary planeDamien Lespiau
Instead of writing to the DSP_ADDR ourselves. This will do the right thing on gen >= 4 as well. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: check fdi B/C lane sharing constraintDaniel Vetter
And properly toggle the chicken bit in the pch to enable/disable fdi C rx. If we don't set this bit correctly, the rx gets confused in link training, which can result in an fdi link that silently fails to train the link (since the corresponding register reports success). Note that both fdi link B and C can suffer when this bit is not set correctly. The code as-is has a few deficiencies: - We presume all pipes use the pch which is not the case for cpu edp. - We don't bother with disabling both pipes when we could make things work, e.g. when pipe B switched from 4 to 2 lanes due to a mode change, we don't bother updating the w/a bit. - It's ugly. All of these are because we compute ->fdi_lanes way too late, when we're already setting up individual pipes. We need to have this information in ->modeset_global_resources already, to set things up correctly. But that is a much larger reorg of the code. Note that we actually hit the 2 lanes limit in practice rather quickly: Even though the 1920x1200 mode native mode of my screen fits into 2 lanes, it needs 3 lanes for the 1920x1080 (since that somehow has much more blanking ...). Not obeying this restriction seems to results in cute-looking digital noise. v2: Only ever clear the chicken bit when both pipes are off. v3: Use the new ->modeset_global_resources callback. v4: Move the WARNs to the right place. Oh how I hate hacks. v5: Fix spelling, noticed by Paulo Zanoni. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: add ->display.modeset_global_resources callbackDaniel Vetter
After all relevant pipes are disabled and after we've updated all the state with the staged state, but before we call the per-crtc ->mode_set functions there's a very natural point to set up any shared/global resources like - shared plls (obviously only the setup, the enabling needs to be separately handling with a separate refcount) - global watermark state like the DSPARB on gmch platforms - workaround bits that depend upon the exact global output configuration - enabling the right set of refclocks - enabling/disabling manual power wells. Now for a lot of these things we can't move them into this function yet, most often because we only compute the required information in the per-crtc ->mode_set callback. Which is too late. But due to a bunch of reasons (check-only atomic modeset, fastboot&hw state checks, ...) we need to separate the computation of that state from the actual hw frobbery anyway. So we can move things into this new callback step- by-step. Others can't be moved here (or implemented at all) because our code lacks the smarts to properly update them. E.g. the DSPARB can only be updated when all pipes are disabled, so if we decide to change it's value, we need to disable _all_ pipes. The infrastructure for that is already in place (with the various pipe masks that driver the modeset logic). But again we need to move a few things out of ->mode_set first before we can even implement the correct decision making. In any case, we need to start somewhere, so let's start with the callback: Some small follow-up patches will make immediate good use of it. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: BUG on impossible pch dp portDaniel Vetter
Since it is one. We need to move this code to encoder specific callbacks eventually, to kill all that inversion of control ... Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: add comment about pch pll enabling rulesDaniel Vetter
Atm we have a few funny issues where we enable/disable shared pll clocks. To make it clear that we are not required to enable/ disable the pch plls together with the other pch resources (and so should keep it running when it's used by another pipe in a shared pll configuration) add a comment. This note is lifted from "Graphics BSpec: vol4g North Display Engine Registers [IVB], Display Mode Set Sequence", step 9.d. of the enable sequence: "Configure and enable PCH DPLL, wait for PCH DPLL warmup (Can be done anytime before enabling PCH transcoder)." Since fixing the pll sharing code to no longer disable shared plls if they're still in use is more involved, let's just stick with the comment for now. v2: Make the comment in the code clearer, to address questions raised by Paulo Zanoni in review. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: set FDI_RX_MISC to recommended values on CPT/PPTDaniel Vetter
My machine here has the correct ones already, but better safe than sorry. IBX has different settings for that register, and on IBX the device defaults match the recommended values. Hence I did not add the respective writes for IBX. LPT needs the same settings, but that has been done already commit 4acf518626cdad5bbf7aac9869bd4accbbfb4ad3 Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Wed Jul 4 20:15:16 2012 -0300 drm/i915: program FDI_RX TP and FDI delays 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>
2012-11-11drm/i915: clarify why we need to enable fdi plls so earlyDaniel Vetter
For reference, see "Graphics BSpec: vol4g North Display Engine Registers [IVB], Display Mode Set Sequence", step 4 of the enabling sequence: a. "Enable PCH FDI Receiver PLL, wait for warmup plus DMI latency b. "Switch from Rawclk to PCDclk in FDI Receiver c. "Enable CPU FDI Transmitter PLL, wait for warmup" Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: Write the FDI RX TU size reg at the right timeDaniel Vetter
According to "Graphics BSpec: vol4g North Display Engine Registers [IVB], Display Mode Set Sequence" We need to write the TU size register of the fdi RX unit _before_ starting to train the link. Note: The current code is actually correct as Paulo mentioned in review, but it's a bit confusion since only the fdi rx/tx plls need to be enabled before the cpu pipes/planes. Hence it's still a good idea to move the TU_SIZE setting to the "right" spot in the sequence, to better match Bspec. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-11drm/i915: shut up spurious message in intel_dp_get_hw_stateDaniel Vetter
The debug message is only relevant on CPT/PPT PCH ports, so move it into the correct if clause. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-02drm/i915: pass adjusted_mode to intel_choose_pipe_bpp_dither(), againJani Nikula
Daniel's backmerge commit c2fb7916927e989ea424e61ce5fe617e54878827 Merge: 29de6ce 6f0c058 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Oct 22 14:34:51 2012 +0200 Merge tag 'v3.7-rc2' into drm-intel-next-queued to solve conflicts blew up (either git or Daniel was trying to be too clever for their own good; it's usually convenient to blame tools ;) and caused the changes of commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Sep 26 18:43:10 2012 +0300 drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag in ironlake_crtc_mode_set() to be dropped. Fix the call in ironlake_crtc_mode_set() again, and while at it, also fix the new, copy-pasted haswell_crtc_mode_set() to use adjusted_mode. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915/dp: change eDP default scaling mode to respect aspect ratioYuly Novikov
Signed-off-by: Yuly Novikov <ynovikov@chromium.org> [Jani: ripped this change separate from the scaling mode change support] Signed-off-by: Jani Nikula <jani.nikula@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>
2012-10-26drm/i915/dp: allow configuring eDP panel fitting scaling modeYuly Novikov
LVDS allowed changing panel fitting scaling mode, while eDP didn't. Copied relevant code from LVDS to eDP. Signed-off-by: Yuly Novikov <ynovikov@chromium.org> [Jani: use fitting mode in intel_panel, remove default mode change] Signed-off-by: Jani Nikula <jani.nikula@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>
2012-10-26drm/i915/lvds: move fitting mode from intel_lvds_connector to intel_panelJani Nikula
Prepare for supporting scaling mode configuration also in eDP. Includes a drive-by-removal of an outdated comment about fitting mode. Signed-off-by: Jani Nikula <jani.nikula@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>
2012-10-26drm/i915: debug print all of the DPCD we haveJani Nikula
At some point the DPCD size was increased, but the debug print not. While at it, switch to using hex dump. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915: VLV does not have a sprite scalerDamien Lespiau
Just like HSW, VLV does not have a sprite scale. Set intel_plane->can_scale accordingly. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915/sdvo: restore i2c adapter config on intel_sdvo_init() failuresJani Nikula
SDVOB may be multiplexed with HDMIB. If it's not SDVOB, the same i2c adapter may be used for HDMIB, with the adjusted config (i.e. with GPIO bit-banging instead of gmbus). Restore i2c adapter config before error return from intel_sdvo_init(), letting HDMIB enjoy the joys of gmbus. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915/sdvo: force GPIO bit-banging also on default pinJani Nikula
commit 63abf3edaf42d0b9f278df90fe41c7ed4796b6b1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Dec 8 16:48:21 2010 +0000 drm/i915/sdvo: Only use the SDVO pin if it is in the valid range added a default fallback if BIOS provides an invalid pin mapping, but failed to force GPIO bit-banging on it. Finish the job, and also clean up the function a bit. With bit-banging, setting the gmbus speed has no effect, so drop it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> [danvet: Extend comment about gmbus in the code a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915: enable DDI eDPPaulo Zanoni
Now that all the eDP enablement bits are there, we can actually try to use the eDP. 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>
2012-10-26drm/i915: turn the eDP DDI panel on/offPaulo Zanoni
It's an important step :) 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>
2012-10-26drm/i915: set/unset the DDI eDP backlightPaulo Zanoni
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>
2012-10-26drm/i915: set the correct eDP aux channel clock divider on DDIPaulo Zanoni
The cdclk frequency is not always the same, so the value here should be adjusted to match it. Version 2: call intel_ddi_get_cdclk_freq instead of reading CDCLK_FREQ, because the register is just for earlier HW steppings. 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>
2012-10-26drm/i915: select the correct pipe when using TRANSCODER_EDPPaulo Zanoni
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>
2012-10-26drm/i915: implement workaround for VTOTAL when using TRANSCODER_EDPPaulo Zanoni
See the documentation for the DDI_FUNC_CTL register, EDP Input Select bits: when the EDP input selection is B, the VTOTAL_B must be programmed with the VTOTAL_EDP value, same thing for selection C. V2: Use I915_READ as suggested by Daniel Vetter. 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>
2012-10-26drm/i915: convert pipe timing definitions to transcoderPaulo Zanoni
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>
2012-10-26drm/i915: convert CPU M/N timings to transcoderPaulo Zanoni
Same thing as the previous commits. Not renaming this one since it exists since way before Haswell. 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>
2012-10-26drm/i915: convert PIPE_MSA_MISC to transcoderPaulo Zanoni
Same as the other registers. This one also appeared on Haswell for the first time, so that's why we are renaming it. 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>
2012-10-26drm/i915: convert PIPECONF to use transcoder instead of pipePaulo Zanoni
Because the PIPECONF register is actually part of the CPU transcoder, not the CPU pipe. Ideally we would also rename PIPECONF to TRANSCONF to remind people that they should use the transcoder instead of the pipe, but let's keep it like this for now since most Gens still name it PIPECONF. 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>
2012-10-26drm/i915: check TRANSCODER_EDP on intel_modeset_setup_hw_statePaulo Zanoni
We need to check if any of the pipes is using TRANSCODER_EDP. V2: DDI_BUF_CTL was renamed, so fix the usage here. 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>
2012-10-26drm/i915: convert DDI_FUNC_CTL to transcoderPaulo Zanoni
Because there's one instance of the register per CPU transcoder and not per CPU pipe. This is another register that appeared for the first time on Haswell, and even though its Haswell name is PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's just use the new naming scheme before it confuses more people. Notice that there's a big improvement on intel_ddi_get_hw_state due to the new TRANSCODER_EDP. V2: Also rename the register to TRANS_DDI_FUNC_CTL as suggested by Damien Lespiau. 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>
2012-10-26drm/i915: convert PIPE_CLK_SEL to transcoderPaulo Zanoni
This register appeared in Haswell. It does not have an EDP version because the EDP transcoder is always tied to the DDIA clock. Notice that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder is TRANSCODER_EDP we might introduce a bug, that's why this is a transcoder register even though it does not have an EDP version. Even though Haswell names this register PIPE_CLK_SEL, it will be renamed to TRANS_CLK_SEL in the future, so let's just start using the real name that makes more sense and avoids misusage. 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>
2012-10-26drm/i915: add TRANSCODER_EDPPaulo Zanoni
Before Haswell we used to have the CPU pipes and the PCH transcoders. We had the same amount of pipes and transcoders, and there was a 1:1 mapping between them. After Haswell what we used to call CPU pipe was split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A, B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder (only used for VGA). For all the outputs except for EDP we have an 1:1 mapping on the CPU pipes and CPU transcoders, so if you're using CPU pipe A you have to use CPU transcoder A. When have an eDP output you have to use transcoder EDP and you can attach this CPU transcoder to any of the 3 CPU pipes. When using VGA you need to select a pair of matching CPU pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the PCH transcoder. For now we're just creating the cpu_transcoder definitions and setting cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the registers was ported to use transcoder instead of pipe. The goal is to keep the code backwards-compatible since on all cases except when using eDP we must have pipe == cpu_transcoder. V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau and Daniel Vetter. We currently need the haswell_crtc_off chunk because TRANSCODER_EDP can be used by any CRTC, so when you stop using it you have to stop saying you're using it, otherwise you may have at some point 2 CRTCs claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled one), then the HW state readout code will get completely confused. In other words: Imagine the following case: xrandr --output eDP1 --auto --crtc 0 xrandr --output eDP1 --off xrandr --output eDP1 --auto --crtc 2 After the last command you could get a "pipe A assertion failure (expected off, current on)" because CRTC 0 still claims it's using TRANSCODER_EDP, so the HW state readout function will read it (through PIPECONF) and expect it to be off, when it's actually on because it's being used by CRTC 2. So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we make sure we're pointing to our own original CRTC which is certainly not used by any other CRTC. 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>
2012-10-26drm/i915: don't call Haswell PCH code when we can't or don't needPaulo Zanoni
On Ironlake we have one PCH transcoder and FDI per pipe, so we know that if ironlake_crtc_driving_pch returns false we can disable the PCH transcoder and we also know that when we disable the crtc we can also disable the PCH transcoder. On Haswell there is only 1 PCH transcoder and FDI and they can be used by any CRTC. So if for one specific crtc haswell_crtc_driving_pch returns false we can't assert anything about the state of the PCH transcoder or the FDI link without checking if any other CRTC is using the PCH. So on this commit remove the "assert_fdi_{t,r}x_disabled" form haswell_crtc_enable and also only disable FDI and the PCH transcoder if the port being disabled was actually a PCH port (we only have one port using PCH: the VGA port). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915: simplify intel_crtc_driving_pchPaulo Zanoni
By forking Ironlake and Haswell functions. The only callers are {ironlake,haswell}_crtc_enable anyway, and this way we won't need to add other checks on the Haswell version for the next gens. V2: Even simpler, as pointed by Jani Nikula. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915: fix checks inside haswell_crtc_{enable, disable}Paulo Zanoni
These functions were forked from their Ironlake versions, so now fix the gen checks to reflect the fact that they will only run on Haswell. It is worth noticing that we are not considering IBX/CPT possible on Haswell anymore. So far on Haswell enablement we kept trying to still consider IBX/CPT as a possibility with a Haswell CPU, but this was never tested, I really doubt it will work with the current code and we don't really have plans to support it. Future patches will remove the IBX/CPT code from other Haswell functions. Notice that we still have a WARN on haswell_crtc_mode_set in case we detect non-LPT PCH. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915: fix checks inside ironlake_crtc_{enable, disable}Paulo Zanoni
The last commit forked a Haswell version, so now we remove Haswell code from these functions. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915: fork a Haswell version of ironlake_crtc_{enable, disable}Paulo Zanoni
The way we enable and disable the PCH on Haswell changed considerably since now we have only one PCH transcoder, so we can't keep the same asserts and we also can't just unconditionally disable the PCH transcoder for non-PCH outputs. So let's fork a Haswell version. These new functions look exactly the same as the ironlake versions. The next patches will introduce the differences. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v0.10.2 at 2024-11-15 01:49:55 (GMT)