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 <[email protected]> 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to