J722S SoC has two instances of SERDES namely SERDES0 and SERDES1 and one
instance of PCIe namely PCIe0. Both SERDES0 and SERDES1 are single lane
SERDES. The PCIe0 instance of PCIe is a Gen3 single lane PCIe controller.
Since SERDES and PCIe are not present on AM62P SoC, add the device-tree
nodes corresponding to them in the J722S SoC specific "k3-j722s-main.dtsi"
file.
Co-developed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-7-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The SERDES0 and SERDES1 instances of SERDES on J722S are single lane
SERDES which are individually muxed across different peripherals.
LANE0 of SERDES0 is muxed between USB and CPSW while LANE0 of SERDES1 is
muxed between PCIe and CPSW.
Define the lane-muxing macros to be used as the idle state values.
Co-developed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-6-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Update "k3-j722s.dtsi" to include "k3-am62p-j722s-common-{}".dtsi files in
order to reuse the nodes shared with AM62P. Also include the J722S specific
"k3-j722s-main.dtsi".
Since the J7 family of SoCs has the k3-{soc}.dtsi file organized as:
k3-{soc}.dtsi = CPU + Cache + CBASS-Ranges + "Peripheral-Includes"
switch the "k3-j722s.dtsi" file to the same convention.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-5-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Introduce the "k3-j722s-main.dtsi" file to contain main domain peripherals
that are specific to J722S SoC and are not shared with AM62P. The USB1
instance of the USB controller on J722S is different from that on AM62P.
Thus, add the USB1 node in "k3-j722s-main.dtsi".
Co-developed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-4-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The USB1 instance of USB controller on AM62P is different from the USB1
instance of USB controller on J722S. Thus, move the USB1 instance from
the shared "k3-am62p-j722s-common-main.dtsi" file to the AM62p specific
"k3-am62p-main.dtsi" file. Include "k3-am62p-main.dtsi" in "k3-am62p.dtsi".
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-3-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The AM62P and J722S SoCs share most of the peripherals. With the aim of
reusing the existing k3-am62p-{mcu,main,thermal,wakeup}.dtsi files for
J722S SoC, rename them to indicate that they are shared with the J722S SoC.
The peripherals that are not shared will be moved in the upcoming patches
to the respective k3-{soc}-{mcu,main,wakeup}.dtsi files without "common" in
the filename, emphasizing that they are not shared.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240615081600.3602462-2-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The NAND expansion card plugs in over the HSE (High Speed Expansion)
connector. Add support for it.
We add the ranges property to the GPMC node instead of the NAND
overlay file to prevent below warnings.
/fragment@3/__overlay__: Relying on default #address-cells value
/fragment@3/__overlay__: Relying on default #size-cells value
As GPMC is dedicated for NAND use on this board, it should be OK.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240614-am642-evm-nand-v5-1-acf760896239@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add an overlay to disable the spi nor for all am6xx-phycore-som
boards.
The EEPROM on am6xx-phycore-soms contains information about the
configuration of the SOM. The standard configuration of the SOM
has an ospi nor, but if no nor is populated, the EEPROM will indicate
that change and we can use this overlay to cleanly disable the
spi nor.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240613230759.1984966-5-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add an overlay to disable the rtc for all am6xx-phycore-som boards.
The EEPROM on am6xx-phycore-soms contains information about the
configuration of the SOM. The standard configuration of the SOM
has an rtc, but if no rtc is populated, the EEPROM will indicate that
change and we can use this overlay to cleanly disable the rtc.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240613230759.1984966-4-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add an overlay to disable the eth phy for all am6xx-phycore-som
boards.
The EEPROM on am6xx-phycore-soms contains information about the
configuration of the SOM. The standard configuration of the SOM
has an ethernet phy, but if no ethernet phy is populated, the EEPROM
will indicate that change and we can use this overlay to cleanly
disable the ethernet phy.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240613230759.1984966-3-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Label the spi nor as serial_flash. This allows us to disable the
flash with an overlay common to all am6xx-phycore-som boards.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240613230759.1984966-2-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J721E common processor board can be interfaced with the infotainment
expansion board[0] to enable the following audio/video interfaces in
addition to the peripherals provided by the common processor board:
- Two Audio codecs each with three Stereo Inputs and four Stereo Outputs
- Audio input over FPD Link III
- Digital Audio Interface TX/RX
- HDMI/FPD LINK III Display out
- LI/OV Camera input
Add support for TFP410 HDMI bridge located on the Infotainment Expansion
Board (connected to J46 & J51).
Add a HDMI connector node and connect the endpoints as below:
DSS => TFP410 bridge => HDMI connector
Also add the pinmux data and board muxes for DPI.
Rest of the peripherals are not added as of now.
[0]: <https://www.ti.com/lit/ug/spruit0a/spruit0a.pdf>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[j-choudhary@ti.com: minor cleanup]
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Link: https://lore.kernel.org/r/20240613093706.480700-1-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add an overlay to enable PCIe on the am642-phyboard-electra. The
serdes is muxed from USB to PCIe, so we are restricted to USB2 while
using this overlay.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240613195012.1925920-3-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Remove pinmuxing for PCIe so that we can add it in an overlay.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240613195012.1925920-2-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
PipeDMC has its own fault interrupt. Enable that so that
we can know if things are failing.
While at it, define the other pipeDMC interrupt as well, even
though we're not currently using it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240605111832.21373-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
GEN9_PIPE_PLANE_FLIP_DONE() only works for planes 1-4. Extend
it handle planes 5-7 as well. Somewhat annoyingly the bits are
spread around into two distinct clumps.
Currently this doesn't achieve anything, but if we ever extend
async flip support to more than just the first plane then we'll
need this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240605111832.21373-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
It's really hard to figure out which bdw+ pipe interrupt bits
we've defined and which we have not. Sort the defines to make
that a bit easier (still not super easy since the bits have
been shuffled a bit over the years).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240605111832.21373-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add support to init TA firmware for psp v14.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
refine gfx6 firmware loading
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This attribute is used to hint the length of flexible arrays to
compiler and sanitizers.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The approach of having a separate WB slot for each submission doesn't
really work well and for example breaks GPU reset.
Use a status query packet for the fence update instead since those
should always succeed we can use the fence of the original packet to
signal the state of the operation.
While at it cleanup the coding style.
Fixes: ade887c633 ("drm/amdgpu/mes12: Use a separate fence per transaction")
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
refine gfx10 firmware loading
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
refine gfx9 firmware loading
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The approach of having a separate WB slot for each submission doesn't
really work well and for example breaks GPU reset.
Use a status query packet for the fence update instead since those
should always succeed we can use the fence of the original packet to
signal the state of the operation.
While at it cleanup the coding style.
Fixes: eef016ba89 ("drm/amdgpu/mes11: Use a separate fence per transaction")
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Adds bounds check for sumo_vid_mapping_entry.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Adds bounds check for sumo_vid_mapping_entry.
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to ensure that even when using a reserved VMID that the gang
members can still run in parallel.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
SRIOV does not need to wait for IFWI init, and MP0_C2PMSG_33 is blocked
for VF access.
Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
Reviewed-by: Vignesh Chander <Vignesh.Chander@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
SMU firmware has not supported MALL PG.
[How]
Disable MALL PG and make it always on until SMU firmware is ready.
Signed-off-by: Li Ma <li.ma@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
- Add new condition for PSR exit due to ESD recovery
- Add new VB scaling feature for ABM by interpolating between
existing VB parameters, allowing driver to have fine grain
scaled VB levels between 0 - 250
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Anthony Koo <anthony.koo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The null checks for aconnector and aconnector->dc_link and
stream redundant as they were already dereferenced previously
as reported by Coverity; therefore the null checks are removed.
This fixes 4 REVERSE_INULL issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CalculateSwathAndDETConfiguration_params_st's UnboundedRequestEnabled
is a pointer (i.e. dml_bool_t *UnboundedRequestEnabled), and thus
if (p->UnboundedRequestEnabled) checks its address, not bool value.
This fixes 1 REVERSE_INULL issue reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The null checks for context are redundant as it was already
dereferenced previously, as reported by Coverity; therefore
the null checks are removed.
This fixes 2 REVERSE_INULL issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The null checks for opp are redundant as they were already
dereferenced previously, as reported by Coverity; therefore
the null checks are removed.
This fixes 2 REVERSE_INULL issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The null checks are redundant as they were already dereferenced
previously, as reported by Coverity; therefore the null checks
are removed.
This fixes 7 REVERSE_INULL issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These portions of code are flagged as 'UNUSED_VALUE' by the
Coverity analysis since the assigned values of these vars
are never used in the code.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Ivan Lipski <ivlipski@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The null checks for ctx->dc_bios are redundant as it was already
dereferenced previously, as reported by Coverity; therefore the
null checks are removed.
This fixes 7 REVERSE_INULL issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The null checks for res_pool->dccg are redundant as it was already
dereferenced previously, as reported by Coverity; therefore the
null checks are removed.
This fixes 6 REVERSE_INULL issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If some part of the driver tries to call
resource_get_opp_heads_for_otg_master in a non-OTG master context, DC
will trigger a dmesg warning since this situation indicates that some
configuration associated with ODM slices might be wrong. This commit
adds an extra log to describe why the warning was triggered to make the
debugging more straightforward.
Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When booting the system with DCN401, the driver adds the following dmesg
warning:
WARNING: CPU: 8 PID: 175 at
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1923
resource_get_opp_heads_for_otg_master+0x13/0x70 [amdgpu]
Modules linked in: amdgpu(+) hid_generic amdxcp i2c_algo_bit
drm_ttm_helper ttm drm_exec gpu_sched drm_suballoc_helper drm_buddy
drm_display_helper drm_kms_helper usbhid hid drm i2c_piix4 ahci igc
libahci video wmi
CPU: 8 PID: 175 Comm: systemd-udevd Not tainted 6.8.0-EXTRA-PROMO-MAY-29+ #66
Hardware name: ASUS System Product Name/TUF GAMING X570-PRO (WI-FI),
BIOS 4021 08/10/2021
RIP: 0010:resource_get_opp_heads_for_otg_master+0x13/0x70 [amdgpu]
Code: 8b 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 0f 1f 44 00 00 55 48 83 bf f8 07 00 00 00 48 89 e5 74 0c <0f> 0b 31
f6 89 f0 5d e9 0c 65 01 e5 48 83 bf e0 07 00 00 00 75 ea
RSP: 0018:ffffa5f000816ed8 EFLAGS: 00010246
[...]
PKRU: 55555554
Call Trace:
<TASK>
? show_regs+0x65/0x70
? __warn+0x85/0x160
? resource_get_opp_heads_for_otg_master+0x13/0x70 [amdgpu]
? report_bug+0x192/0x1c0
? handle_bug+0x44/0x90
? exc_invalid_op+0x18/0x70
[...]
This warning is triggered by a check in the function
resource_get_opp_heads_for_otg_master that validates if the request
operation is in a master OTG pipe; if not, the warning above is
displayed. In other words, another part of the code might be calling
this function in a non-OTG master pipe context, resulting in the log
message.
The reason the ASSERT was triggered is that the current state wasn't
updated after applying the context to the hardware. This means that the
update_dsc_for_odm_change might be called from a non-OTG-MASTER. To
prevent this, it's crucial to check if the current reference is pointing
to an OTG master before operate in the old OTG master reference. If it's
not, the function must set the old OTG reference to NULL and avoid
calling resource_get_opp_heads_for_otg_master before the context is
updated.
Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Co-developed-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
