Am 09.11.2017 um 10:54 schrieb Piotr Redlewski: > On Wed, Nov 08, 2017 at 06:54:18PM -0500, Alex Deucher wrote: >> On Wed, Nov 8, 2017 at 5:38 PM, Piotr Redlewski <predlewski at gmail.com> wrote: >>> Hi, >>> >>> Following series implements UVD support for SI in amdgpu driver. Code is based >>> on CIK's UVD support in amdgpu and SI's UVD support in radeon drivers. To work, >>> it requires tahiti uvd firmware with added header - I've created simple script >>> to produce exactly this, so if anyone is interested it can be found here: >>> https://gist.github.com/anonymous/6d974a970340f7f64b6fcc4f95267e43 >>> >>> Code is based on amd-staging-drm-next branch in Alex's tree. After applying >>> these patches, uvd boots up and seems to work ok. I've tested it with vdpauinfo >>> and mpv. >>> >>> Some comments/issues for the patches: >>> 1. To make uvd work, I had to bring back fb location programming. Using location >>> programmed by vbios, vram location is not available for uvd mc (at least on my >>> machine) due to too wide address. Starting address is 40-bit long for fb, but >>> uvd mc supports only 32-bits (judging by comments in amdgpu code and actual code >>> in radeon driver) >> Something else must be going on. The vram location is irrelevant with >> respect to the limitations of UVD. I think the limitations with UVD >> are more to do with the location of the active buffers relative to >> each other rather than the absolute location of some aperture in the >> GPU's address space. CI has the same limitation as I recall so there >> is probably a bug somewhere. Windows has used the fb location as set >> by the vbios since evergreen, so it definitely should work. >> > If this is the case, then there must be something missing in UVD mc controller > programming. When using vbios, I get following location: > amdgpu 0000:01:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used) > > When UVD bo is created, it starts at address 0xf400243000 and this value is used > for programming UVD mc offsets. Programming is done in the following way: > addr = (adev->uvd.gpu_addr + AMDGPU_UVD_FIRMWARE_OFFSET) >> 3; > WREG32(mmUVD_VCPU_CACHE_OFFSET0, addr); > > Because address of the bo is wider than 32-bit, this won't work. It would be the > same if UVD bo would be created at the beginning of the VRAM. > > Any ideas how to handle this? Are you programming UVD_LMI_EXT40_ADDR? But I'm not sure if we ever handled that correctly in the SI code. Regards, Christian. > >>> 2. I don't know why, but I couldn't get the uvd to boot without setting uvd mc >>> offsets before starting other engines. Because of that I set it in .sw_init >>> function. In my opinion this should be fixed as it generally doesn't follow >>> amdgpu driver architecture (hardware setup during software setup stage) and >>> probably will break suspending and resume (I didn't test it). As I mentioned, >>> I couldn't figure out why this is happening, so I count on help with finding fix >>> for this. >>> 3. I found some redefinitions in include/asic_reg/uvd/uvd_4_0_sh_mask.h. I guess >>> this file is generated, so fix should be made wherever it is generated from. For >>> now I removed offending lines just to silence the compiler warnings. >>> 4. I'm not sure whether I choose the right version for the uvd. Existing code in >>> si.c suggested that it should be 3.1, however I went with the 4.0, because for >>> this version there are available new style headers. >> I think the regs are pretty much the same between 3.x and 4.x so it >> should be fine. > Great. > > Regards, > Piotr >> Alex >> >> >>> Regards, >>> Piotr >>> >>> Piotr Redlewski (7): >>> drm/amdgpu: remove duplicated definitions of some of the SI registers >>> drm/amdgpu/uvd4: fix some register's mask and shift definitions >>> drm/amdgpu/gmc6: don't use vram location programmed by the vbios >>> drm/amdgpu/uvd4: add early init stage functions for uvd 4.0 >>> drm/amdgpu/uvd4: add sw init and fini stages' functions for uvd 4.0 >>> drm/amdgpu/uvd4: add hardware specific functions for uvd 4.0 >>> drm/amdgpu: enable UVD for SI >>> >>> drivers/gpu/drm/amd/amdgpu/Makefile | 3 +- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 6 + >>> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 14 + >>> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 114 ++- >>> drivers/gpu/drm/amd/amdgpu/dce_v6_0.h | 5 + >>> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 7 - >>> drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 40 +- >>> drivers/gpu/drm/amd/amdgpu/si.c | 256 ++++++- >>> drivers/gpu/drm/amd/amdgpu/si_ih.c | 3 + >>> drivers/gpu/drm/amd/amdgpu/sid.h | 52 +- >>> drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c | 810 +++++++++++++++++++++ >>> drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h | 29 + >>> .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h | 2 - >>> 13 files changed, 1273 insertions(+), 68 deletions(-) >>> create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c >>> create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h >>> >>> -- >>> 2.15.0 >>> >>> _______________________________________________ >>> amd-gfx mailing list >>> amd-gfx at lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
