On Thu, Nov 09, 2017 at 11:09:42AM +0100, Christian König wrote: > 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. Yes, I do it exactly the same as it is done in radeon (and CIK in amdgpu): /* bits 32-39 */ addr = (adev->uvd.gpu_addr >> 32) & 0xFF; WREG32(mmUVD_LMI_EXT40_ADDR, addr | (0x9 << 16) | (0x1 << 31)); Regards, Piotr > > 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 > > > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
