- 07 Jan, 2021 1 commit
-
-
Hans de Goede authored
drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence Commit 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode") added an intel_dsi_msleep() helper which skips sleeping if the MIPI-sequences have a version of 3 or newer and the panel is in vid-mode; and it moved a bunch of msleep-s over to this new helper. This was based on my reading of the big comment around line 730 which starts with "Panel enable/disable sequences from the VBT spec.", where the "v3 video mode seq" column does not have any wait t# entries. Given that this code has been used on a lot of different devices without issues until now, it seems that my interpretation of the spec here is mostly correct. But now I have encountered one device, an Acer Aspire Switch 10 E SW3-016, where the panel will not light up unless we do actually honor the panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence. What seems to set this model apart is that it is lacking a MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on delay usually happens. Fix the panel not lighting up on this model by using an unconditional msleep(panel_on_delay) instead of intel_dsi_msleep() when there is no MIPI_SEQ_DEASSERT_RESET sequence. Fixes: 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201118124058.26021-1-hdegoede@redhat.com
-
- 06 Jan, 2021 2 commits
-
-
Matt Roper authored
The bspec has been updated with new vswing programming for RKL DP. No data is provided for HDMI or eDP, so for now we'll continue to assume that those are the same as TGL. Bspec: 49291 Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218040535.45492-1-matthew.d.roper@intel.comReviewed-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
-
Lee Shawn C authored
After boot into kernel. Driver configured ddc pin mapping based on predefined table in parse_ddi_port(). Now driver configure rkl ddc pin mapping depends on icp_ddc_pin_map[]. Then this table will give incorrect gmbus port number to cause HDMI can't work. Refer to commit cd0a8952 ("drm/i915/rkl: Add DDC pin mapping"). Create two ddc pin table for rkl TGP and CMP pch. Then HDMI can works properly on rkl. v2: update patch based on latest dinq branch. v3: update ddc table for RKL+TGP sku. RKL+CNP sku will load cnp_ddc_pin_map[] setting. v4: modify the if/else judgment to avoid nesting. v5: fix typo in v4. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2577Signed-off-by:
Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117142629.28729-1-shawn.c.lee@intel.com
-
- 05 Jan, 2021 5 commits
-
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-fixes-2020-12-25 - Avoid one useless inline (Jani) - make gvt header self-contained, fix CONFIG_DRM_I915_WERROR (Jani) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201225022009.GF16939@zhen-hp.sh.intel.com
-
José Roberto de Souza authored
It programs Plane's calculated x, y, offset to Plane SF register. It does the calculation of x and y offsets using skl_calc_main_surface_offset(). v3: Update commit message Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Tested-by:
-
José Roberto de Souza authored
The calculation the offsets of the main surface will be needed by PSR2 selective fetch code so here splitting and exporting it. No functional changes were done here. v3: Rebased Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
Now using plane damage clips property to calcualte the damaged area. Selective fetch only supports one region to be fetched so software needs to calculate a bounding box around all damage clips. Now that we are not complete fetching each plane, there is another loop needed as all the plane areas that intersect with the pipe damaged area needs to be fetched from memory so the complete blending of all planes can happen. v2: - do not shifting new_plane_state->uapi.dst only src is in 16.16 format v4: - setting plane selective fetch area using the whole pipe damage area - mark the whole plane area damaged if plane visibility or alpha changed v5: - taking in consideration src.y1 in the damage coordinates - adding to the pipe damaged area planes that were visible but are invisible in the new state v6: - consider old state plane coordinates when visibility changes or it moved to calculate damaged area - remove from damaged area the portion not in src clip v7: - intersec every damage clip with src to minimize damaged area v8: - adjust pipe_damaged area to 4 lines grouping - adjust calculation now that is understood that uapi.src is the framebuffer coordinates that plane will start to fetch from v9: - Only add plane dst or src to damaged_area if visible - Early skip plane damage calculation if it was not visible in old and new state Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Much more clear to read one function call than four lines doing this conversion. v7: - function renamed - calculating width and height before truncate - inlined v10: - renamed parameters from source and destination to src and dst to match sister functions Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
- 30 Dec, 2020 1 commit
-
-
Chris Wilson authored
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a single global pm_qos does not suffice. (One connector may disable the dma-latency boost prematurely while the second is still depending on it.) Instead of a single global pm_qos, track the pm_qos request for each intel_dp. v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini Fixes: 9ee32fea ("drm/i915: irq-drive the dp aux communication") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201230202309.23982-1-chris@chris-wilson.co.uk
-
- 23 Dec, 2020 5 commits
-
-
Lyude Paul authored
No functional changes yet, this just adds definitions for all of the known DPCD registers used by Intel's HDR backlight interface. Since we'll only ever use this in i915, we just define them in intel_dp_aux_backlight.c Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-7-lyude@redhat.com
-
Lyude Paul authored
Since we're about to add support for a second type of backlight control interface over DP AUX (specifically, Intel's proprietary HDR backlight controls) let's rename all of the current backlight hooks we have for vesa to make it clear that they're specific to the VESA interface and not Intel's. v3: * Rebase Signed-off-by:
-
Lyude Paul authored
Instead of using intel_panel->backlight.level, have the caller provide us with the current panel backlight value. We'll need this for when we separate PWM-related backlight callbacks from other means of backlight control (like DPCD backlight controls), as the caller of each PWM callback will be responsible for converting the current brightness value to it's respective PWM level. Signed-off-by:
-
Lyude Paul authored
Since we're going to need to add a set of lower-level PWM backlight control hooks to be shared by normal backlight controls and HDR backlight controls in SDR mode, let's add a prefix to the external PWM backlight functions so that the difference between them and the high level PWM-only backlight functions is a bit more obvious. This introduces no functional changes. Signed-off-by:
-
Lyude Paul authored
Since we're about to start adding support for Intel's magic HDR backlight interface over DPCD, we need to ensure we're properly programming this field so that Intel specific sink services are exposed. Otherwise, 0x300-0x3ff will just read zeroes. We also take care not to reprogram the source OUI if it already matches what we expect. This is just to be careful so that we don't accidentally take the panel out of any backlight control modes we found it in. v2: * Add careful parameter to intel_edp_init_source_oui() to avoid re-writing the source OUI if it's already been set during driver initialization Signed-off-by:
-
- 22 Dec, 2020 13 commits
-
-
Dave Airlie authored
Ville suggested this as a good idea, let's move this before moving the crtc code. Signed-off-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
-
Dave Airlie authored
This file is a monster, let's start simple, the cursor plane code seems pretty standalone, and splits out easily enough. Reviewed-by:
-
Dave Airlie authored
There is no need for a comma use here. Reviewed-by:
-
Dave Airlie authored
This will be used for some refactoring in other files, so move it first. Signed-off-by:
-
Dave Airlie authored
This function is going to be used in a later change, so clean it up first before moving it. Reviewed-by:
-
Jani Nikula authored
Add necessary #includes and forward declarations to make the header compile on its own. Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Add necessary #includes and forward declarations to make the header compile on its own. Reviewed-by:
-
Jani Nikula authored
Add necessary #includes and forward declarations to make the header compile on its own. Reviewed-by:
-
Jani Nikula authored
Add necessary #includes and forward declarations to make the header compile on its own. Reviewed-by:
-
Jani Nikula authored
Add necessary #includes and forward declarations to make the header compile on its own. Reviewed-by:
-
Jani Nikula authored
Add necessary #includes and forward declarations to make the header compile on its own. Reviewed-by:
-
Jani Nikula authored
Add necessary #includes and forward declarations to make the header compile on its own. While at it, also remove a useless forward declaration. Reviewed-by:
-
Jani Nikula authored
Remove unused declaration. Reviewed-by:
-
- 15 Dec, 2020 1 commit
-
-
Ville Syrjälä authored
With GEN11_HOTPLUG_CTL_LONG_DETECT(), SHOTPLUG_CTL_DDI_HPD_LONG_DETECT() and ICP_TC_HPD_LONG_DETECT() taking the hpd_pin as their argument we can remove some duplication in the long_detect() switch statements. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
- 11 Dec, 2020 1 commit
-
-
Sean Paul authored
No need to spam syslog/console when we can ignore/fix the flag. Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
- 10 Dec, 2020 6 commits
-
-
Imre Deak authored
For an enabled DSC during HW readout the corresponding power reference is taken along the CRTC power domain references in get_crtc_power_domains(). Remove the incorrect get ref from the DSI encoder hook. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201209153952.3397959-1-imre.deak@intel.com
-
Jani Nikula authored
The VBT fields match the DPCD data, so use the same helper. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Jani Nikula authored
Add a helper for calculating the rc buffer size from the DCPD offsets DP_DSC_RC_BUF_BLK_SIZE and DP_DSC_RC_BUF_SIZE. Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Move the initialization of the rc_model_size from the common code into encoder code, allowing different encoders to specify the size according to their needs. Keep using the hard coded value in the encoders for now to make this a non-functional change. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Jani Nikula authored
The rc_model_size is specified in the DSC config, and the hardware programming should respect that instead of hard coding a value of 8192. Regardless, the rc_model_size in DSC config is currently hard coded to the same value, so this should have no impact, other than allowing the use of other sizes as needed. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Jani Nikula authored
The PPS is supposed to reflect the DSC config instead of hard coding the rc_model_size. Make it so. Currently all users of drm_dsc_pps_payload_pack() hard code the size to 8192 also in the DSC config, so this change should have no impact, other than allowing the drivers to use other sizes as needed. Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
- 08 Dec, 2020 2 commits
-
-
Manasi Navare authored
This patch fixes the slice count computation algorithm for calculating the slice count based on Peak pixel rate and the max slice width allowed on the DSC engines. We need to ensure slice count > min slice count req as per DP spec based on peak pixel rate and that it is greater than min slice count based on the max slice width advertised by DPCD. So use max of these two. In the prev patch we were using min of these 2 causing it to violate the max slice width limitation causing a blank screen on 8K@60. Fixes: d9218c8f ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com
-
Manasi Navare authored
The Bspec does not mention polling the FEC Enable Live status bit. That is only there for debug purposes. So remove the polling from driver. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
- 04 Dec, 2020 3 commits
-
-
Chris Wilson authored
Switch off the scanout during driver unregister, so we can shutdown the HW immediately for unbind. v2: Remove the old shutdown from remove, it should now be redundant. Signed-off-by:
-
Ville Syrjälä authored
Let's do the kill_bigjoiner_slave() thing from intel_bigjoiner_add_affected_crtcs() since it's related to what we do there. This cleans up the logic in the compute_config() loop a bit. Signed-off-by:
-
Ville Syrjälä authored
If either of the bigjoiner pipes needs a modeset then we need a modeset on both pipes. Make it so. v2: Split out the kill_bigjoiner_slave() change (Manasi) Add affected connectors/planes Signed-off-by:
-
