Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Alex Deucher 
On Tue, Mar 21, 2017 at 3:42 AM, Christian König
 wrote:
> Patches #1 - #5, #21, #23, #25, #27, #28, #31, #35-#38, #40, #41, #45 are
> Acked-by: Christian König.
>
> Patches #6-#20, #22, #24, #32, #39, #42 didn't made it to the list (probably
> to large).
>
> Patches #43, #44 are Reviewed-by: Christian König
> .
>
> Patch #26: That stuff actually belongs into vega10 specifc code, doesn't it?

It's common to all soc15 parts for the foreseeable future.

>
> Patch #29: We shouldn't use typedefs for enums.

The existing doorbell assignments use a typedef as well.  Should
probably fix both up.

>
> Going to take a look at the rest later today,
> Christian.
>
>
> Am 20.03.2017 um 21:29 schrieb Alex Deucher:
>>
>> This patch set adds support for vega10.  Major changes and supported
>> features:
>> - new vbios interface
>> - Lots of new hw IPs
>> - Support for video decode using UVD
>> - Support for video encode using VCE
>> - Support for 3D via radeonsi
>> - Power management
>> - Full display support via DC
>> - Support for SR-IOV
>>
>> I did not send out the register headers since they are huge.  You can find
>> them
>> along with all the other patches in this series here:
>> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9
>>
>> Please review.
>>
>> Thanks,
>>
>> Alex
>>
>> Alex Deucher (29):
>>drm/amdgpu: add the new atomfirmware interface header
>>amdgpu: detect if we are using atomfirm or atombios for vbios (v2)
>>drm/amdgpu: move atom scratch setup into amdgpu_atombios.c
>>drm/amdgpu: add basic support for atomfirmware.h (v3)
>>drm/amdgpu: add soc15ip.h
>>drm/amdgpu: add vega10_enum.h
>>drm/amdgpu: Add ATHUB 1.0 register headers
>>drm/amdgpu: Add the DCE 12.0 register headers
>>drm/amdgpu: add the GC 9.0 register headers
>>drm/amdgpu: add the HDP 4.0 register headers
>>drm/amdgpu: add the MMHUB 1.0 register headers
>>drm/amdgpu: add MP 9.0 register headers
>>drm/amdgpu: add NBIF 6.1 register headers
>>drm/amdgpu: add NBIO 6.1 register headers
>>drm/amdgpu: add OSSSYS 4.0 register headers
>>drm/amdgpu: add SDMA 4.0 register headers
>>drm/amdgpu: add SMUIO 9.0 register headers
>>drm/amdgpu: add THM 9.0 register headers
>>drm/amdgpu: add the UVD 7.0 register headers
>>drm/amdgpu: add the VCE 4.0 register headers
>>drm/amdgpu: add gfx9 clearstate header
>>drm/amdgpu: add SDMA 4.0 packet header
>>drm/amdgpu: use atomfirmware interfaces for scratch reg save/restore
>>drm/amdgpu: update IH IV ring entry for soc-15
>>drm/amdgpu: add PTE defines for MTYPE
>>drm/amdgpu: add NGG parameters
>>drm/amdgpu: Add asic family for vega10
>>drm/amdgpu: add tiling flags for GFX9
>>drm/amdgpu: gart fixes for vega10
>>
>> Alex Xie (4):
>>drm/amdgpu: Add MTYPE flags to GPU VM IOCTL interface
>>drm/amdgpu: handle PTE EXEC in amdgpu_vm_bo_split_mapping
>>drm/amdgpu: handle PTE MTYPE in amdgpu_vm_bo_split_mapping
>>drm/amdgpu: Add GMC 9.0 support
>>
>> Andrey Grodzovsky (1):
>>drm/amdgpu: gb_addr_config struct
>>
>> Charlene Liu (1):
>>drm/amd/display: need to handle DCE_Info table ver4.2
>>
>> Christian König (1):
>>drm/amdgpu: add IV trace point
>>
>> Eric Huang (7):
>>drm/amd/powerplay: add smu9 header files for Vega10
>>drm/amd/powerplay: add new Vega10's ppsmc header file
>>drm/amdgpu: add new atomfirmware based helpers for powerplay
>>drm/amd/powerplay: add some new structures for Vega10
>>drm/amd: add structures for display/powerplay interface
>>drm/amd/powerplay: add some display/powerplay interfaces
>>drm/amd/powerplay: add Vega10 powerplay support
>>
>> Felix Kuehling (1):
>>drm/amd: Add MQD structs for GFX V9
>>
>> Harry Wentland (6):
>>drm/amd/display: Add DCE12 bios parser support
>>drm/amd/display: Add DCE12 gpio support
>>drm/amd/display: Add DCE12 i2c/aux support
>>drm/amd/display: Add DCE12 irq support
>>drm/amd/display: Add DCE12 core support
>>drm/amd/display: Enable DCE12 support
>>
>> Huang Rui (6):
>>drm/amdgpu: use new flag to handle different firmware loading method
>>drm/amdgpu: rework common ucode handling for vega10
>>drm/amdgpu: add psp firmware header info
>>drm/amdgpu: add PSP driver for vega10
>>drm/amdgpu: add psp firmware info into info query and debugfs
>>drm/amdgpu: add SMC firmware into global ucode list for psp loading
>>
>> Jordan Lazare (1):
>>drm/amd/display: Less log spam
>>
>> Junwei Zhang (2):
>>drm/amdgpu: add NBIO 6.1 driver
>>drm/amdgpu: add Vega10 Device IDs
>>
>> Ken Wang (8):
>>drm/amdgpu: add common soc15 headers
>>drm/amdgpu: add vega10 chip name
>>drm/amdgpu: add 64bit doorbell assignments
>>drm/amdgpu: add SDMA v4.0 implementation
>>drm/amdgpu: implement GFX 9.0 support
>>drm/amdgpu: add vega10 interrupt handler
>>drm/amdgpu: soc15 enable (v2)
>>

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Andres Rodriguez 



On 2017-03-21 11:14 AM, Deucher, Alexander wrote:

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Christian König
Sent: Tuesday, March 21, 2017 5:01 AM
To: Edward O'Callaghan; StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 000/100] Add Vega10 Support

Am 21.03.2017 um 09:45 schrieb Edward O'Callaghan:


On 03/21/2017 05:36 PM, Christian König wrote:

Am 21.03.2017 um 00:38 schrieb Tom St Denis:

On 03/20/2017 06:34 PM, Jan Ziak wrote:

On Mon, Mar 20, 2017 at 10:41 PM, Alex Deucher

<alexdeuc...@gmail.com

<mailto:alexdeuc...@gmail.com>> wrote:

 On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak

<0xe2.0x9a.0...@gmail.com

 <mailto:0xe2.0x9a.0...@gmail.com>> wrote:
 > Hi
 >
 >


https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/inclu
de/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-
4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2




<https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/incl
ude/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-
4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2>


 >
 > The file nbio_6_1_sh_mask.h is uncompressed. It consists from
133884 lines.
 > Only generated C/C++ code will be able to utilize the content
of such a file
 > efficiently. All hand-written codes combined will be able to
utilize about
 > 1% of the file.
 >
 > Is there a reason why nbio_6_1_sh_mask.h is huge?

 That IP block contains a lot of registers.  The idea is to open
source
 as much IP as possible to facilitate debugging, new features, etc.

 Alex


[This email contains long/wide lines and should be viewed on a
sufficiently wide screen]

For example if I open the file in vim and go to line 66952:

#define


DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9

Then abstracting away some of the digits used in the defined identifier
and using egrep:

$ egrep


"\"


nbio_6_1_sh_mask.h
#define


DWC_E12MP_PHY_X4_NS_X4_0_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_0_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_0_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_0_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_0_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_1_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_1_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_1_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_1_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_2_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_2_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_2_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_2_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_2_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_3_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_3_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_3_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_3_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9
#define


DWC_E12MP_PHY_X4_NS_X4_3_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_1__DTB_SEL__SHIFT


0x9

The egrep command produced 20 lines.

Instead of the many #define directives, it is a possibility to define
functions such as:

int


DWC_E12MP_PHY_Xa_NS_Xb_c_LANEd_DIG_RX_VCOCAL_RX_VCO_CAL_C
TRL_e__DTB_SEL__SHIFT(int


a, int b, int c, int d, int e) __attribute__((pure));

I suppose the file nbio_6_1_sh_mask.h is the output of a tool (it is a
generated file). It is an option to modify the tool to output C
functions with proper input guards instead of #define directives.

The registers are generated by

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Alex Deucher 
On Tue, Mar 21, 2017 at 8:18 AM, Christian König
 wrote:
> In my Spam folder I've found:
>
> Patches #22, #24, #39, #50, #64, #69, #75, #78 which are Acked-by: Christian
> König .
>
> Patches #32, #42 which are Reviewed-by: Christian König
> .
>
> And patches #80, #85, #89, #90, #91, #100 which already had either my rb or
> ackb.
>
> So still missing are #6-#20 which are probably just to large for the list.

As I mentioned below, 6-20 are the register headers which I didn't
send because they are too big.

Alex

>
> Regards,
> Christian.
>
>
> Am 21.03.2017 um 12:51 schrieb Christian König:
>>
>> Patches #48, #49, #52-#63, #65-#68, #70-#72, #74, #76, #77, #79, #81-#84
>> are Acked-by: Christian König .
>>
>> Patches #50, #64, #69, #75, #78, #80, #85, #89-#91, #100 didn't made it to
>> the list.
>>
>> Patch #73 probably needs to be moved to the end of the set or at least
>> after the wptr_poll fix.
>>
>> Apart from those everything should already have my reviewed-by or
>> acked-by.
>>
>> What worries me a bit are the ones who didn't made it to the list. Going
>> to check my spam folder, but that is a bit disturbing.
>>
>> Regards,
>> Christian.
>>
>> Am 21.03.2017 um 08:42 schrieb Christian König:
>>>
>>> Patches #1 - #5, #21, #23, #25, #27, #28, #31, #35-#38, #40, #41, #45 are
>>> Acked-by: Christian König.
>>>
>>> Patches #6-#20, #22, #24, #32, #39, #42 didn't made it to the list
>>> (probably to large).
>>>
>>> Patches #43, #44 are Reviewed-by: Christian König
>>> .
>>>
>>> Patch #26: That stuff actually belongs into vega10 specifc code, doesn't
>>> it?
>>>
>>> Patch #29: We shouldn't use typedefs for enums.
>>>
>>> Going to take a look at the rest later today,
>>> Christian.
>>>
>>> Am 20.03.2017 um 21:29 schrieb Alex Deucher:

 This patch set adds support for vega10. Major changes and supported
 features:
 - new vbios interface
 - Lots of new hw IPs
 - Support for video decode using UVD
 - Support for video encode using VCE
 - Support for 3D via radeonsi
 - Power management
 - Full display support via DC
 - Support for SR-IOV

 I did not send out the register headers since they are huge. You can
 find them
 along with all the other patches in this series here:
 https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9

 Please review.

 Thanks,

 Alex

 Alex Deucher (29):
drm/amdgpu: add the new atomfirmware interface header
amdgpu: detect if we are using atomfirm or atombios for vbios (v2)
drm/amdgpu: move atom scratch setup into amdgpu_atombios.c
drm/amdgpu: add basic support for atomfirmware.h (v3)
drm/amdgpu: add soc15ip.h
drm/amdgpu: add vega10_enum.h
drm/amdgpu: Add ATHUB 1.0 register headers
drm/amdgpu: Add the DCE 12.0 register headers
drm/amdgpu: add the GC 9.0 register headers
drm/amdgpu: add the HDP 4.0 register headers
drm/amdgpu: add the MMHUB 1.0 register headers
drm/amdgpu: add MP 9.0 register headers
drm/amdgpu: add NBIF 6.1 register headers
drm/amdgpu: add NBIO 6.1 register headers
drm/amdgpu: add OSSSYS 4.0 register headers
drm/amdgpu: add SDMA 4.0 register headers
drm/amdgpu: add SMUIO 9.0 register headers
drm/amdgpu: add THM 9.0 register headers
drm/amdgpu: add the UVD 7.0 register headers
drm/amdgpu: add the VCE 4.0 register headers
drm/amdgpu: add gfx9 clearstate header
drm/amdgpu: add SDMA 4.0 packet header
drm/amdgpu: use atomfirmware interfaces for scratch reg save/restore
drm/amdgpu: update IH IV ring entry for soc-15
drm/amdgpu: add PTE defines for MTYPE
drm/amdgpu: add NGG parameters
drm/amdgpu: Add asic family for vega10
drm/amdgpu: add tiling flags for GFX9
drm/amdgpu: gart fixes for vega10

 Alex Xie (4):
drm/amdgpu: Add MTYPE flags to GPU VM IOCTL interface
drm/amdgpu: handle PTE EXEC in amdgpu_vm_bo_split_mapping
drm/amdgpu: handle PTE MTYPE in amdgpu_vm_bo_split_mapping
drm/amdgpu: Add GMC 9.0 support

 Andrey Grodzovsky (1):
drm/amdgpu: gb_addr_config struct

 Charlene Liu (1):
drm/amd/display: need to handle DCE_Info table ver4.2

 Christian König (1):
drm/amdgpu: add IV trace point

 Eric Huang (7):
drm/amd/powerplay: add smu9 header files for Vega10
drm/amd/powerplay: add new Vega10's ppsmc header file
drm/amdgpu: add new atomfirmware based helpers for powerplay
drm/amd/powerplay: add some new structures for Vega10
drm/amd: add structures for display/powerplay interface
drm/amd/powerplay: add some display/powerplay interfaces
drm/amd/powerplay: add Vega10

RE: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Deucher, Alexander 
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Tuesday, March 21, 2017 5:01 AM
> To: Edward O'Callaghan; StDenis, Tom; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 000/100] Add Vega10 Support
> 
> Am 21.03.2017 um 09:45 schrieb Edward O'Callaghan:
> >
> > On 03/21/2017 05:36 PM, Christian König wrote:
> >> Am 21.03.2017 um 00:38 schrieb Tom St Denis:
> >>> On 03/20/2017 06:34 PM, Jan Ziak wrote:
> >>>> On Mon, Mar 20, 2017 at 10:41 PM, Alex Deucher
> <alexdeuc...@gmail.com
> >>>> <mailto:alexdeuc...@gmail.com>> wrote:
> >>>>
> >>>>  On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak
> <0xe2.0x9a.0...@gmail.com
> >>>>  <mailto:0xe2.0x9a.0...@gmail.com>> wrote:
> >>>>  > Hi
> >>>>  >
> >>>>  >
> >>>>
> https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/inclu
> de/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-
> 4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2
> >>>>
> >>>>
> <https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/incl
> ude/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-
> 4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2>
> >>>>
> >>>>  >
> >>>>  > The file nbio_6_1_sh_mask.h is uncompressed. It consists from
> >>>> 133884 lines.
> >>>>  > Only generated C/C++ code will be able to utilize the content
> >>>> of such a file
> >>>>  > efficiently. All hand-written codes combined will be able to
> >>>> utilize about
> >>>>  > 1% of the file.
> >>>>  >
> >>>>  > Is there a reason why nbio_6_1_sh_mask.h is huge?
> >>>>
> >>>>  That IP block contains a lot of registers.  The idea is to open
> >>>> source
> >>>>  as much IP as possible to facilitate debugging, new features, etc.
> >>>>
> >>>>  Alex
> >>>>
> >>>>
> >>>> [This email contains long/wide lines and should be viewed on a
> >>>> sufficiently wide screen]
> >>>>
> >>>> For example if I open the file in vim and go to line 66952:
> >>>>
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>>
> >>>> Then abstracting away some of the digits used in the defined identifier
> >>>> and using egrep:
> >>>>
> >>>> $ egrep
> >>>>
> "\ CTRL_.__DTB_SEL__SHIFT\>"
> >>>>
> >>>> nbio_6_1_sh_mask.h
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_0_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_0_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_0_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_0_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_0_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_1_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>> #define
> >>>>
> DWC_E12MP_PHY_X4_NS_X4_1_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_C
> TRL_1__DTB_SEL__SHIFT
> >>>>
> >>>> 0x9
> >>>> #define
> >&g

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Christian König 

In my Spam folder I've found:

Patches #22, #24, #39, #50, #64, #69, #75, #78 which are Acked-by: 
Christian König .


Patches #32, #42 which are Reviewed-by: Christian König 
.


And patches #80, #85, #89, #90, #91, #100 which already had either my rb 
or ackb.


So still missing are #6-#20 which are probably just to large for the list.

Regards,
Christian.

Am 21.03.2017 um 12:51 schrieb Christian König:
Patches #48, #49, #52-#63, #65-#68, #70-#72, #74, #76, #77, #79, 
#81-#84 are Acked-by: Christian König .


Patches #50, #64, #69, #75, #78, #80, #85, #89-#91, #100 didn't made 
it to the list.


Patch #73 probably needs to be moved to the end of the set or at least 
after the wptr_poll fix.


Apart from those everything should already have my reviewed-by or 
acked-by.


What worries me a bit are the ones who didn't made it to the list. 
Going to check my spam folder, but that is a bit disturbing.


Regards,
Christian.

Am 21.03.2017 um 08:42 schrieb Christian König:
Patches #1 - #5, #21, #23, #25, #27, #28, #31, #35-#38, #40, #41, #45 
are Acked-by: Christian König.


Patches #6-#20, #22, #24, #32, #39, #42 didn't made it to the list 
(probably to large).


Patches #43, #44 are Reviewed-by: Christian König 
.


Patch #26: That stuff actually belongs into vega10 specifc code, 
doesn't it?


Patch #29: We shouldn't use typedefs for enums.

Going to take a look at the rest later today,
Christian.

Am 20.03.2017 um 21:29 schrieb Alex Deucher:

This patch set adds support for vega10. Major changes and supported
features:
- new vbios interface
- Lots of new hw IPs
- Support for video decode using UVD
- Support for video encode using VCE
- Support for 3D via radeonsi
- Power management
- Full display support via DC
- Support for SR-IOV

I did not send out the register headers since they are huge. You can 
find them

along with all the other patches in this series here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9

Please review.

Thanks,

Alex

Alex Deucher (29):
   drm/amdgpu: add the new atomfirmware interface header
   amdgpu: detect if we are using atomfirm or atombios for vbios (v2)
   drm/amdgpu: move atom scratch setup into amdgpu_atombios.c
   drm/amdgpu: add basic support for atomfirmware.h (v3)
   drm/amdgpu: add soc15ip.h
   drm/amdgpu: add vega10_enum.h
   drm/amdgpu: Add ATHUB 1.0 register headers
   drm/amdgpu: Add the DCE 12.0 register headers
   drm/amdgpu: add the GC 9.0 register headers
   drm/amdgpu: add the HDP 4.0 register headers
   drm/amdgpu: add the MMHUB 1.0 register headers
   drm/amdgpu: add MP 9.0 register headers
   drm/amdgpu: add NBIF 6.1 register headers
   drm/amdgpu: add NBIO 6.1 register headers
   drm/amdgpu: add OSSSYS 4.0 register headers
   drm/amdgpu: add SDMA 4.0 register headers
   drm/amdgpu: add SMUIO 9.0 register headers
   drm/amdgpu: add THM 9.0 register headers
   drm/amdgpu: add the UVD 7.0 register headers
   drm/amdgpu: add the VCE 4.0 register headers
   drm/amdgpu: add gfx9 clearstate header
   drm/amdgpu: add SDMA 4.0 packet header
   drm/amdgpu: use atomfirmware interfaces for scratch reg save/restore
   drm/amdgpu: update IH IV ring entry for soc-15
   drm/amdgpu: add PTE defines for MTYPE
   drm/amdgpu: add NGG parameters
   drm/amdgpu: Add asic family for vega10
   drm/amdgpu: add tiling flags for GFX9
   drm/amdgpu: gart fixes for vega10

Alex Xie (4):
   drm/amdgpu: Add MTYPE flags to GPU VM IOCTL interface
   drm/amdgpu: handle PTE EXEC in amdgpu_vm_bo_split_mapping
   drm/amdgpu: handle PTE MTYPE in amdgpu_vm_bo_split_mapping
   drm/amdgpu: Add GMC 9.0 support

Andrey Grodzovsky (1):
   drm/amdgpu: gb_addr_config struct

Charlene Liu (1):
   drm/amd/display: need to handle DCE_Info table ver4.2

Christian König (1):
   drm/amdgpu: add IV trace point

Eric Huang (7):
   drm/amd/powerplay: add smu9 header files for Vega10
   drm/amd/powerplay: add new Vega10's ppsmc header file
   drm/amdgpu: add new atomfirmware based helpers for powerplay
   drm/amd/powerplay: add some new structures for Vega10
   drm/amd: add structures for display/powerplay interface
   drm/amd/powerplay: add some display/powerplay interfaces
   drm/amd/powerplay: add Vega10 powerplay support

Felix Kuehling (1):
   drm/amd: Add MQD structs for GFX V9

Harry Wentland (6):
   drm/amd/display: Add DCE12 bios parser support
   drm/amd/display: Add DCE12 gpio support
   drm/amd/display: Add DCE12 i2c/aux support
   drm/amd/display: Add DCE12 irq support
   drm/amd/display: Add DCE12 core support
   drm/amd/display: Enable DCE12 support

Huang Rui (6):
   drm/amdgpu: use new flag to handle different firmware loading method
   drm/amdgpu: rework common ucode handling for vega10
   drm/amdgpu: add psp firmware header info
   drm/amdgpu: add PSP driver for vega10
   drm/amdgpu: add psp firmware info into info query and debugfs
   drm/amdgpu: add SMC firmware into

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Marek Olšák 
It would be better to keep the headers as-is, because changing them
wouldn't fix anybody's problems, but it would take time from us that we
don't have.

Marek

On Mar 21, 2017 9:46 AM, "Edward O'Callaghan" 
wrote:

>
>
> On 03/21/2017 05:36 PM, Christian König wrote:
> > Am 21.03.2017 um 00:38 schrieb Tom St Denis:
> >> On 03/20/2017 06:34 PM, Jan Ziak wrote:
> >>> On Mon, Mar 20, 2017 at 10:41 PM, Alex Deucher  >>> > wrote:
> >>>
> >>> On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak <
> 0xe2.0x9a.0...@gmail.com
> >>> > wrote:
> >>> > Hi
> >>> >
> >>> >
> >>> https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/
> drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.
> h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2
> >>>
> >>>  gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.
> h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2>
> >>>
> >>> >
> >>> > The file nbio_6_1_sh_mask.h is uncompressed. It consists from
> >>> 133884 lines.
> >>> > Only generated C/C++ code will be able to utilize the content
> >>> of such a file
> >>> > efficiently. All hand-written codes combined will be able to
> >>> utilize about
> >>> > 1% of the file.
> >>> >
> >>> > Is there a reason why nbio_6_1_sh_mask.h is huge?
> >>>
> >>> That IP block contains a lot of registers.  The idea is to open
> >>> source
> >>> as much IP as possible to facilitate debugging, new features, etc.
> >>>
> >>> Alex
> >>>
> >>>
> >>> [This email contains long/wide lines and should be viewed on a
> >>> sufficiently wide screen]
> >>>
> >>> For example if I open the file in vim and go to line 66952:
> >>>
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>> 0x9
> >>>
> >>> Then abstracting away some of the digits used in the defined identifier
> >>> and using egrep:
> >>>
> >>> $ egrep
> >>> "\ CAL_CTRL_.__DTB_SEL__SHIFT\>"
> >>>
> >>> nbio_6_1_sh_mask.h
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_0_LANE0_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_0_LANE1_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_0_LANE2_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_0_LANE3_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_0_LANEX_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_1_LANE0_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_1_LANE2_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_1_LANE3_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_1_LANEX_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_2_LANE0_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_2_LANE1_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_2_LANE2_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_2_LANE3_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_2_LANEX_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_3_LANE0_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_3_LANE1_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_3_LANE2_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_3_LANE3_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>> #define
> >>> DWC_E12MP_PHY_X4_NS_X4_3_LANEX_DIG_RX_VCOCAL_RX_VCO_
> CAL_CTRL_1__DTB_SEL__SHIFT
> >>>
> >>>0x9
> >>>
>

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Christian König 
Patches #48, #49, #52-#63, #65-#68, #70-#72, #74, #76, #77, #79, #81-#84 
are Acked-by: Christian König .


Patches #50, #64, #69, #75, #78, #80, #85, #89-#91, #100 didn't made it 
to the list.


Patch #73 probably needs to be moved to the end of the set or at least 
after the wptr_poll fix.


Apart from those everything should already have my reviewed-by or acked-by.

What worries me a bit are the ones who didn't made it to the list. Going 
to check my spam folder, but that is a bit disturbing.


Regards,
Christian.

Am 21.03.2017 um 08:42 schrieb Christian König:
Patches #1 - #5, #21, #23, #25, #27, #28, #31, #35-#38, #40, #41, #45 
are Acked-by: Christian König.


Patches #6-#20, #22, #24, #32, #39, #42 didn't made it to the list 
(probably to large).


Patches #43, #44 are Reviewed-by: Christian König 
.


Patch #26: That stuff actually belongs into vega10 specifc code, 
doesn't it?


Patch #29: We shouldn't use typedefs for enums.

Going to take a look at the rest later today,
Christian.

Am 20.03.2017 um 21:29 schrieb Alex Deucher:

This patch set adds support for vega10. Major changes and supported
features:
- new vbios interface
- Lots of new hw IPs
- Support for video decode using UVD
- Support for video encode using VCE
- Support for 3D via radeonsi
- Power management
- Full display support via DC
- Support for SR-IOV

I did not send out the register headers since they are huge. You can 
find them

along with all the other patches in this series here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9

Please review.

Thanks,

Alex

Alex Deucher (29):
   drm/amdgpu: add the new atomfirmware interface header
   amdgpu: detect if we are using atomfirm or atombios for vbios (v2)
   drm/amdgpu: move atom scratch setup into amdgpu_atombios.c
   drm/amdgpu: add basic support for atomfirmware.h (v3)
   drm/amdgpu: add soc15ip.h
   drm/amdgpu: add vega10_enum.h
   drm/amdgpu: Add ATHUB 1.0 register headers
   drm/amdgpu: Add the DCE 12.0 register headers
   drm/amdgpu: add the GC 9.0 register headers
   drm/amdgpu: add the HDP 4.0 register headers
   drm/amdgpu: add the MMHUB 1.0 register headers
   drm/amdgpu: add MP 9.0 register headers
   drm/amdgpu: add NBIF 6.1 register headers
   drm/amdgpu: add NBIO 6.1 register headers
   drm/amdgpu: add OSSSYS 4.0 register headers
   drm/amdgpu: add SDMA 4.0 register headers
   drm/amdgpu: add SMUIO 9.0 register headers
   drm/amdgpu: add THM 9.0 register headers
   drm/amdgpu: add the UVD 7.0 register headers
   drm/amdgpu: add the VCE 4.0 register headers
   drm/amdgpu: add gfx9 clearstate header
   drm/amdgpu: add SDMA 4.0 packet header
   drm/amdgpu: use atomfirmware interfaces for scratch reg save/restore
   drm/amdgpu: update IH IV ring entry for soc-15
   drm/amdgpu: add PTE defines for MTYPE
   drm/amdgpu: add NGG parameters
   drm/amdgpu: Add asic family for vega10
   drm/amdgpu: add tiling flags for GFX9
   drm/amdgpu: gart fixes for vega10

Alex Xie (4):
   drm/amdgpu: Add MTYPE flags to GPU VM IOCTL interface
   drm/amdgpu: handle PTE EXEC in amdgpu_vm_bo_split_mapping
   drm/amdgpu: handle PTE MTYPE in amdgpu_vm_bo_split_mapping
   drm/amdgpu: Add GMC 9.0 support

Andrey Grodzovsky (1):
   drm/amdgpu: gb_addr_config struct

Charlene Liu (1):
   drm/amd/display: need to handle DCE_Info table ver4.2

Christian König (1):
   drm/amdgpu: add IV trace point

Eric Huang (7):
   drm/amd/powerplay: add smu9 header files for Vega10
   drm/amd/powerplay: add new Vega10's ppsmc header file
   drm/amdgpu: add new atomfirmware based helpers for powerplay
   drm/amd/powerplay: add some new structures for Vega10
   drm/amd: add structures for display/powerplay interface
   drm/amd/powerplay: add some display/powerplay interfaces
   drm/amd/powerplay: add Vega10 powerplay support

Felix Kuehling (1):
   drm/amd: Add MQD structs for GFX V9

Harry Wentland (6):
   drm/amd/display: Add DCE12 bios parser support
   drm/amd/display: Add DCE12 gpio support
   drm/amd/display: Add DCE12 i2c/aux support
   drm/amd/display: Add DCE12 irq support
   drm/amd/display: Add DCE12 core support
   drm/amd/display: Enable DCE12 support

Huang Rui (6):
   drm/amdgpu: use new flag to handle different firmware loading method
   drm/amdgpu: rework common ucode handling for vega10
   drm/amdgpu: add psp firmware header info
   drm/amdgpu: add PSP driver for vega10
   drm/amdgpu: add psp firmware info into info query and debugfs
   drm/amdgpu: add SMC firmware into global ucode list for psp loading

Jordan Lazare (1):
   drm/amd/display: Less log spam

Junwei Zhang (2):
   drm/amdgpu: add NBIO 6.1 driver
   drm/amdgpu: add Vega10 Device IDs

Ken Wang (8):
   drm/amdgpu: add common soc15 headers
   drm/amdgpu: add vega10 chip name
   drm/amdgpu: add 64bit doorbell assignments
   drm/amdgpu: add SDMA v4.0 implementation
   drm/amdgpu: implement GFX 9.0 support
   drm/amdgpu: add vega10 interrupt handler
   drm/amdgpu: soc15

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Christian König 

Am 21.03.2017 um 09:45 schrieb Edward O'Callaghan:


On 03/21/2017 05:36 PM, Christian König wrote:

Am 21.03.2017 um 00:38 schrieb Tom St Denis:

On 03/20/2017 06:34 PM, Jan Ziak wrote:

On Mon, Mar 20, 2017 at 10:41 PM, Alex Deucher > wrote:

 On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com
 > wrote:
 > Hi
 >
 >
https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2



 >
 > The file nbio_6_1_sh_mask.h is uncompressed. It consists from
133884 lines.
 > Only generated C/C++ code will be able to utilize the content
of such a file
 > efficiently. All hand-written codes combined will be able to
utilize about
 > 1% of the file.
 >
 > Is there a reason why nbio_6_1_sh_mask.h is huge?

 That IP block contains a lot of registers.  The idea is to open
source
 as much IP as possible to facilitate debugging, new features, etc.

 Alex


[This email contains long/wide lines and should be viewed on a
sufficiently wide screen]

For example if I open the file in vim and go to line 66952:

#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9

Then abstracting away some of the digits used in the defined identifier
and using egrep:

$ egrep
"\"

nbio_6_1_sh_mask.h
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9

The egrep command produced 20 lines.

Instead of the many #define directives, it is a possibility to define
functions such as:

int
DWC_E12MP_PHY_Xa_NS_Xb_c_LANEd_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_e__DTB_SEL__SHIFT(int

a, int b, int c, int d, int e) __attribute__((pure));

I suppose the file nbio_6_1_sh_mask.h is the output of a tool (it is a
generated file). It is an option to modify the tool to output C
functions with proper input guards instead of #define directives.

The registers are generated by the HW team and then filtered down to
become what we release publicly.  It is machine generated very likely
from the RTL that specifies the hardware itself.

Yes, exactly that. And it was actually quite some work to get to this
point.


Generally speaking if a class of registers share masks/offsets the
lowest (zero'th) is used in programming and offsets are used when
selecting the correct MMIO address to use specific

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Edward O'Callaghan 


On 03/21/2017 05:36 PM, Christian König wrote:
> Am 21.03.2017 um 00:38 schrieb Tom St Denis:
>> On 03/20/2017 06:34 PM, Jan Ziak wrote:
>>> On Mon, Mar 20, 2017 at 10:41 PM, Alex Deucher >> > wrote:
>>>
>>> On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com
>>> > wrote:
>>> > Hi
>>> >
>>> >
>>> https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2
>>>
>>> 
>>>
>>> >
>>> > The file nbio_6_1_sh_mask.h is uncompressed. It consists from
>>> 133884 lines.
>>> > Only generated C/C++ code will be able to utilize the content
>>> of such a file
>>> > efficiently. All hand-written codes combined will be able to
>>> utilize about
>>> > 1% of the file.
>>> >
>>> > Is there a reason why nbio_6_1_sh_mask.h is huge?
>>>
>>> That IP block contains a lot of registers.  The idea is to open
>>> source
>>> as much IP as possible to facilitate debugging, new features, etc.
>>>
>>> Alex
>>>
>>>
>>> [This email contains long/wide lines and should be viewed on a
>>> sufficiently wide screen]
>>>
>>> For example if I open the file in vim and go to line 66952:
>>>
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>> 0x9
>>>
>>> Then abstracting away some of the digits used in the defined identifier
>>> and using egrep:
>>>
>>> $ egrep
>>> "\"
>>>
>>> nbio_6_1_sh_mask.h
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_0_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_0_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_0_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_0_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_0_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_1_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_1_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_1_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_1_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_2_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_2_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_2_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_2_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_2_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_3_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_3_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_3_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_3_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>> #define
>>> DWC_E12MP_PHY_X4_NS_X4_3_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
>>>
>>>0x9
>>>
>>> The egrep command produced 20 lines.
>>>
>>> Instead of the many #define directives, it is a possibility to define
>>> functions such as:
>>>
>>> int
>>> DWC_E12MP_PHY_Xa_NS_Xb_c_LANEd_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_e__DTB_SEL__SHIFT(int
>>>
>>> a, int b, int c, int d, int e) __attribute__((pure));
>>>
>>> I suppose the file nbio_6_1_sh_mask.h is the output of a tool (it is a
>>> generated file). It is an option to modify the tool to output C
>>> functions with proper input guards instead of #define directives.
>>
>> The

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Christian König 
Patches #1 - #5, #21, #23, #25, #27, #28, #31, #35-#38, #40, #41, #45 
are Acked-by: Christian König.


Patches #6-#20, #22, #24, #32, #39, #42 didn't made it to the list 
(probably to large).


Patches #43, #44 are Reviewed-by: Christian König 
.


Patch #26: That stuff actually belongs into vega10 specifc code, doesn't it?

Patch #29: We shouldn't use typedefs for enums.

Going to take a look at the rest later today,
Christian.

Am 20.03.2017 um 21:29 schrieb Alex Deucher:

This patch set adds support for vega10.  Major changes and supported
features:
- new vbios interface
- Lots of new hw IPs
- Support for video decode using UVD
- Support for video encode using VCE
- Support for 3D via radeonsi
- Power management
- Full display support via DC
- Support for SR-IOV

I did not send out the register headers since they are huge.  You can find them
along with all the other patches in this series here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9

Please review.

Thanks,

Alex

Alex Deucher (29):
   drm/amdgpu: add the new atomfirmware interface header
   amdgpu: detect if we are using atomfirm or atombios for vbios (v2)
   drm/amdgpu: move atom scratch setup into amdgpu_atombios.c
   drm/amdgpu: add basic support for atomfirmware.h (v3)
   drm/amdgpu: add soc15ip.h
   drm/amdgpu: add vega10_enum.h
   drm/amdgpu: Add ATHUB 1.0 register headers
   drm/amdgpu: Add the DCE 12.0 register headers
   drm/amdgpu: add the GC 9.0 register headers
   drm/amdgpu: add the HDP 4.0 register headers
   drm/amdgpu: add the MMHUB 1.0 register headers
   drm/amdgpu: add MP 9.0 register headers
   drm/amdgpu: add NBIF 6.1 register headers
   drm/amdgpu: add NBIO 6.1 register headers
   drm/amdgpu: add OSSSYS 4.0 register headers
   drm/amdgpu: add SDMA 4.0 register headers
   drm/amdgpu: add SMUIO 9.0 register headers
   drm/amdgpu: add THM 9.0 register headers
   drm/amdgpu: add the UVD 7.0 register headers
   drm/amdgpu: add the VCE 4.0 register headers
   drm/amdgpu: add gfx9 clearstate header
   drm/amdgpu: add SDMA 4.0 packet header
   drm/amdgpu: use atomfirmware interfaces for scratch reg save/restore
   drm/amdgpu: update IH IV ring entry for soc-15
   drm/amdgpu: add PTE defines for MTYPE
   drm/amdgpu: add NGG parameters
   drm/amdgpu: Add asic family for vega10
   drm/amdgpu: add tiling flags for GFX9
   drm/amdgpu: gart fixes for vega10

Alex Xie (4):
   drm/amdgpu: Add MTYPE flags to GPU VM IOCTL interface
   drm/amdgpu: handle PTE EXEC in amdgpu_vm_bo_split_mapping
   drm/amdgpu: handle PTE MTYPE in amdgpu_vm_bo_split_mapping
   drm/amdgpu: Add GMC 9.0 support

Andrey Grodzovsky (1):
   drm/amdgpu: gb_addr_config struct

Charlene Liu (1):
   drm/amd/display: need to handle DCE_Info table ver4.2

Christian König (1):
   drm/amdgpu: add IV trace point

Eric Huang (7):
   drm/amd/powerplay: add smu9 header files for Vega10
   drm/amd/powerplay: add new Vega10's ppsmc header file
   drm/amdgpu: add new atomfirmware based helpers for powerplay
   drm/amd/powerplay: add some new structures for Vega10
   drm/amd: add structures for display/powerplay interface
   drm/amd/powerplay: add some display/powerplay interfaces
   drm/amd/powerplay: add Vega10 powerplay support

Felix Kuehling (1):
   drm/amd: Add MQD structs for GFX V9

Harry Wentland (6):
   drm/amd/display: Add DCE12 bios parser support
   drm/amd/display: Add DCE12 gpio support
   drm/amd/display: Add DCE12 i2c/aux support
   drm/amd/display: Add DCE12 irq support
   drm/amd/display: Add DCE12 core support
   drm/amd/display: Enable DCE12 support

Huang Rui (6):
   drm/amdgpu: use new flag to handle different firmware loading method
   drm/amdgpu: rework common ucode handling for vega10
   drm/amdgpu: add psp firmware header info
   drm/amdgpu: add PSP driver for vega10
   drm/amdgpu: add psp firmware info into info query and debugfs
   drm/amdgpu: add SMC firmware into global ucode list for psp loading

Jordan Lazare (1):
   drm/amd/display: Less log spam

Junwei Zhang (2):
   drm/amdgpu: add NBIO 6.1 driver
   drm/amdgpu: add Vega10 Device IDs

Ken Wang (8):
   drm/amdgpu: add common soc15 headers
   drm/amdgpu: add vega10 chip name
   drm/amdgpu: add 64bit doorbell assignments
   drm/amdgpu: add SDMA v4.0 implementation
   drm/amdgpu: implement GFX 9.0 support
   drm/amdgpu: add vega10 interrupt handler
   drm/amdgpu: soc15 enable (v2)
   drm/amdgpu: Set the IP blocks for vega10

Leo Liu (2):
   drm/amdgpu: add initial uvd 7.0 support for vega10
   drm/amdgpu: add initial vce 4.0 support for vega10

Marek Olšák (1):
   drm/amdgpu: don't validate TILE_SPLIT on GFX9

Monk Liu (5):
   drm/amdgpu/gfx9: programing wptr_poll_addr register
   drm/amdgpu:impl gfx9 cond_exec
   drm/amdgpu:bypass RLC init for SRIOV
   drm/amdgpu/sdma4:re-org SDMA initial steps for sriov
   drm/amdgpu/vega10:fix DOORBELL64 scheme

Rex Zhu (2):
   drm/amdgpu: get display info from DC when DC enabled.
   drm/amd/powerplay: add global

Re: [PATCH 000/100] Add Vega10 Support

2017-03-21 Thread Christian König 

Am 21.03.2017 um 00:38 schrieb Tom St Denis:

On 03/20/2017 06:34 PM, Jan Ziak wrote:

On Mon, Mar 20, 2017 at 10:41 PM, Alex Deucher > wrote:

On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com
> wrote:
> Hi
>
> 
https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2


>
> The file nbio_6_1_sh_mask.h is uncompressed. It consists from 
133884 lines.
> Only generated C/C++ code will be able to utilize the content 
of such a file
> efficiently. All hand-written codes combined will be able to 
utilize about

> 1% of the file.
>
> Is there a reason why nbio_6_1_sh_mask.h is huge?

That IP block contains a lot of registers.  The idea is to open 
source

as much IP as possible to facilitate debugging, new features, etc.

Alex


[This email contains long/wide lines and should be viewed on a
sufficiently wide screen]

For example if I open the file in vim and go to line 66952:

#define 
DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT

0x9

Then abstracting away some of the digits used in the defined identifier
and using egrep:

$ egrep
"\" 


nbio_6_1_sh_mask.h
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT 


   0x9

The egrep command produced 20 lines.

Instead of the many #define directives, it is a possibility to define
functions such as:

int
DWC_E12MP_PHY_Xa_NS_Xb_c_LANEd_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_e__DTB_SEL__SHIFT(int 


a, int b, int c, int d, int e) __attribute__((pure));

I suppose the file nbio_6_1_sh_mask.h is the output of a tool (it is a
generated file). It is an option to modify the tool to output C
functions with proper input guards instead of #define directives.


The registers are generated by the HW team and then filtered down to 
become what we release publicly.  It is machine generated very likely 
from the RTL that specifies the hardware itself.


Yes, exactly that. And it was actually quite some work to get to this point.

Generally speaking if a class of registers share masks/offsets the 
lowest (zero'th) is used in programming and offsets are used when 
selecting the correct MMIO address to use specific instances.


The problem is that the files we get from the HW team describe the

Re: [PATCH 000/100] Add Vega10 Support

2017-03-20 Thread Tom St Denis 

On 03/20/2017 06:34 PM, Jan Ziak wrote:

On Mon, Mar 20, 2017 at 10:41 PM, Alex Deucher > wrote:

On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com
> wrote:
> Hi
>
> 
https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2


>
> The file nbio_6_1_sh_mask.h is uncompressed. It consists from 133884 
lines.
> Only generated C/C++ code will be able to utilize the content of such a 
file
> efficiently. All hand-written codes combined will be able to utilize about
> 1% of the file.
>
> Is there a reason why nbio_6_1_sh_mask.h is huge?

That IP block contains a lot of registers.  The idea is to open source
as much IP as possible to facilitate debugging, new features, etc.

Alex


[This email contains long/wide lines and should be viewed on a
sufficiently wide screen]

For example if I open the file in vim and go to line 66952:

#define 
DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
0x9

Then abstracting away some of the digits used in the defined identifier
and using egrep:

$ egrep
"\"
nbio_6_1_sh_mask.h
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9

The egrep command produced 20 lines.

Instead of the many #define directives, it is a possibility to define
functions such as:

int
DWC_E12MP_PHY_Xa_NS_Xb_c_LANEd_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_e__DTB_SEL__SHIFT(int
a, int b, int c, int d, int e) __attribute__((pure));

I suppose the file nbio_6_1_sh_mask.h is the output of a tool (it is a
generated file). It is an option to modify the tool to output C
functions with proper input guards instead of #define directives.


The registers are generated by the HW team and then filtered down to 
become what we release publicly.  It is machine generated very likely 
from the RTL that specifies the hardware itself.


Generally speaking if a class of registers share masks/offsets the 
lowest (zero'th) is used in programming and offsets are used when 
selecting the correct MMIO address to use specific instances.


Having these enumerated though is handy for tools like UMR which would 
decode to the correct instance of the register (you could even see that 
by watching the logscan via umr).  So we make use of them fairly 
efficiently.  UMR reads the headers to create the

Re: [PATCH 000/100] Add Vega10 Support

2017-03-20 Thread Jan Ziak 
On Mon, Mar 20, 2017 at 10:41 PM, Alex Deucher 
wrote:

> On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com>
> wrote:
> > Hi
> >
> > https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/
> drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.
> h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2
> >
> > The file nbio_6_1_sh_mask.h is uncompressed. It consists from 133884
> lines.
> > Only generated C/C++ code will be able to utilize the content of such a
> file
> > efficiently. All hand-written codes combined will be able to utilize
> about
> > 1% of the file.
> >
> > Is there a reason why nbio_6_1_sh_mask.h is huge?
>
> That IP block contains a lot of registers.  The idea is to open source
> as much IP as possible to facilitate debugging, new features, etc.
>
> Alex
>

[This email contains long/wide lines and should be viewed on a sufficiently
wide screen]

For example if I open the file in vim and go to line 66952:

#define 
DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
0x9

Then abstracting away some of the digits used in the defined identifier and
using egrep:

$ egrep
"\"
nbio_6_1_sh_mask.h
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_0_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_1_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_2_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE0_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE1_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE2_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANE3_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9
#define
DWC_E12MP_PHY_X4_NS_X4_3_LANEX_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_1__DTB_SEL__SHIFT
   0x9

The egrep command produced 20 lines.

Instead of the many #define directives, it is a possibility to define
functions such as:

int
DWC_E12MP_PHY_Xa_NS_Xb_c_LANEd_DIG_RX_VCOCAL_RX_VCO_CAL_CTRL_e__DTB_SEL__SHIFT(int
a, int b, int c, int d, int e) __attribute__((pure));

I suppose the file nbio_6_1_sh_mask.h is the output of a tool (it is a
generated file). It is an option to modify the tool to output C functions
with proper input guards instead of #define directives.

Jan
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 000/100] Add Vega10 Support

2017-03-20 Thread Alex Deucher 
On Mon, Mar 20, 2017 at 5:36 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> Hi
>
> https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2
>
> The file nbio_6_1_sh_mask.h is uncompressed. It consists from 133884 lines.
> Only generated C/C++ code will be able to utilize the content of such a file
> efficiently. All hand-written codes combined will be able to utilize about
> 1% of the file.
>
> Is there a reason why nbio_6_1_sh_mask.h is huge?

That IP block contains a lot of registers.  The idea is to open source
as much IP as possible to facilitate debugging, new features, etc.

Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 000/100] Add Vega10 Support

2017-03-20 Thread Jan Ziak 
Hi

https://cgit.freedesktop.org/~agd5f/linux/plain/drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h?h=amd-staging-4.9=9555ef0ba926df25d9a637d0ea21bc0d231c21d2

The file nbio_6_1_sh_mask.h is uncompressed. It consists from 133884 lines.
Only generated C/C++ code will be able to utilize the content of such a
file efficiently. All hand-written codes combined will be able to utilize
about 1% of the file.

Is there a reason why nbio_6_1_sh_mask.h is huge?

Jan
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx