IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
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: Heikki Krogerus <heikki.krogerus@linux.intel.com>
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-6-hdegoede@redhat.com
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: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210819184835.1181323-4-juston.li@intel.com
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 <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: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210819184835.1181323-3-juston.li@intel.com
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: Juston Li <juston.li@intel.com>
Acked-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Suraj K <suraj.kandpal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210819184835.1181323-2-juston.li@intel.com
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: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-6-shawn.c.lee@intel.com
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 <shawn.c.lee@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-5-shawn.c.lee@intel.com
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 <shawn.c.lee@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-4-shawn.c.lee@intel.com
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 <shawn.c.lee@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-3-shawn.c.lee@intel.com
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: Lee Shawn C <shawn.c.lee@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-2-shawn.c.lee@intel.com
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
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 <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210903221036.34770-2-jose.souza@intel.com
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: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210903221036.34770-1-jose.souza@intel.com
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: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e1dbf7cbdd2191439e760ab9098242dcec5fbb2e.1630512523.git.jani.nikula@intel.com
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: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210901160402.24816-6-animesh.manna@intel.com
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: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210901160402.24816-5-animesh.manna@intel.com
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: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210901160402.24816-4-animesh.manna@intel.com
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: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210901160402.24816-3-animesh.manna@intel.com
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 680c45c767f6
("drm/i915/dp: Correctly advertise HBR3 for GEN11+"), but later reverted
due to issues in CI in commit d3913019602e ("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: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210901160402.24816-2-animesh.manna@intel.com
Accidentally dropped the else in a rebase fail, causing the DG2 max rate
to be overwritten later in the if ladder.
Fixes: e752d1f9c14a ("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: Imre Deak <imre.deak@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210901112815.16498-1-jani.nikula@intel.com
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 <vandita.kulkarni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210826054811.10572-3-vandita.kulkarni@intel.com
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 <vandita.kulkarni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210826054811.10572-2-vandita.kulkarni@intel.com
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210827174253.51122-3-jose.souza@intel.com
intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce
some lines from it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210827174253.51122-2-jose.souza@intel.com
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: 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/20210827174253.51122-1-jose.souza@intel.com
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: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210827103843.527-1-jani.nikula@intel.com
Apparently the last reader of i915->active_pipes was removed with commit
ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder"), and
now it's only ever written to. Remove it completely.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210826141830.889-1-jani.nikula@intel.com
The memory latency values returned by pcode on DG2 are in units of "2
usec" rather than 1 usec on all other platforms. I.e., we need to
double the value returned by pcode to obtain the true latency value.
The bspec wording here was a bit ambiguous as to whether it wanted us to
multiply or divide the pcode value by two, but we confirmed offline with
the hardware team that we need to double the value the pcode gives us;
this change is intended to support a larger range of potential latency
values.
Bspec: 49326
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Harish Chegondi <harish.chegondi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210820225710.401136-1-matthew.d.roper@intel.com
