- 01 Apr, 2020 35 commits
-
-
Aric Cyr authored
Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Jiawei authored
extend compute lockup timeout to 60000 for SR-IOV. Reviewed-by:
Emily Deng <Emily.Deng@amd.com> Signed-off-by:
Jiawei <Jiawei.Gu@amd.com> Signed-off-by:
-
Emily Deng authored
As no need to support vcn decode feature, so disable the ring for SR-IOV. Signed-off-by:
Monk Liu <monk.liu@amd.com> Signed-off-by:
-
Monk Liu authored
if host support new handshake we only need to enter fullaccess_mode in ip_init() part, otherwise we need to do it before reading vbios (becuase host prepares vbios for VF only after received REQ_GPU_INIT event under legacy handshake) Signed-off-by:
-
Monk Liu authored
what: 1)move timtout setting before ip_early_init to reduce exclusive mode cost for SRIOV 2)move ip_discovery_init() to inside of amdgpu_discovery_reg_base_init() it is a prepare for the later upcoming patches. why: in later upcoming patches we would use a new mailbox event -- "req_gpu_init_data", which is a callback hooked in adev->virt.ops and this callback send a new event "REQ_GPU_INIT_DAT" to host to notify host to do some preparation like "IP discovery/vbios on the VF FB" and this callback must be: A) invoked after set_ip_block() because virt.ops is configured during set_ip_block() B) invoked before ip_discovery_init() becausen ip_discovery_init() need host side prepares everything in VF FB first. current place of ip_discovery_init() is before we can invoke callback of adev->virt.ops, thus we must move ip_discovery_init() to a place after the adev->virt.ops all settle done, and the perfect place is in amdgpu_discovery_reg_base_init() Signed-off-by:
-
Monk Liu authored
by this new handshake host side can prepare vbios/ip-discovery and pf&vf exchange data upon recieving this request without stopping world switch. this way the world switch is less impacted by VF's exclusive mode request Signed-off-by:
-
Monk Liu authored
what: with the new "req_init_data" handshake we need to use mailbox before do IP discovery, so in mxgpu_nv.c file the original SOC15_REG method won'twork because that depends on IP discovery complete first. how: so the solution is to always use static MMIO offset for NV+ mailbox registers. HW team confirm us all MAILBOX registers will be at the same offset for all ASICs, no IP discovery needed for those registers Signed-off-by:
-
Monk Liu authored
1) modify xgpu_nv_send_access_requests to support new idh request 2) introduce new function: req_gpu_init_data() which is used to notify host to prepare vbios/ip-discovery/pfvf exchange Signed-off-by:
-
Monk Liu authored
new idh_request and ihd_event to prepare for the new handshake protocol implementation later Signed-off-by:
-
Monk Liu authored
1) drop the headers from AI in mxgpu_nv.c, should refer to mxgpu_nv.h 2) the IDH_EVENT_MAX is not used and not aligned with host side so drop it 3) the IDH_TEXT_MESSAG was provided in host but not defined in guest Signed-off-by:
-
Tom St Denis authored
The PWR block was merged into the SMUIO block by revision 12 so we add that to the smuio_12_0_0 headers. (v2): Drop nonsensical smuio_10_0_0 header Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
-
Tom St Denis authored
The register is part of the PWR block not the GC block. Move to its own header. Signed-off-by:
-
Tom St Denis authored
This register is needed by umr. Signed-off-by:
-
Chen Zhou authored
The conversion to bool is not needed, remove it. Signed-off-by:
Chen Zhou <chenzhou10@huawei.com> Signed-off-by:
-
Masahiro Yamada authored
This beautifies the build log. [Before] HOSTCC drivers/gpu/drm/radeon/mkregtable MKREGTABLE drivers/gpu/drm/radeon/r100_reg_safe.h MKREGTABLE drivers/gpu/drm/radeon/rn50_reg_safe.h CC [M] drivers/gpu/drm/radeon/r100.o MKREGTABLE drivers/gpu/drm/radeon/r300_reg_safe.h CC [M] drivers/gpu/drm/radeon/r300.o [After] HOSTCC drivers/gpu/drm/radeon/mkregtable MKREG drivers/gpu/drm/radeon/r100_reg_safe.h MKREG drivers/gpu/drm/radeon/rn50_reg_safe.h CC [M] drivers/gpu/drm/radeon/r100.o MKREG drivers/gpu/drm/radeon/r300_reg_safe.h CC [M] drivers/gpu/drm/radeon/r300.o Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Masahiro Yamada authored
This Makefile repeats similar build rules. Use a pattern rule. Signed-off-by:
-
Masahiro Yamada authored
if_changed must have FORCE as a prerequisite, and the targets must be added to 'targets'. Signed-off-by:
-
Masahiro Yamada authored
A header include path without $(srctree)/ is suspicious because it does not work with O= builds. You can build drivers/gpu/drm/radeon/ without this include path. Signed-off-by:
-
Emily Deng authored
As the VCN firmware will not use vf vmr now. And new psp policy won't support set tmr now. For driver compatible issue, ignore the not support error. Signed-off-by:
-
Emily Deng authored
Add 4k resolution for virtual connector. Signed-off-by:
-
Emily Deng authored
The crtc num is determined by virtual_display parameter. Signed-off-by:
-
John Clements authored
added flag to ras context to indicate if ras query functionality is ready Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
John Clements authored
added mechanism to clear xgmi ras status inbetween error queries Reviewed-by:
-
Monk Liu authored
we need to move virt detection much earlier because: 1) HW team confirms us that RCC_IOV_FUNC_IDENTIFIER will always be at DE5 (dw) mmio offset from vega10, this way there is no need to implement detect_hw_virt() routine in each nbio/chip file. for VI SRIOV chip (tonga & fiji), the BIF_IOV_FUNC_IDENTIFIER is at 0x1503 2) we need to acknowledged we are SRIOV VF before we do IP discovery because the IP discovery content will be updated by host everytime after it recieved a new coming "REQ_GPU_INIT_DATA" request from guest (there will be patches for this new handshake soon). Signed-off-by:
-
Monk Liu authored
Signed-off-by:
-
Monk Liu authored
those two headers are not needed for ip discovery Signed-off-by:
-
Kent Russell authored
Ensure that when we memcpy, we don't end up copying more data than the struct supports. For now, this is 16 characters for product number and serial number, and 32 chars for product name Signed-off-by:
Kent Russell <kent.russell@amd.com> Reviewed-by:
-
Kent Russell authored
Reporting the fw_version just returns 0, the actual version is kept as ta_*_ucode_version. This is the same as the feature reported in the amdgpu_firmware_info debugfs file. Signed-off-by:
-
John Clements authored
added asic support checking function to be filled in by supported asic types Reviewed-by:
-
Tom St Denis authored
The registers are needed for umr and not in the headers. I left them in the gfx_v9_0.c since it includes 9.0 and 9.4 headers and including 9.1 headers would result in a lot of duplicate registers clashing. Signed-off-by:
-
Kent Russell authored
Add the amdgpu.rst tie-ins for the unique_id documentation Signed-off-by:
-
Kent Russell authored
Add the amdgpu.rst tie-ins for the pcie accounting documentation Signed-off-by:
-
Kent Russell authored
Add the amdgpu.rst tie-ins for the mem_info documentation Signed-off-by:
-
Kent Russell authored
Allow for reading of information like manufacturer, product number and serial number from the FRU chip. Report the serial number as the new sysfs file serial_number. Note that this only works on server cards, as consumer cards do not feature the FRU chip, which contains this information. v2: Add documentation to amdgpu.rst, add helper functions, rename functions for consistency, fix bad starting offset v3: Remove testing definitions Signed-off-by:Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
-
Jack Zhang authored
Originally, it kfrees the wrong pointer for mem_obj. It would cause memory leak under stress test. Signed-off-by:
Jack Zhang <Jack.Zhang1@amd.com> Acked-by:
Nirmoy Das <nirmoy.das@amd.com> Signed-off-by:
-
- 31 Mar, 2020 5 commits
-
-
Bhawanpreet Lakha authored
[Why] Some displays have an issue where the hdcp chips are initialized after the display has already lit up. This means we can sometimes authentication too early and cause authentication failures. This happens when HDCP is enabled and the display is power cycled. Normally we will authenticate 2 seconds after the display is lit, but some displays need a bit more time. [How] Increase delay to 3 second before we start authentication. Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Bhawanpreet Lakha authored
[Why] -We need to cancel future callbacks/watchdogs events when a callback/watchdog event happens [How] -fix typo in event_callback() -cancel callback, not watchdog -cancel watchdog events in event_watchdog_timer(). Signed-off-by:
-
Bhawanpreet Lakha authored
[Why] When content type property is set to 1. We should enable hdcp2.2 and if we cant then stop. Currently the way it works in DC is that if we fail hdcp2, we will try hdcp1 after. [How] Use link config to force disable hdcp1.4 when type1 is set. Signed-off-by:
-
Evan Quan authored
This is ASIC specific and should be placed in _ppt.c of each ASIC. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Evan Quan authored
This is already done in soc15.c. And this is really ASIC specific and should not be placed here. Signed-off-by:
-
