linux-toradex.git/drivers/gpu/drm/amd/display/dc/dce100, branch v5.8 Linux kernel for Apalis and Colibri modules drm/amd/display: change from panel to panel cntl 2020-04-22T22:11:48+00:00 Anthony Koo Anthony.Koo@amd.com 2020-04-08T17:31:50+00:00 d4caa72e275c1920d38a9541b2e4dcc167733734 [Why] it doesn't represent panel specifically, it's more like the control logic for the panel [How] change from panel to panel cntl to make it a bit more clear Signed-off-by: Anthony Koo <Anthony.Koo@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> 
[Why]
it doesn't represent panel specifically, it's more like the control
logic for the panel

[How]
change from panel to panel cntl to make it a bit more clear

Signed-off-by: Anthony Koo <Anthony.Koo@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: move panel power seq to new panel struct 2020-04-22T22:11:48+00:00 Anthony Koo Anthony.Koo@amd.com 2020-03-28T05:44:14+00:00 904fb6e0f4e8158e6db1e21c3c97bdc238e537f5 [Why] panel power sequencer is currently just sitting in hwseq but it really it tied to internal panels [How] make a new panel struct to contain power sequencer code Signed-off-by: Anthony Koo <Anthony.Koo@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> 
[Why]
panel power sequencer is currently just sitting in hwseq but it really
it tied to internal panels

[How]
make a new panel struct to contain power sequencer code

Signed-off-by: Anthony Koo <Anthony.Koo@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 separate of private hwss functions 2019-12-05T21:26:46+00:00 Anthony Koo Anthony.Koo@amd.com 2019-11-05T18:17:30+00:00 f42ea55be1114768e36c4e8dff4400ca811309cf [Why] Some function pointers in the hwss function pointer table are meant to be hw sequencer entry points to be called from dc. However some of those function pointers are not meant to be entry points, but instead used as a code reuse/inheritance tool called directly by other hwss functions, not by dc. Therefore, we want a more clear separation of which functions we determine to be interface functions vs the functions we use within hwss. [How] DC interface functions will be stored in: struct hw_sequencer_funcs Functions used within HWSS will be stored in: struct hwseq_private_funcs Signed-off-by: Anthony Koo <Anthony.Koo@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> 
[Why]
Some function pointers in the hwss function pointer table are
meant to be hw sequencer entry points to be called from dc.

However some of those function pointers are not meant to
be entry points, but instead used as a code reuse/inheritance
tool called directly by other hwss functions, not by dc.

Therefore, we want a more clear separation of which functions
we determine to be interface functions vs the functions we
use within hwss.

[How]
DC interface functions will be stored in:
    struct hw_sequencer_funcs
Functions used within HWSS will be stored in:
    struct hwseq_private_funcs

Signed-off-by: Anthony Koo <Anthony.Koo@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: cleanup of construct and destruct funcs 2019-11-19T15:12:52+00:00 Anthony Koo Anthony.Koo@amd.com 2019-11-01T01:39:39+00:00 d9e32672a1285d6c5e06bedaabb465441c172aa8 [Why] Too many construct functions which makes searching difficult, especially on some debuggers. [How] Append all construct and destruct functions with dcn number and object type to make each construct function name unique Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Too many construct functions which makes searching
difficult, especially on some debuggers.

[How]
Append all construct and destruct functions with dcn
number and object type to make each construct function
name unique

Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: map TRANSMITTER_UNIPHY_x to LINK_REGS_x 2019-10-25T20:50:09+00:00 Yogesh Mohan Marimuthu yogesh.mohanmarimuthu@amd.com 2019-10-02T07:06:33+00:00 bf7f5ac3167a75f60c2f27f16613a6ab90e55908 [Why] The enum value for TRANSMITTER_UNIPHY_G is 9. In resource dc_xx_resource file structure link_enc_regs[], the TRANSMITTER_UNIPHY_G registers are initialized at index 6. Due to this mismatch, if monitor is attached to port using TRANSMITTER_UNIPHY_G then the monitor blanks out. [How] add function map_transmitter_id_to_phy_instance() and use the function to map enum transmitter to link regs. Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com> Reviewed-by: Eric Yang <eric.yang2@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
The enum value for TRANSMITTER_UNIPHY_G is 9. In resource dc_xx_resource
file structure link_enc_regs[], the TRANSMITTER_UNIPHY_G registers are
initialized at index 6. Due to this mismatch, if monitor is attached to
port using TRANSMITTER_UNIPHY_G then the monitor blanks out.

[How]
add function map_transmitter_id_to_phy_instance() and use the function
to map enum transmitter to link regs.

Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Eric Yang <eric.yang2@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: configurable aux timeout support 2019-10-17T20:24:56+00:00 abdoulaye berthe abdoulaye.berthe@amd.com 2019-07-18T19:58:25+00:00 f6040a439f9b6d9f90b7d4ef56762f412dfd1f9d [Description] 1-add configurable timeout support to aux engine. 2-add timeout support field to dc_caps 3-add reg_key to override extended timeout support Signed-off-by: abdoulaye berthe <abdoulaye.berthe@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Description]
1-add configurable timeout support to aux engine.
2-add timeout support field to dc_caps
3-add reg_key to override extended timeout support

Signed-off-by: abdoulaye berthe <abdoulaye.berthe@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Roman Li <Roman.Li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: update register field access mechanism 2019-10-17T20:24:34+00:00 abdoulaye berthe abdoulaye.berthe@amd.com 2019-08-13T13:24:10+00:00 8276dd871fd4240037cffb3904eda2dfe028fd85 1-add timeout length and multiplier fields to aux_control1 register 2-update access mechanism from macro constructed name to uint32_t defined addresses. 3-define registers and field per asic family Signed-off-by: abdoulaye berthe <abdoulaye.berthe@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
1-add timeout length and multiplier fields to aux_control1 register
2-update access mechanism from macro constructed name to uint32_t
defined addresses.
3-define registers and field per asic family

Signed-off-by: abdoulaye berthe <abdoulaye.berthe@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Roman Li <Roman.Li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: memory leak 2019-10-03T14:11:06+00:00 Navid Emamdoost navid.emamdoost@gmail.com 2019-09-17T03:20:44+00:00 cabe144bfd0c106c2e55d900320c2464c42ab94c In dcn*_clock_source_create when dcn20_clk_src_construct fails allocated clk_src needs release. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
In dcn*_clock_source_create when dcn20_clk_src_construct fails allocated
clk_src needs release.

Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: prevent memory leak 2019-10-03T14:11:03+00:00 Navid Emamdoost navid.emamdoost@gmail.com 2019-09-25T04:23:56+00:00 e7883ab63213e3eea001af522ca5f4fc91075572 In dcn*_create_resource_pool the allocated memory should be released if construct pool fails. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
In dcn*_create_resource_pool the allocated memory should be released if
construct pool fails.

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: make firmware info only load once during dc_bios create 2019-08-15T15:53:36+00:00 Dmytro Laktyushkin Dmytro.Laktyushkin@amd.com 2019-07-12T19:06:06+00:00 9adc8050bf3ca3e49c65e13259a4c310640542f1 Currently every time DC wants to access firmware info we make a call into VBIOS. This makes no sense as there is nothing that can change runtime inside fw info and can cause issues when calling unstable bios during bringup. This change eliminate this behavior by only calling bios once for fw info and keeping it stored as part of dc_bios. Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Currently every time DC wants to access firmware info we make a call
into VBIOS. This makes no sense as there is nothing that can change
runtime inside fw info and can cause issues when calling unstable
bios during bringup.

This change eliminate this behavior by only calling bios once for fw
info and keeping it stored as part of dc_bios.

Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Chris Park <Chris.Park@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>