summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/amd/display/dmub/inc
Commit message (Collapse)AuthorAgeFilesLines
* drm/amd/display: Add hardware reset interface for DMUB serviceNicholas Kazlauskas2020-01-221-0/+15
| | | | | | | | | | | | | | [Why] We'll need this to perform a clean shutdown before unloading the driver. [How] It will call reset internally and set hw_init to false. It won't do anything if the hardware isn't initialized. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Get fb base and fb offset for DMUB from registersNicholas Kazlauskas2020-01-221-0/+2
| | | | | | | | | | | | | | | | | | [Why] Under some hardware initialization sequences the fb base/fb offset provided can be zero or hardwareinit can happen too late. We want to ensure that we always have the correct fb_base/fb_offset when performing DMCUB hardware initialization so we can do DMCUB command table offloading during first dc hardware init. [How] Read from the DCN registers. VBIOS already filled these in for us. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Only program surface flip for video plane via dmcubYongqiang Sun2020-01-161-13/+6
| | | | | | | | | | Only need to do surface flip for video plane via dmcub. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Fix DMUB PSR command IDsWyatt Wood2020-01-161-7/+8
| | | | | | | | | | | | | | [Why] The DMUB PSR command IDs do not have the correct values. [How] Fix the command IDs and cleanup the formatting. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Refactor surface flip programmingYongqiang Sun2020-01-161-7/+9
| | | | | | | | | | | Rework surface programming for RN to separate preparing parameters and register programming. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: DMCUB FW Changes to support PSRWyatt Wood2020-01-162-14/+11
| | | | | | | | | | | | | | | [Why] Moving PSR from DMCU to DMCUB. [How] Cleanup psr spec files and add PSR hw programming files. No functionality is included in this change. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: programing surface flip by dmcub.Yongqiang Sun2020-01-162-6/+48
| | | | | | | | | | | Programming surface flip addresses via dmcub uC for optimizing the data flush. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Driverside changes to support PSR in DMCUBWyatt Wood2020-01-161-10/+24
| | | | | | | | | | | | | | | | [Why] Moving PSR from DMCU to DMCUB. [How] Add driverside PSR changes required to send inbox messages to fw. These changes are non-functional until the psr structure allocation is uncommented. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Flush framebuffer data before passing to DMCUBNicholas Kazlauskas2020-01-162-19/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] There's a data race that can occur between when we update the inbox write pointer vs when the memory for the command actually gets flushed from the map to the framebuffer. DMCUB can read stale or partially invalid data when this race occurs. [How] Before updating the write pointer we can read back all pending commands to ensure that we stall for the writes to be flushed to framebuffer. We don't need to worry about choosing HDP vs VM flush with this mechanism. Drop the dmub_srv_cmd_submit() while we're updating this to work correctly since nothing was actually using this API and the caller should be explicit about the API flow here - by doing this on execute we can give some extra time for the flush to finish while preparing other commands. We should try to avoid writing single commands because of this overhead. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Get cache window sizes from DMCUB firmwareNicholas Kazlauskas2019-12-182-38/+29
| | | | | | | | | | | | | | | | | | | | | | | [Why] Firmware state and tracebuffer shouldn't be considered stable API between firmware versions. Driver shouldn't be querying anything from firmware state or tracebuffer outside of debugging. Commands are the stable API for this once we have the outbox. [How] Add metadata struct to the end of the data firmware that describes fw_state_size and some reserved area for future use. Drop the tracebuffer and firmware state headers since they can differ per version. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Get DMUB registers from ASIC specific structsNicholas Kazlauskas2019-12-181-1/+3
| | | | | | | | | | | | | | | | | | [Why] These values can differ per ASIC and should follow the full DC style register programming model. [How] Define a common list and fill in the common list separately for dcn20 and dcn21. Unlike DC we're not using designated initializers for better compiler compatibility since this resides in the DMUB service. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Add shared DMCUB/driver firmware state cache windowNicholas Kazlauskas2019-12-052-2/+79
| | | | | | | | | | | | | | | | | | | | | | | | | [Why] Scratch registers are limited on the DMCUB and we have an expanding list of state to track between driver and DMCUB. [How] Place shared state in cache window 6. The cache window size is aligned to the size of the cache line on the DMCUB to make it easy to invalidate. The shared state is intended to be read only from driver side so it's been marked as const. The use of volatile is intentional. The memory for the shared firmware state is memory mapped from the framebuffer memory. The DMCUB will flush its cache after modifying the region. There's no way for x86 to known whether this data is stale or not so we want to intentionally disable optimization to force the read at every access. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Split DMUB cmd type into type/subtypeNicholas Kazlauskas2019-12-053-30/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Commands will be considered a stable ABI between driver and firmware. Commands are also split between DC commands, DAL feature commands, and VBIOS commands. Commands are currently not designated to a specific ID and the enum does not provide a stable ABI. We currently group all of these into a single command type of 8-bits. With the stable ABI consideration in mind it's not unreasonable to run out of command IDs. For cleaner separation and versioning split the commands into a main type and a subtype. [How] For commands where performance matters (like reg sequences) these are still considered main commands. Sub commands will be split by ownership/feature. Update existing command sequences to reflect new changes. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Add DMCUB__PG_DONE trace code enumYongqiang Sun2019-12-051-0/+1
| | | | | | | Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Add Navi10 DMUB VBIOS codeNicholas Kazlauskas2019-11-191-0/+11
| | | | | | | | | | | | | | | [Why] We need some extra dmub_cmd_type for NV10 [How] Add command table functions in DMUB firmware. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Xiong Yan <Xiong.Yan@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Add debug trace for dmcub FW autoload.Yongqiang Sun2019-11-191-2/+19
| | | | | | | | | | | | | | | | | | | | [Why & How] 1. Add trace code enum for easy debugging. 2. Add trace during uC boot up, including loading phy FW and dmcu FW. 3. Change cache memory type back to write back, since write through has issue when resume from S0i3 100% hang after 3.2ms. 4. Change CW3 base address to hard code value to avoid memory overlap with cw1. 5. Change polling phy init done to infinite loop to avoid dcn hang when dmcub uC stalled. 6. Add dmcub FW dis-assembly file to repositatory for debug purpose. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Add DMUB param to load inst const from driverNicholas Kazlauskas2019-11-191-0/+2
| | | | | | | | | | | | | | | [Why] By default we shouldn't be trying to write secure registers during DMUB hardware init. [How] Add a parameter to control whether we put the DMCUB into secure reset and attempt to load CW0/CW1. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Add DMUB service function check if hw initializedNicholas Kazlauskas2019-11-191-0/+11
| | | | | | | | | | | | | | | | | | | | | [Why] We want to avoid reprogramming the cache window when possible. We don't need to worry about it for S3 but we *do* need to worry about it for S4 resume. DM can check whether hardware should be reinitialized or store software state when going to S4 to know whether we need to reprogram hardware. [How] Add helpers to the DMUB service to check hardware initialization state. DM will hook it up later. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: fix spelling mistake "exeuction" -> "execution"Colin Ian King2019-11-131-1/+1
| | | | | | | | | There are spelling mistakes in a DC_ERROR message and a comment. Fix these. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/amd/display: Add the DMUB serviceNicholas Kazlauskas2019-11-135-0/+1005
The DMUB service is the interface to the DMCUB. It's required to support Renoir features so it will be enabled and compiled automatically when the Renoir display engine is enabled via CONFIG_DRM_AMD_DC_DCN2_1. DMUB code will initially be guarded by CONFIG_DRM_AMD_DC_DMUB and later switched to CONFIG_DRM_AMD_DC_DCN2_1 with the config option dropped. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
OpenPOWER on IntegriCloud