- 16 Oct, 2020 5 commits
-
-
Ville Syrjälä authored
Remove the lspcon special case from intel_dp_compute_config() and just treat it like any other DFP than can do 4:4:4->4:2:0 conversion. The only difference between the two codepaths was that the lspcon code tried to already halve port_clock. That was just total nonsense as we hadn't even computed the base port_clock at that time. All that stuff happens intel_dp_compute_link_config*() and it already takes care of the 4:2:0 clock reduction. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924184156.24491-2-ville.syrjala@linux.intel.comReviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
crtc_state->lspcon_downsampling isn't particularly useful at the moment since we can't even do proper readout for it. Let's get rid of it. Will help with unifying the LSPCON with the regular DFP YCbCr output support. Signed-off-by:
-
Ville Syrjälä authored
Currently we leave the cache_level of the initial fb obj set to NONE. This means on eLLC machines the first pin_to_display() will try to switch it to WT which requires a vma unbind+bind. If that happens during the fbdev initialization rcu does not seem operational which causes the unbind to get stuck. To most appearances this looks like a dead machine on boot. Avoid the unbind by already marking the object cache_level as WT when creating it. We still do an excplicit ggtt pin which will rewrite the PTEs anyway, so they will match whatever cache level we set. Cc: <stable@vger.kernel.org> # v5.7+ Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381Signed-off-by:
-
Ville Syrjälä authored
WAC6entrylatency is trying to fix excessive rc6 entry latency caused by the extra delay from FBC_LLC_READ_CTRL, which is there for some extra sync with uncore for frame buffer caching in LLC. Reading through the hsd the recommendation was to set the FBC_LLC_FULLY_OPEN bit to disable this extra delay entirely. This can be done whenever fb LLC caching is not used. The alternative suggestion was to reduce the delay to eg. 0x5 via updated BIOS programming instructions. But all the kbl/cfl machines I've seen still have the default 0xff programmed. As we never use fb LLC caching let's just apply the w/a to all skl derivatives to get consistent rc6 latencies. I was able to measure the effect of FBC_LLC_READ_CTRL to rc6 latency via forcewake. Here's a graph of some of the results: sleep;fw_req=1;wait fw_ack==1;sleep;fw_req=0;wait fw_ack==0 fw_ack==1 duration 160us +----------------------------------------------------------------+ | + + $$+ + + | | $$ $ $ ******$$ ** $ $**$* #########$$######| 140us |-$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$*$$$$$$$$$$$$$$$$ $$$$$$| | $ * # | | $ * # | 120us |$+ * # +-| |$ * # | |$ * # # | 100us |$+ ************######################## +-| |$ * *# | |$ ***** ######### | 80us |$+ * # #### ## +-| |$ **** ### # # | | ** #### FBC_LLC_READ_CTRL: 0x8000 ******* | 60us |-###### FBC_LLC_READ_CTRL: 0xffff #######-| |## + + FBC_LLC_READ_CTRL: 0x400000ff $$$$$$$ | +----------------------------------------------------------------+ 0ms 10ms 20ms 30ms 40ms 50ms 60ms sleep duration The default FBC_LLC_READ_CTRL value of 0xff is documented to give us a 170usec delay. That tracks well with the knees at 0xffff->~44msec and 0x8000->~22msec we see in the graph. We can see that if we sleep longer than the FBC_LLC_READ_CTRL delay we always observe the full (~145usec) rc6 wakeup latency. But if we sleep for less than the FBC_LLC_READ_CTRL delay we see a quicker fw wakeup, presumably due the hardware not having yet entered rc6 fully. The other plateaus in the graph I suspect correspond to some shallower internal rc states. v2: s/usec/msec/ typo in commit msg Signed-off-by: -
Matt Roper authored
A recent bspec update has provided a new cdclk table for RKL. All of the cdclk values are the same as those we've been using on ICL, TGL, etc., but we obtain them by doubling both the PLL ratio and CD2X divider numbers. Bspec: 49202 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201015220038.271740-1-matthew.d.roper@intel.com
-
- 15 Oct, 2020 11 commits
-
-
Michel Thierry authored
While we do lack the faster shared LLC, we should still have support for snooping over PCIe. Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Anshuman Gupta authored
Update the DMC_DEBUG_DC5 register to its new location and do not try reading the DC6 counter since DG1 doesn't support DC6. v2: Use IS_DGFX() instead of IS_DG1(). Even if not having DC6 is not directly related to DGFX, the register move to a new location is. So in future, if there is one supporting DC6, it would just need to add the other register rather than fixing the case of a wrong register being read (Matt) Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Anshuman Gupta authored
DC6 is not supported on DG1, so change the allowed DC mask for DG1. This is not yet on bspec, but it has been confirmed by HW engineers. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Stuart Summers authored
DG1 shares some workarounds with TGL and RKL and also has some additional workarounds of its own. v2: Correct location of Wa_1408615072 (JohnH). v3: Apply WAs 1606700617, 18011464164 and 22010931296 to DG1 (José) v4 (Anusha) - Add Wa_22010271021 - s/Wa_14010096844/Wa_1409836686 v5: - Extend Wa_14010919138 to all revs (Matt Atwood) - Power gate media is global gen12 design. (Rodrigo) - Rebase (Lucas) v6: use REG_BIT() to fix checkpatch warning (Lucas) BSpec: 53508 Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Matt Atwood authored
Add support to load DMC v2.0.2 on DG1 While we're at it, make TGL use the same GEN12 firmware size definition and remove obsolete comment. Bpec: 49230 v2: do not replace GEN12_CSR_MAX_FW_SIZE (from José) and replace stale comment Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Add DG1 DPLL Enable register macro and use the macro to enable the correct DPLL based on PLL id. Although we use _MG_PLL1_ENABLE/_MG_PLL2_ENABLE these are rather combo phys. While at it, fix coding style: wrong newlines and use if/else chain v2: Rewrite original patch from Aditya Swarup based on refactors upstream Bspec: 49443, 49206 Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-6-lucas.demarchi@intel.com
-
Aditya Swarup authored
Add entries for dg1 plls and setup dg1_pll_mgr to reuse ICL callbacks. Initial setup for shared dplls DPLL0/1 for DDIA/DDIB and DPLL2/3 for DDI-TC1/DDI-TC2. Configure dpll cfgcrx registers to drive the plls on DG1. v2 (Lucas): Reword commit message and add missing update_ref_clks hook (requested by Matt Roper) Signed-off-by:
-
Aditya Swarup authored
DG1 has 4 DPLLs where DPLL0 and DPLL1 drive DDIA/B and DPLL2 and DPLL3 drive DDI-TC1/DDI-TC2. Introduce DG1_DPLL_CFCRx() helper macros to configure DPLL registers. Bspec: 50288, 50299 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Lucas De Marchi authored
TGL power wells can be re-used for DG1 with the exception of the fake power well for TC_COLD. v2: use logic to skip power wells while copying instead of duplicating the definition of TGL power wells (Matt Roper) Bspec: 49182 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Lucas De Marchi authored
The skus guarded by IS_CNL_WITH_PORT_F() have port F and thus they need those power wells. The others don't have those. Up to now we were just overriding the number of power wells on !IS_CNL_WITH_PORT_F(), relying on those power wells to be the last ones. Now that we have logic in place to skip power wells by id, use it instead. Signed-off-by:
-
Aditya Swarup authored
This allows us to skip power wells on a platform allowing it to re-use the table from another one instead of having to create a new table from scratch that is basically a copy with a few removals. Cc: Imre Deak <imre.deak@intel.com> Suggested-by:
-
- 14 Oct, 2020 1 commit
-
-
Tejas Upadhyay authored
Recently we came across requirement to identify EHL and JSL platform to program them differently. Thus Split the basic platform definition, macros, and PCI IDs to differentiate between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced with IS_JSL_EHL everywhere. Changes since V1 : - Rebased to avoid merge conflicts - Added missed check for jasperlake in intel_uc_fw.c Cc : Matt Roper <matthew.d.roper@intel.com> Cc : Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201013192948.63470-1-tejaskumarx.surendrakumar.upadhyay@intel.com
-
- 12 Oct, 2020 9 commits
-
-
Aaron Ma authored
BOE 2270 panel failed to control backlight brightness. Add it in edid quirks to force using DPCD backlight control. Then the brightness can be controlled. Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201009085750.88490-2-aaron.ma@canonical.com
-
Aaron Ma authored
BOE panel with ID 2270 claims both PWM_PIN_CAP and AUX_SET_CAP backlight control bits, but default chip backlight failed to control brightness. Check AUX_SET_CAP and proceed to check quirks or VBT backlight type. DPCD can control the brightness of this pannel. Signed-off-by:
-
Sean Paul authored
In commit 79946723 ("drm/i915: Assume 100% brightness when not in DPCD control mode"), we fixed the brightness level when DPCD control was not active to max brightness. This is as good as we can guess since most backlights go on full when uncontrolled. However in doing so we changed the semantics of the initial 'backlight.enabled' value. At least on Pixelbooks, they were relying on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on boot such that enabled would be false. This causes the device to be enabled when the brightness is set. Without this, brightness control doesn't work. So by changing brightness to max, we also flipped enabled to be true on boot. To fix this, make enabled a function of brightness and backlight control mechanism. Fixes: 79946723 ("drm/i915: Assume 100% brightness when not in DPCD control mode") Cc: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Kevin Chowski <chowski@chromium.org>> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Imre Deak authored
The DP Standard's recommendation is to use the LTTPR non-transparent mode link training if LTTPRs are detected, so let's do this. Besides power-saving, the advantages of this are that the maximum number of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in transparent mode), and it provides a way to narrow down the reason for a link training failure to a given link segment. Non-transparent mode is probably also the mode that was tested the most by the industry. The changes in this patchset: - Pass the DP PHY that is currently link trained to all LT helpers, so that these can access the correct LTTPR/DPRX DPCD registers. - During LT take into account the LTTPR common lane rate/count and the per LTTPR-PHY vswing/pre-emph limits. - Switch to LTTPR non-transparent LT mode and train each link segment according to the sequence in DP Standard v2.0 (complete CR/EQ for each segment before continuing with the next segment). v2: - Switch to non-transparent mode during connector detection, which is required before reading the per-PHY LTTPR capabilities. - Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville) - Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the same logic to intel_dp_get_link_status(). (Ville) - Make intel_dp_lttpr_phy_caps() return a pointer to the whole array instead of a pointer to its first element. (Ville) - Add the intel_dp_phy_is_downstream_of_source() helper. (Ville) - Add a code comment about the disable->enable quirk of non-transparent mode. - Add the intel_dp_training_pattern_set_reg() helper. - Fix checkpatch/sparse warns. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
-
Imre Deak authored
By default LTTPRs should be in transparent link training mode, nevertheless in this patch we switch to this default mode explicitly. The DP Standard recommends this, supposedly because an LTTPR may be left in the non-transparent mode (by BIOS, previous kernel, or after reset due to a firmware bug). I haven't seen this happening, but let's follow the DP Standard. v2: - Add a code comment about the explicit disabling of non-transparent mode. v3: - Move check to prevent initing LTTPRs on eDP to init_dp_lttpr_init(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Add the helpers and register definitions needed to read out the common and per-PHY LTTPR capabilities and perform link training in the LTTPR non-transparent mode. v2: - Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead of adding these to i915. (Ville) v3: - Use memmove() to convert LTTPR to DPRX link status format. (Ville) Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Imre Deak authored
To prepare for a follow-up LTTPR change factor out a helper to disable the training pattern in DPCD. We'll need to do this for each LTTPR (without programming the port to output the idle pattern) when training in LTTPR non-transparent mode. While at it also move the disable-link-training logic from intel_dp_set_link_train() to intel_dp_stop_link_train(), since the latter is the only user of this. v2: - Move the disable-link-training logic to intel_dp_stop_link_train() (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Split the prepare, link training, fallback-handling steps into their own functions for clarity and as a preparation for the upcoming LTTPR changes. While at it also: - Unexport and inline intel_dp_set_idle_link_train(), which is used at a single place. - Add some documentation to functions that are exported or that can use a better description about which part of the LT sequence they implement. v2: (Ville) - Unexport/inline intel_dp_set_idle_link_train() - Make the documentation of intel_dp_prepare_link_train()/intel_dp_stop_link_train() more accurate wrt. HW specific details. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
An LTTPR can be trained with training pattern 4 even if the DPCD revision is < 1.4, but drm_dp_training_pattern_mask() would change pattern 4 to pattern 3 on those DPCD revisions. Since intel_dp_training_pattern() makes already sure that the proper training pattern is used, all that needs to be masked out is the scrambling disable flag, which is or'd to the mask later based on the training pattern. v2: - Use a helper instead of open-coding the masking. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 10 Oct, 2020 3 commits
-
-
Matt Roper authored
The updated bspec forcewake table also provides us with new multicast ranges that should be reflected in our workaround code. Note that there are different types of multicast registers with different styles of replication and different steering registers. The i915 MCR range lists we're updating here are only used to ensure we can verify workarounds properly (i.e., if we can't steer register reads we don't want to verify workarounds where an unsteered read might hit a fused-off instance of the unit). Because of this, we don't need to include any of the multicast ranges where all instances of the register will always present and fusing doesn't play a role. Specifically, that means that we are not including the MCR ranges designated as "SQIDI" in the bspec. Bspec: 66696 Cc: Caz Yokoyama <caz.yokoyama@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Matt Roper authored
The bspec's forcewake page was very stale and out of date for recent platforms. The hardware team finally provided us with an updated gen12 table (which applies to TGL, RKL, and DG1) and there are a lot of changes. v2: - Add comments showing the subregions of ranges that we've combined for ease of code review. (Jose) - Rebase on the s/FORCEWAKE_BLITTER/FORCEWAKE_GT/ patch Bspec: 66696 Cc: Caz Yokoyama <caz.yokoyama@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Matt Roper authored
The power well that we've been referring to as the 'blitter' well is actually more of a general GT power well which contains a lot of things other than the blitter engine registers. The FORCEWAKE_BLITTER name in the code was used for historic reasons, but no longer matches how the bspec describes this power well and just causes confusion for people not familiar with this area of the code. Let's rename it to FORCEWAKE_GT to more accurately describe the role of the power well and match how the modern bspec refers to it. v2: - Add a comment noting that the GT power well includes the blitter engine. (Jose) Bspec: 66696, 66534, 67609 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
- 09 Oct, 2020 11 commits
-
-
José Roberto de Souza authored
Another step towards PSR2 selective fetch, here programming plane selective fetch registers and MAN_TRK_CTL enabling selective fetch but for now it is fetching the whole area of the planes. The damaged area calculation will come as next and final step. v2: - removed warn on when no plane is visible in state - removed calculations using plane damaged area in intel_psr2_program_plane_sel_fetch() v3: - do not shift 16 positions the plane dst coordinates, only src is shifted v4: - only setting PLANE_SEL_FETCH_CTL_ENABLE and MCURSOR_MODE in PLANE_SEL_FETCH_CTL v5: - not masking bits for cursor BSpec: 55229 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007195238.53955-3-jose.souza@intel.com
-
José Roberto de Souza authored
Due to the debugfs flag, has_psr2 in CRTC state could have a different value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO and selective fetch) to be set to not a expected state. So here only taking in consideration the parameter and debugfs flag when computing PSR state, this way the CRTC state will also have the correct state. intel_psr_fastset_force() was already broken as intel_psr_compute_config() was already only enabling PSR when psr_global_enabled() and all other PSR requirements are met. So some changes was required in this function, now it iterates over all connectors, if it is a eDP connector and is active force a modeset in the CRTC driving this connector, what will cause the new PSR state to be set based on the debugfs flag. v2: - end connector iterator in error cases Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
For platforms without selective fetch this register is reserved so do not write 0 to it. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
This will be used in future but already adding to VBT so we are updated with VBT changes. Reviewed-by:
-
José Roberto de Souza authored
This will remove the "Expected child device config size for VBT version 235 not known" debug message seen in TGL, although this is not fixing anything it good to keep our VBT parser updated. Reviewed-by:
-
José Roberto de Souza authored
Child min_brightness is obsolete from VBT 234+, instead the new min_brightness field in the main structure should be used. This new field is 16 bits wide, so backlight_precision_bits is needed to check if value needs to be scaled down but it is only available in VBT 236+ so working around it by using the also new backlight_level in the main struct. v2: - missed that backlight_data->level is also obsolete v3: - s/backlight/brightness to better match specification - using u16 to specify brightness level instead of a u32 : 16 BSpec: 20149 Reviewed-by:
-
Ville Syrjälä authored
ggtt offsets/alignments are u32 everywhere else. Don't use a signed int for them here. Signed-off-by:
-
Ville Syrjälä authored
when the hardware isn't going to use the aux plane there's no real point in dealing with the relevant hardware restrictions. So let's just skip all that when not necessary. We can now also remove the offset=~0xfff behaviour for unused color planes. Let's just zero out everyting so as to not leave stale garbage behind to confuse people debugging the code. v2: Explicitly set AUX_DIST to zero when there is no aux plane Reviewed-by: Imre Deak <imre.deak@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
When the number of potential color planes grew to 4 we stopped setting all unused color plane offsets to ~0xfff. The code still tries to do this, but actually does nothing since the loop limits are bogus. skl_check_main_surface() actually depends on this ~0xfff behaviour as it will make sure to move the main surface offset below the aux surface offset because the hardware AUX_DIST must be a non-negative value [1], and for simplicity it doesn't bother checking if the AUX plane is actually needed or not. So currently it may end up shuffling the main surface around based on some stale leftover AUX offset. The skl+ plane code also just blindly calculates the AUX_DIST whether or not the AUX plane is actually needed by the hw or not, and that too will now potentially use some stale AUX surface offset in the calculation. Would seem nicer to guarantee a consistent non-negative AUX_DIST always. So bring back the original ~0xfff offset behaviour for unused color planes. Though it doesn't seem super likely that this inconsistency would cause any real issues. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Fixes: 2dfbf9d2 ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine") Signed-off-by:
-
Ville Syrjälä authored
i915_{save,restore}_state() are actually all about the display. Currently they are split into display part + SWF part. But since the SWF part is also related to the display let's just move that part into its own thing and flip the roles around so that the current display part is the main function. Signed-off-by:Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
As with eDP and LVDS we should also respect the power cycle delay on DSI panels. We are not using the power sequencer for these, and we have no optimizations around the sleep duration, so we just msleep() the whole thing away. Note that the ICL+ DSI code doesn't seem to have any power off/power cycle delay handling whatsoever. The only thing it handles is the power on delay. As that looks pretty busted in general I won't bother dealing with it for the time being. Signed-off-by:
-
