- 14 Sep, 2021 5 commits
-
-
Jani Nikula authored
MSO will require segment pixel overlap information from the EDID. Postpone MSO init until after we've read and cached the EDID. Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7a360fca01be0f971337b3635f4e4752922ffebe.1630419362.git.jani.nikula@intel.com
-
Jani Nikula authored
The VESA Organization Vendor-Specific Data Block, defined in VESA DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO) stream count and segment pixel overlap. DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension, describing how DisplayID sections may be embedded in EDID extension blocks. DisplayID v2.0 does not have such a section, perhaps implying that DisplayID v2.0 data should not be included in EDID extensions, but rather in a "pure" DisplayID structure at its own DDC address pair A4h/A5h, as described in VESA E-DDC Standard v1.3 chapter 3. However, in practice, displays out in the field have embedded DisplayID v2.0 data blocks in EDID extensions, including, in particular, some eDP MSO displays, where a pure DisplayID structure is not available at all. Parse the MSO data from the DisplayID data block. Do it as part of drm_add_display_info(), extending it to parse also DisplayID data to avoid requiring extra calls to update the information. v2: Check for VESA OUI (Ville) Reviewed-by:
Maxime Ripard <maxime@cerno.tech> Signed-off-by:
-
Jani Nikula authored
Replace the open coded OUI conversion from three bytes to a 24-bit int, as we'll be adding one more user shortly. No functional changes. Side note: CTA-861 format has the OUI bytes in reverse order. Reviewed-by:
-
Jani Nikula authored
DisplayID v2.0 changes the data block identifiers and product types (now called primary use cases). Reviewed-by:
-
Jani Nikula authored
Make the values easier to read. Also add DisplayID Structure version and revision information (this is different from the spec version). Reviewed-by:
-
- 09 Sep, 2021 5 commits
-
-
Hans de Goede authored
On some Cherry Trail devices, DisplayPort over Type-C is supported through a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this case does the PD/alt-mode negotiation itself, rather then everything being handled in firmware. So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch to DP mode and sets the mux accordingly. In this setup the HPD pin is not connected, so the i915 driver needs to respond to a software event and scan the DP port for changes manually. This commit adds support for this. Together with the recent addition of DP alt-mode support to the Type-C subsystem this makes DP over Type-C work on these devices. Tested-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210817215201.795062-7-hdegoede@redhat.com
-
Heikki Krogerus authored
On Intel platforms we know that the ACPI connector device node order will follow the order the driver (i915) decides. The decision is made using the custom Intel ACPI OpRegion (intel_opregion.c), though the driver does not actually know that the values it sends to ACPI there are used for associating a device node for the connectors, and assigning address for them. In reality that custom Intel ACPI OpRegion actually violates ACPI specification (we supply dynamic information to objects that are defined static, for example _ADR), however, it makes assigning correct connector node for a connector entry straightforward (it's one-on-one mapping). Changes in v2 (Hans de goede): - Take a reference on the fwnode which we assign to the connector, for ACPI nodes this is a no-op but in the future we may see software-fwnodes assigned to connectors which are ref-counted. Signed-off-by:
-
Juston Li authored
On some MST docking stations, rx_info can only be read after RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set otherwise the read will return -EIO. This behavior causes the mst stream type1 capability test to fail to read rx_info and determine if the topology supports type1 and fallback to type0. To fix this, check for type1 capability when we receive rx_info within the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead of an explicit read just for type1 capability checking. This does require moving where we set stream_types to after hdcp2_authenticate_sink() when we get rx_info but this occurs before we do hdcp2_propagate_stream_management_info. Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for that as well. Changes since v5: - rename intel_set_stream_types() to intel_hdcp_prepare_streams() (Anshuman) Changes since v4: - move topology_type1_capable to intel_digital_port and rename it as hdcp_mst_type1_capable (Anshuman) - make a helper function intel_set_stream_types() to set stream types in hdcp2_authenticate_and_encrypt() (Anshuman) - break on failure to set stream types and retry instead of returning - remove no longer used declaration for streams_type1_capable() Changes since v2: - Remove no longer used variables in _intel_hdcp2_enable() Signed-off-by:
Juston Li <juston.li@intel.com> Reviewed-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Tested-by:
Suraj K <suraj.kandpal@intel.com> Signed-off-by:
-
Juston Li authored
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself once to retrieve the DEVICE_COUNT to calculate the size of the ReceiverID list then read a second time as a part of reading ReceiverID list. On some MST docking stations, RxInfo can only be read after the RxStatus READY bit is set otherwise the read will return -EIO. The spec states that the READY bit should be cleared as soon as RxInfo has been read. In this case, the first RxInfo read succeeds but after the READY bit is cleared, the second read fails. Fix it by reading RxInfo once and storing it before reading the rest of RepeaterAuth_Send_ReceiverID_List once we know the size. Modify get_receiver_id_list_size() to read and store RxInfo in the message buffer and also parse DEVICE_COUNT so we know the size of RepeaterAuth_Send_ReceiverID_List. Afterwards, retrieve the rest of the message at the offset for seq_num_V. Changes in v5: - Don't change the offset define for Send_ReceiverID_List When reading, update message offset to account for RxInfo being read Changes in v4: - rebase and edit commit message Changes in v3: - remove comment Changes in v2: - remove unnecessary moving of drm_i915_private from patch 1 Signed-off-by:
-
Juston Li authored
Update cp_irq_count_cached when reading messages rather than when writing a message to make sure the value is up to date and not stale from a previously handled CP_IRQ. AKE flow doesn't always respond to a read with a ACK write msg. E.g. AKE_Send_Pairing_Info will "timeout" because we received a CP_IRQ for reading AKE_Send_H_Prime but no write occurred between that and reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale causing the wait to return right away rather than waiting for a new CP_IRQ. Signed-off-by:
-
- 08 Sep, 2021 5 commits
-
-
Lee Shawn C authored
Driver has to swap the endian before send brightness level value to tcon. v2: Use __be16 instead of u16 to fix sparse warning. v3: Send one or two bytes brightness value depend on the precision. v4: get data length of brightness value more easily. Reported-by:
kernel test robot <lkp@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by:
Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-6-shawn.c.lee@intel.com
-
Lee Shawn C authored
So far, DCS backlight driver hardcode (0xFF) for max brightness level. MIPI DCS spec allow max 0xFFFF for set_display_brightness (51h) command. And VBT brightness precision bits can support 8 ~ 16 bits. We should set correct precision bits in VBT that meet panel's request. Driver can refer to this setting then configure max brightness level in DCS backlight driver properly. v2: modify variable name brightness_precision_bits instead of max_brightness_level. v3: fix checkpatch warning. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: -
Lee Shawn C authored
VDSC engine can process only 1 pixel per Cd clock. In case VDSC is used and max slice count == 1, max supported pixel clock should be 100% of CD clock. Then do min_cdclk and pixel clock comparison to get proper min cdclk. v2: - Check for dsc enable and slice count ==1 then allow to double confirm min cdclk value. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by:
-
Lee Shawn C authored
According to chapter "Sending Commands to the Panel" in bspec #29738 and #49188. If driver try to send DCS long pakcet, we have to program TX payload register at first. And configure TX header HW register later. DSC long packet would not be sent properly if we don't follow this sequence. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by:
-
Lee Shawn C authored
Driver should wait for free header or payload buffer in FIFO. It would be good to wait a while for HW to release credit before give it up to write to HW. Without sending initailize command sets completely. It would caused MIPI display can't light up properly. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by:
-
- 07 Sep, 2021 10 commits
-
-
José Roberto de Souza authored
Frontbuffer rendering will be dropped for modern platforms but before that we to prepare DRRS for it. intel_drrs_flush and intel_drrs_invalidate will not be called for platforms that will not support frontbuffer rendering so DRRS needs another way to be notified about to page flips so it can change between high and low refresh rates as needed. Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210903221036.34770-3-jose.souza@intel.com
-
José Roberto de Souza authored
Both functions are pretty much equal, with minor changes that can be handled by a single parameter. v3: - not scheduling work from invalidate operations Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
It started as a code style fix for the lines above 100 col but it turned out to simplifications to intel_drrs_set_state(). Now it receives the desired refresh rate type, high or low. v3: - Fixed the mode refesh rate debug message Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Jani Nikula authored
We can finally remove the extra caching in ddi_port_info. Good riddance. v2: Rebased Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid extra caching of the data. This is slightly more subtle than one would think. For one thing, we explicitly ignore 0 value in child device ddc pin; this is specified as N/A and does not warrant a warning. For another, we start looking for ddc pin collisions in sanitize using unmapped pin numbering. v2: Check !devdata in intel_bios_alternate_ddc_pin() Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Jani Nikula authored
Move code around to avoid a forward declaration in the future. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Jani Nikula authored
Avoid extra caching of the data. v2: Check for !info->devdata in intel_bios_port_aux_ch() (Ankit) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
-
Jani Nikula authored
Avoid extra caching of the data. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Jani Nikula authored
Avoid extra caching of the data. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Jani Nikula authored
Avoid extra caching of the data. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
- 02 Sep, 2021 8 commits
-
-
Animesh Manna authored
Added HBR3 support for ADL_P and ADL_S platform. Bspec: 53597, 53720, 49185, 55409 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Jani Nikula authored
Combo phy is limited to 5.4 GHz on low-voltage SKUs, but both eDP and DP can do 8.1 GHz on combo phy. Bspec: 49182, 49205, 49202 Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Animesh Manna authored
Only higher voltage sku can support HBR3 so a condition check added in max source rate calculation for ehl/jsl. Bspec: 32247, 20598 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Jani Nikula authored
Combo phy is limited to 5.4 GHz on low-voltage SKUs. Combo phy DP is limited to 5.4 GHz, while combo phy eDP can do 8.1 GHz. Bspec: 20584, 20598, 49180, 49201 Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Matt Atwood authored
intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to use before intel_encoder->type is set. This causes incorrect max source rate to be used for display 11+. On EHL and JSL, HBR3 is used instead of HBR2, and on the other affected platforms, HBR2 is used instead of HBR3. Move intel_dp_set_source_rates() to after intel_encoder->type is set. Add comment to intel_dp_is_edp() describing unsafe usages. Cleanup intel_dp_init_connector() while at it. Note: The same change was originally added as commit 680c45c7 ("drm/i915/dp: Correctly advertise HBR3 for GEN11+"), but later reverted due to issues in CI in commit d3913019 ("Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""). Cc: Uma Shankar <uma.shankar@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
Jani Nikula authored
Clean up the LPSP capability printout. No functional changes. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
Clean up the LPSP status printout. No functional changes. Reviewed-by:
-
Jani Nikula authored
Accidentally dropped the else in a rebase fail, causing the DG2 max rate to be overwritten later in the if ladder. Fixes: e752d1f9 ("drm/i915/dg2: add DG2 UHBR source rates") Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
- 01 Sep, 2021 3 commits
-
-
Vandita Kulkarni authored
Enable MIPI DSI support on ADL-P platform. The esc clock changes, WA changes are taken care in the previous patches. As per the Bspec the seq remains to be same as TGL. Signed-off-by:
-
Vandita Kulkarni authored
Wa_16012360555 SW will have to program the "LP to HS Wakeup Guardband" field to account for the repeaters on the HS Request/Ready PPI signaling between the Display engine and the DPHY. v2: Fix build issue. v3: Align to new naming (Jani) Signed-off-by:
-
Vandita Kulkarni authored
Xelpd supports larger small joiner ram. Signed-off-by:
-
- 30 Aug, 2021 4 commits
-
-
José Roberto de Souza authored
We had a mix of intel_edp_drrs_*(), intel_dp_drrs_*() and intel_dp_set_drrs_state(), so properly renaming all functions to keep the same pattern. While at it, also dropping intel_dp_set_drrs_state from the documentation as it is a static function. v3: - dropping documentation style comment in static function (intel_drrs_set_state) Reviewed-by:
-
José Roberto de Souza authored
intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce some lines from it. Reviewed-by:
-
José Roberto de Souza authored
At this point is sure that HSW and BDW will never have PSR enabled by default, so here dropping it from device info and cleaning up code. v2: - enable psr support for display 9 Reviewed-by:
-
Animesh Manna authored
UHBR modes has higher link rate and added new values for programming mpll of SNPS phy. No change in sequence, only the pll parameters are different for UHBR modes. Reviewed-by:
-
