> Am 09.11.2017 um 11:53 schrieb Piotr Redlewski:
> > 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));
>
> Ok, I've checked the firmware in the meantime and found that we never
> released firmware which supports the full 40bit addressing.
>
> That's why this will never work correctly. Going to check if we can get
> updated firmware out of the door.
Hi Christian,
Did you manage to publish the updated firmware? I can't see it in the linux-firmware tree.
Thanks,
Federico
> Regards,
> Christian.
>
> >
> > Regards,
> > Piotr
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
