summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-11-12drm/i915: don't assert_pch_ports_disabled on LPTPaulo Zanoni1-3/+0
That function is made for IBX. Running it on LPT will trigger tons of "unclaimed register" errors. The only port remaining on LPT is PCH_ADPA. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: don't rely on previous values when setting LPT TRANSCONFPaulo Zanoni1-3/+2
Because we already set all the bits we can set. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: apply by hand due to dropped patch. Also, obey my OCD a bit and do a s/_TRANSACONF/TRANSCONF(TRANSCODER_A)/, makes it more consisten with other lpt pch code imnsho ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: use CPU and PCH transcoders on lpt_enable_pch_transcoderPaulo Zanoni1-15/+9
... instead of using "pipe". As already explained in previous commits, since Haswell/LPT cpu_transcoder, pch_transcoder and pipe are not the same thing. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: don't assert_pch_pll_enabled on lpt_enable_pch_transcoderPaulo Zanoni1-6/+0
These asserts are specific to IBX/CPT/PPT. Inside the assert_pch_pll function we even "return" in case we detect LPT, but I prefer to just not call it. In the future we might rename to something like ibx_assert_pch_pll. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: remove IBX code from lpt_enable_pch_transcoderPaulo Zanoni1-14/+1
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: remove Haswell code from ironlake_enable_pch_transcoderPaulo Zanoni1-4/+0
Since now we have lpt_enable_pch_transcoder. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: fork lpt version of ironlake_{en, dis}able_pch_transcoderPaulo Zanoni1-2/+75
For now the new functions are just copies. Differences will be added later. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: rename intel_{en, dis}able_transcoderPaulo Zanoni1-8/+8
To ironlake_{en,dis}able_pch_transcoder since these functions will be different on Haswell/LPT and since the "transcoder" they {en,dis}able is on the PCH. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: again a small conflict because the fdi disable sequenc looks a bit different here.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: use the CPU and PCH transcoders on lpt_pch_enablePaulo Zanoni1-9/+10
On Haswell/LPT, pipe, cpu_transcoder and pch_transcoder are different things with different values, unlinke the previous gens. So here we use the right thing at the right place. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: apply the patch by hand due to the reorder patch sequence. We also can't kill all uses of pipe where we should, since the fdi link train code isn't fixed up yet on this baselin.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: don't assert_panel_unlocked on LPTPaulo Zanoni1-2/+1
There is no LVDS, so don't poke the LVDS registers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: don't call ironlake_enable_pch_pll on lpt_pch_enablePaulo Zanoni1-9/+0
This is just wrong. The lpt_program_iclkip should disable the PCH pixel clocks (and yes, we plan to rename it later). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: rename intel_enable_pch_pll to ironlake_enable_pch_pllPaulo Zanoni1-4/+4
Because this function is only for the older PCHs, not the newer ones. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: remove ironlake bits from lpt_pch_enablePaulo Zanoni1-68/+1
Since this function will only run on Haswell/LPT and newer. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: remove Haswell/LPT bits from ironlake_pch_enablePaulo Zanoni1-6/+2
Since now we have lpt_pch_enable for them. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: add lpt_pch_enablePaulo Zanoni1-1/+110
For now it's just a fork of ironlake_pch_enable. The next commits will change this. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: use intel_ddi_get_hw_state on CRT encoder tooPaulo Zanoni1-1/+4
Because things changed on Haswell/LPT and the bits checked by intel_crt_get_hw_state have moved to other registers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: don't set ADPA pipe select on LPTPaulo Zanoni1-1/+3
Those bits just don't exist on LPT. The CRT DAC, PCH transcoder and FDI RX are always connected to DDI E. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: move encoder->mode_set calls to crtc_mode_setDaniel Vetter1-15/+15
Makes more sense to group the entire mode_set stage into one function. Noticed while discussiing the rather confusing set of function names with Paulo Zanoni. Unfortunately I don't have an idea to make the function names lesss confusion. v2: Use for_each_encoder_on_crtc as suggested by Chris Wilson. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: Introduce intel_crtc_update_sarea_pos()Ville Syrjälä1-15/+28
Refactor the code that stores the panning x/y position into the sarea. This also changes the code so that it won't mistakenly update sareaB_x/y for pipe >= C. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: Bad pixel formats can't reach the sprite codeVille Syrjälä1-6/+2
The framebuffer pixel format is already checked by the common code. So there's no way an invalid format could reach the driver. So instead of falling back to a default format, call BUG(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: pixel_size == cppVille Syrjälä1-16/+3
Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: Check the framebuffer offsetVille Syrjälä1-0/+4
The current code can't deal with framebuffers with an offset. Return an error when trying to create such a framebuffer until the rest of the code is fixed to handle them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: Check framebuffer stride more thoroughlyVille Syrjälä1-0/+8
Make sure the the framebuffer stride is smaller than 32k. That seems to be the limit on recent hardware. Not quite sure if <=Gen4 has smaller limits. Also when using a tiled memory make sure the object stride matches the framebuffer stride. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: Fix display pixel format handlingVille Syrjälä2-37/+74
Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float format). Fix intel_init_framebuffer() to match hardware and driver limitations: * RGB332 is not supported at all * CI8 is supported * XRGB1555 & co. are supported on Gen3 and earlier * XRGB210101010 & co. are supported from Gen4 onwards * BGR formats are supported from Gen4 onwards * YUV formats are supported from Gen5 onwards (driver limitation) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: move more pte encoding to pte encodeBen Widawsky1-29/+27
In order to handle differences in pte encoding between architectures it is desirable to have one helper function, pte_encode, do it all for us. As such, this commit moves the code around so we're in good shape to do that. Luckily the ppgtt pte and the ggtt pte look very similar. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: Extract PPGTT pte encodingBen Widawsky1-5/+16
HSW will change the PTE encoding, and laying this out now will be helpful when we're ready to implement that. More importantly, GGTT and PPGTT PTE encoding is quite similar, so moving this out into a helper function will enable us to lance the AGP layer. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: introduce gtt_pte_tBen Widawsky1-6/+8
This will make the calculations of size easier to read instead of just assuming uint32_t everywhere. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: Add dev to ppgttBen Widawsky2-2/+4
Some subsequent commits will need to know what generation we're running on to do different pte encoding for the ppgtt. Since it's not much hassle or overhead to store it in the ppgtt structure, do that. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: No LLC_MLC for HSW.Ben Widawsky1-3/+7
The mid-level cache or as it's more commonly referred to now as L3, is not setup this way on HSW. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915/ringbuffer: exclude last 2 cachelines on 845g on all callpathsMika Kuoppala1-1/+1
Make intel_render_ring_init_dri and intel_init_ring_buffer symmetrical with regards of workaround introduced by: commit 27c1cbd06a7620b354cbb363834f3bb8df4f410d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 9 13:59:46 2012 +0100 drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-12drm/i915: create the DDI encoderPaulo Zanoni4-100/+144
Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it inits the encoder and then calls the proper init_connector functions. Notice that for non-eDP ports we call both HDMI and DP connector init, so we have 2 connectors attached to each DDI encoder. After this change, intel_hdmi_init and intel_dp_init are only called by Ivy Bridge and earlier, while hardware containing DDI outputs should call intel_ddi_init. Also added/removed quite a few "static" keywords due to the fact that some function pointers were moved from intel_dp.c and intel_hdmi.c to intel_ddi.c. DP finally works on Haswell now! \o/ 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-12drm/i915: add intel_ddi_connector_get_hw_statePaulo Zanoni4-2/+50
We need this since now on DDI we will have 2 connectors on each encoder. 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-12drm/i915: add port field to intel_digital_portPaulo Zanoni4-26/+25
Both "intel_dp" and "intel_hdmi" structs had a "port" field, which always had the same value. It makes more sense to move this to intel_digital_port, so we can know the port independently of the connector type. 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-12drm/i915: reset intel_encoder->type when DP or HDMI is detectedPaulo Zanoni2-0/+8
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-12drm/i915: split intel_dp_init into encoder and connector piecesPaulo Zanoni1-57/+67
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-12drm/i915: split intel_hdmi_init into encoder and connector piecesPaulo Zanoni1-43/+53
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-12drm/i915: create intel_digital_port and use itPaulo Zanoni3-36/+78
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-12drm/i915: add intel_dp_to_dev and intel_hdmi_to_devPaulo Zanoni2-23/+34
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-12drm/i915: simplify assignments inside intel_dp.cPaulo Zanoni1-20/+21
- 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-12drm/i915: Fix HSW power well control state readZhenyu Wang1-1/+1
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-12drm/i915: Flush using only the correct base address registerDamien Lespiau1-2/+4
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-12drm/i915: implement WaDisableRenderCachePipelinedFlushDaniel Vetter2-0/+9
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-12drm/i915: implement WaIssueDummyWriteToWakeupFromRC6Daniel Vetter1-0/+13
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-12drm/i915: adjust sprite base addressDamien Lespiau3-27/+41
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-12drm/i915: Fix sprite offset on HSWDamien Lespiau2-1/+10
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-12drm/i915: Fix primary plane offset on HSWDamien Lespiau2-2/+9
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-12drm/i915: Error out when trying to set a y-tiled as a spriteDamien Lespiau1-0/+9
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-12drm/i915/tv: Use intel_flush_display_plane() to flush the primary planeDamien Lespiau1-5/+2
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-12drm/i915: check fdi B/C lane sharing constraintDaniel Vetter2-6/+121
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-12drm/i915: add ->display.modeset_global_resources callbackDaniel Vetter2-0/+4
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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 21:47:23 +0300