- 15 Nov, 2018 5 commits
-
-
Jani Nikula authored
Their user has vanished in the course of history. Remove. Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181115105237.1237-2-jani.nikula@intel.com
-
Jani Nikula authored
Conform to function naming in intel_bios.c. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Clint Taylor authored
reorder structure of 297, 594 N values to group Audio Sample Frequencies together to make updating from HDMI specification easier. V2: Match patch 1/2 version V3: Arrange by sample freq, then pixel clock. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Jani Nikula authored
While removing .palette_offsets, I removed the commas after .trans_offsets in the macros, but failed to remove the line continuation backslashes. While at it, also remove another extra comma to be in line with the other related macros. Fixes: 74c1e826 ("drm/i915: remove palette_offsets from device info in favor of _PICK()") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Use intel_plane_destroy_state in intel_plane_free to free the state. Also fix intel_plane_alloc() to use __drm_atomic_helper_plane_reset(), to get sane defaults from the atomic core. This is needed to get the correct alpha value and blend mode from the core, and any new default values added from new properties. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by:
-
- 14 Nov, 2018 9 commits
-
-
Imre Deak authored
Even though PW#1 and the MISC_IO power wells are managed by the DMC firmware (toggled dynamically if conditions allow it) from the driver's POV they are always on if the display core is initialized (always restored by DMC to the enabled state after exiting from DC5/6 for instance b/c of MMIO access). Accordingly we can just mark them as always-on and remove the special casing for them during state verification (thus enabling verification for these power wells too). Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
We can just use a proper true/false initializer even for bitfields, which is more descriptive. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
A DMC bug on GEN9 big core machines fails to restore the driver's request bits for the PW1 and MISC_IO power wells after a DC5/6 entry->exit sequence. As a consequence the driver's subsequent check for the enabled status of these power wells will fail, as the check considers the power wells being enabled only if both the status and request bits are set. To work around this borrow the request bits from BIOS's own request register in which DMC forces on the request bits when exiting from DC5/6. This fixes a problem reported by Ramalingam, where HDCP init failed, since PW1 reported itself as being disabled, while in reality it was enabled. Reported-by:
Ramalingam C <ramalingam.c@intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
Align icl workarounds whitespace with the rest of the file Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145333.10570-2-mika.kuoppala@linux.intel.com
-
Mika Kuoppala authored
This got duplicated on introducing icl workarounds. Fix by using the older definition and moving the wa bit definition there. No functional changes. v3: avoid fixes tag, whitespace (Chris) References: 908ae051 ("drm/i915/icl: WaDisCtxReload") Signed-off-by:
-
Mika Kuoppala authored
Register DBUF_CTL_S2 is read and it's value is not used. As there is no explanation why we should prime the hardware with read, remove it as spurious. Fixes: aa9664ff ("drm/i915/icl: Enable 2nd DBuf slice only when needed") Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Paulo Zanoni authored
I think I'm probably the one who argued in favor of having separate implementations for both PCHs, but the calculations are actually the same, the clocks are the same and the only difference is that on ICP we write the numerator to the register. I have previously suggested to kill cnp_rawclk() and keep the icp_rawclk() style, but Ville gave some good arguments that what's in this patch may be the better choice. v2: Switch numerator to 1 from 1000 and adjust calculations accordingly (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-3-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
Although CNP names this field "Counter Fraction", what we write to the register is really the denominator for the fractional part of the divider, not the fractional part (and the field description even says that). The ICP spec renamed the field to "Counter Fraction Denominator", which makes a lot more sense. Use the more complete ICL naming because we will merge the CNP and ICP functions into a single one, which will introduce the concept of the numerator. That will make a lot more sense when you read the "num/frac = den" calculation. Reviewed-by:
-
Paulo Zanoni authored
BSpec was updated and now there's no more "subtract 1" to the Microsecond Counter Divider field. It seems this should help fixing some GMBUS issues. I'm not aware of any specific open bug that could be solved by this patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
- 13 Nov, 2018 6 commits
-
-
Ville Syrjälä authored
VBT appears to have two (or possibly three) ways to indicate the panel rotation. The first is in the MIPI config block, but that apparenly usually (maybe always?) indicates 0 degrees despite the actual panel orientation. The second way to indicate this is in the general features block, which can just indicate whether 180 degress rotation is used. The third might be a separate rotation data block, but that is not at all documented so who knows what it may contain. Let's try the first two. We first try the DSI specicic VBT information, and it it doesn't look trustworthy (ie. indicates 0 degrees) we fall back to the 180 degree thing. Just to avoid too many changes in one go we shall also keep the hardware readout path for now. If this works for more than just my VLV FFRD the question becomes how many of the panel orientation quirks are now redundant? v2: Move the code into intel_dsi.c (Jani) Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com>
-
Ville Syrjälä authored
Let's make sure the DSI port is actually on before we go poking at the plane register to determine which way it's rotated. Otherwise we could be looking at a plane that is feeding a HDMI port for instance. And in order to read the plane register we need the power well to be on. Make sure that is indeed the case. We'll also make sure the plane is actually enabled before we trust the rotation bit to tell us the truth. v2: s/intel_dsi/vlv_dsi/ Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
No point in cluttering the common codepaths with the skip_intermediate_wm handling. Just move it into ilk_compute_intermediate_wm() as those are the only platforms using this. Signed-off-by:
-
Ville Syrjälä authored
To get the initial phase correct we need to account for the scale factor as well. I forgot this initially and was mostly looking at heavily upscaled content where the minor difference between -0.5 and the proper initial phase was not readily apparent. And let's toss in a comment that tries to explain the formula a little bit. v2: The initial phase upper limit is 1.5, not 24.0! Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 0a59952b ("drm/i915: Configure SKL+ scaler initial phase correctly") Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
-
Ville Syrjälä authored
Reduce the clutter in the sprite update functions by writing both TILEOFF and LINOFF registers unconditionally. We already did this for primary planes so might as well do it for the sprites too. There is no harm in writing both registers. Which one gets used depends on the tilimg mode selected in the plane control registers. It might even make sense to clear the register that won't get used. That could make register dumps a little easier to parse. But I'm not sure it's worth the extra hassle. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We no longer change LSPCON into PCON mode if it boots up in LS mode. This was broken by some code shuffling in commit 96e35598 ("drm/i915: Check LSPCON vendor OUI"). I actually can't see a reason why that code shuffling had to be done. The commit msg notes it but doesn't justify it in any way. But I guess we'll keep the code in its current place anyway and just make the "switch to PCON mode" part effective once again. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Tested-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Fixes: 96e35598 ("drm/i915: Check LSPCON vendor OUI") Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com>
-
- 12 Nov, 2018 4 commits
-
-
Lionel Landwerlin authored
subslice_mask is an array indexed by slice, not subslice. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 8cc76693 ("drm/i915: store all subslice masks") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108712Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112123931.2815-1-lionel.g.landwerlin@intel.com
-
Ville Syrjälä authored
Pass on the errno all the way from connected_sink_max_bpp(), and make the base_bpp handling in intel_modeset_pipe_config() a bit less ugly. We'll also rename connected_sink_max_bpp() to not give the impression that it return the bpp value, and we'll pimp up the debug message within to include the connector name/id. Signed-off-by:
-
Ville Syrjälä authored
We just 'return ret' immediately after jumping to the label. Let's return directly instead. Signed-off-by:
-
Ville Syrjälä authored
ironlake_check_fdi_lanes() may try to grab some extra crtc locks. If that fails we need to propagate the -EDEADLK all the way up, and we shouldn't dump out the crtc state or other debug messages either since it wasn't the crtc state that caused the failure. Just hit this on my IVB: [drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 3 [drm:intel_atomic_check [i915]] only 2 lanes on pipe C: required 3 lanes [drm:intel_atomic_check [i915]] fdi link bw constraint, reducing pipe bpp to 18 [drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 2 [drm:intel_atomic_check [i915]] CRTC bw constrained, retrying [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 4 max rate 270000 max bpp 18 pixel clock 185580KHz [drm:intel_dp_compute_config [i915]] DP lane count 4 clock 162000 bpp 18 [drm:intel_dp_compute_config [i915]] DP link rate required 417555 available 648000 [drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 2 WARNING: CPU: 4 PID: 25115 at ../drivers/gpu/drm/drm_modeset_lock.c:241 drm_modeset_lock+0xbc/0xd0 [drm] ... WARNING: CPU: 4 PID: 25115 at ../drivers/gpu/drm/drm_modeset_lock.c:223 drm_modeset_drop_locks+0x4a/0x50 [drm] The warnings are from 'WARN_ON(ctx->contended)'. Signed-off-by:
-
- 09 Nov, 2018 16 commits
-
-
Daniele Ceraolo Spurio authored
We dump the info as an array of u8, so we want to know the length in number of bytes. Current code is still safe because the variable we use BITS_PER_TYPE on is a u8. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
We have a subslice mask per slice, not per subslice. MAX_SUBSLICES > MAX_SLICES, so the wrong size didn't cause any issue apart from using extra memory. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
José Roberto de Souza authored
In the past we had hooks to configure HW for VLV/CHV too, in the drop of VLV/CHV support the intel_psr_disable_source() code was not moved to the caller, so doing it here. Suggested-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-4-jose.souza@intel.com
-
José Roberto de Souza authored
All other interruptions gen11 interruptions are reset in gen11_irq_reset() also it is done for other gens that supports PSR. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
José Roberto de Souza authored
It should always wait for idle state when disabling PSR because PSR could be inactive due a call to intel_psr_exit() and while PSR is still being disabled asynchronously userspace could change the modeset causing a call to psr_disable() that will not wait for PSR idle and then PSR will be enabled again while PSR is still not idle. v2: rebased on top of the patch reusing psr_exit() Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Both functions have the same code to disable PSR, so let's reuse that code instead of duplicate. Suggested-by:
-
Ville Syrjälä authored
Make skl_ddb_allocation_overlaps() useful for other callers besides skl_update_crtcs(). We'll need it to do plane updates as well. And while we're here we can reduce the stack utilization a bit by noting that each struct skl_ddb_entry is 4 bytes whereas a pointer to one is 8 bytes (on 64bit). So we'll switch to an array of structs from the array of pointers we used before. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
On skl+ the scaler (when enabled) will take care of the plane output position. Make the code less ugly by just setting crtc_x/y to 0 when the scaler is enabled. Signed-off-by:
-
Ville Syrjälä authored
Due to the constant alpha we're going to have to program two of the the tree keying registers anyway, so might as well always program all three. And parametrize the plane constant alpha define while at it. v2: Rebase due to input CSC Signed-off-by:
-
Ville Syrjälä authored
If we don't need the PS_PWR_GATE write when programming the pipe scaler I don't see why we'd need it for plane scalers either. Just remove it. Signed-off-by:
-
José Roberto de Souza authored
MST is only supported in DDI ports that have this hook, so the null check can be dropped. Suggested-by:
-
José Roberto de Souza authored
MST ports did not had the post_pll_disable() hook causing the references get in pre_pll_enable() never being released causing DDI and AUX CH being enabled all the times. v2: renamed intel_mst_post_pll_disable_dp() parameters Reviewed-by:
-
José Roberto de Souza authored
intel_dp_detect() caches the aux_domain in the beginning of the function as it is used twice, so lets also use it as the aux_domain don't change in runtime. v3: returning intel_dp_retrain_link() error insted of connector_status_disconnected Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Ville Syrjälä authored
IBX has a documented workaround which states that when we disable the port we must change its transcoder select to A, otherwise it will prevent the other port (DP vs. HDMI/SDVO) from using transcoder A. We implement the workaround during encoder disable, but looks like some BIOSen leave transcoder B selected even when the port wasn't actually enabled by the BIOS. That will trip up our asserts that attempt to make sure we never forget this w/a. Sanitize the transcoder select to A for all disabled PCH DP/HDMI/SDVO ports. We assume that the port was never enabled by the BIOS on transcoder B, because if it had we'd actually have to toggle the port on and back off to properly switch it back to transcoder A. That would cause some display flicker if transcoder A is already enabled on some other port, so it's better not to do it unless absolutely necessary. Since we have no indication that the transcoder select is misbehaving on the affected machines we can assume the port was never actually enabled by the BIOS. This cures warning like this during driver load: IBX PCH DP C still using transcoder B WARNING: CPU: 2 PID: 172 at drivers/gpu/drm/i915/intel_display.c:1279 assert_pch_dp_disabled+0x9e/0xb0 [i915] v2: Add comments to remind the reader that SDVOB==HDMIB (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
In my haste to remove irq_port[] I accidentally changed the way we deal with hpd pins that are shared by multiple encoders (DP and HDMI for pre-DDI platforms). Previously we would only handle such pins via ->hpd_pulse(), but now we queue up the hotplug work for the HDMI encoder directly. Worse yet, we now count each hpd twice and this increment the hpd storm count twice as fast. This can lead to spurious storms being detected. Go back to the old way of doing things, ie. delegate to ->hpd_pulse() for any pin which has an encoder with that hook implemented. I don't really like the idea of adding irq_port[] back so let's loop through the encoders first to check if we have an encoder with ->hpd_pulse() for the pin, and then go through all the pins and decided on the correct course of action based on the earlier findings. I have occasionally toyed with the idea of unifying the pre-DDI HDMI and DP encoders into a single encoder as well. Besides the hotplug processing it would have the other benefit of preventing userspace from trying to enable both encoders at the same time. That is simply illegal as they share the same clock/data pins. We have some testcases that will attempt that and thus fail on many older machines. But for now let's stick to fixing just the hotplug code. Cc: stable@vger.kernel.org # 4.19+ Cc: Lyude Paul <lyude@redhat.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: b6ca3eee ("drm/i915: Nuke dev_priv->irq_port[]") Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Imre Deak authored
We shouldn't consider an encoder inactive if it doesn't have a CRTC linked, but has virtual MST encoders with a crtc linked. Fix this. Also we should not sanitize the mapping for MST encoders, as it's always their primary encoder (which could be even in SST mode) whose active state determines if we need the clock being enabled for the corresponding physical port. Fix this too. This fixes at least an existing breakage where we incorrectly disabled the clock for an active DP encoder when sanitizing its MST virtual encoders. Not sure if there are BIOSes that enable an output in MST mode, but our HW readout is mostly missing for it anyway, so just warn for that case. Fixes: 70332ac5 ("drm/i915/icl+: Sanitize port to PLL mapping") Cc: Antonio Argenziano <antonio.argenziano@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reported-by:
Antonio Argenziano <antonio.argenziano@intel.com> Signed-off-by:
-
