(In reply to comment #1)
> Hi, I try to using gpu hardware accelerate to play video from mplayer
> (vdpau+uvd)  . The machine architecture is sparc64,video card is radeon
> HD7450,OS version is redhat7,kernel version is 3.10.0, mplayer version is
> 1.1-21,mesa version is 9.2.5-6.

Please attach the output of dmesg (showing at least all radeon driver related initialization), the /var/log/Xorg.0.log file and the output of vdpauinfo.

Can you try newer versions of the kernel and Mesa?

P.S. AFAICT the 7450 is Northern Islands generation (Caicos) based, not Southern Islands based, otherwise I'd be very surprised you even got this far, given bug 82455. :)

Created attachment 106479 [details]
xorg log

Created attachment 106480 [details]
vdpau log

Created attachment 106481 [details]
radeon init log

Created attachment 106482 [details]
error log

(In reply to comment #1)
> (In reply to comment #1)
> > Hi, I try to using gpu hardware accelerate to play video from mplayer
> > (vdpau+uvd)  . The machine architecture is sparc64,video card is radeon
> > HD7450,OS version is redhat7,kernel version is 3.10.0, mplayer version is
> > 1.1-21,mesa version is 9.2.5-6.
> 
> Please attach the output of dmesg (showing at least all radeon driver
> related initialization), the /var/log/Xorg.0.log file and the output of
> vdpauinfo.
> 
> Can you try newer versions of the kernel and Mesa?
> 
> P.S. AFAICT the 7450 is Northern Islands generation (Caicos) based, not
> Southern Islands based, otherwise I'd be very surprised you even got this
> far, given bug 82455. :)

Hi, attachment are the logs of xort,radeon init,vdpauinfo, the output seem to be ok.

I try to trace the code ,found that it execute  radeon_uvd_cs_reloc func to get the start address of the relocs in GPU RAM.
 reloc = p->relocs_ptr[idx/4]     (idx is 0)
 start = reloc->lobj.gpu_offset
and the start address is start:0x182c000, the radeon_uvd_cs_msg func can remap the gpu address to cpu virtual address use radeon_bo_kmap(bo, &ptr)->ttm_bo_ioremap, the return cpu virtual address is  [zd radeon_uvd_cs_msg]  ptr:000000ca1182c000, msg:000000ca1182c000. and this address is the unhandle address, see the error log. 
       I try to change the PAGE_SHIFT to 12(gpu page shift) in the ttm_bo_ioremap(cpu is 8K page size ,gpu is 4K page size) ,but no effects. I think the bo store in gpu ram has the wrong gpu_offset.But I don't know the reason. the only way can effect this is the remap,base the different cpu page size and gpu page size.
       Can give me any idea about this? Or maybe have some ways to  verified? Tks
       By the way, where can download the document about the ttm and gem ? I am puzzled about the principle of gpu memory managerment .

Looks like maybe ttm_bo_ioremap() doesn't work correctly. Which path does it take?

(In reply to comment #7)
> Looks like maybe ttm_bo_ioremap() doesn't work correctly. Which path does it
> take?

which path does it take?  you mean...

but I get the start = reloc->lobj.gpu_offset, start is 0x182c000, this address is gpu address,base address is 0x0. when do ttm_bo_ioremap the cpu virtual address is 0x000000ca1182c000, reference as radeon.log ,the address mapping seems good.
By the way, when I do the ring_ib_test on ring 5, also failed, unhandle request address come out. Next I will do some trace for ring_ib_test,because this not depend on libdrm.only construct msg and send.

I solved that problem by use readl()/writel() func to access cpu virtual address insteand of set address directly. such as use readl(&msg[1]) instead of msg_type=msg[1]. and use the l/b endian transfer. But the new error ocurred (error message) .
    radeon:GPU lockup cp stall for ... more than...
   I try to change the lockup timeout to longer but no use.
   I don't know why??

Created attachment 106571 [details]
error message

The mplayer UI appear,no output.  and then kernel panic

(In reply to comment #9)
>     radeon:GPU lockup cp stall for ... more than...

That means the GPU hangs while processing commands, probably because the commands are malformed in some way (e.g. wrong byte order).

Please attach the exact changes you've made to get to that point.

Created attachment 106731 [details] [review]
solve the problem of unhandle request address

This patch can solve the address problem.

(In reply to comment #13)
> This patch can solve the address problem.

writel() and readl() already convert to/from little endian. Does it work better if you remove cpu_to_le32() from all lines using those functions?


> @@ -751,22 +748,12 @@
>  	}
>  
>  	/* stitch together an UVD destroy msg */
> -#if 0
> -	msg[0] = cpu_to_le32(0x00000de4);
> -	msg[1] = cpu_to_le32(0x00000002);
> -	msg[2] = cpu_to_le32(handle);
> -	msg[3] = cpu_to_le32(0x00000000);
> -	for (i = 4; i < 1024; ++i)
> -		msg[i] = cpu_to_le32(0x0);
> -#endif
> -#if 1
>  	writel(cpu_to_le32(0x00000de4),&msg[1]);
>          writel(cpu_to_le32(0x00000002),&msg[2]);
>          writel(cpu_to_le32(handle),&msg[3]);
>          writel(cpu_to_le32(0x00000000),&msg[4]);
>          for (i = 4; i < 1024; ++i)
>                  writel(cpu_to_le32(0x0),&msg[i]);
> -#endif
>  	radeon_bo_kunmap(bo);
>  	radeon_bo_unreserve(bo);

Why are you enabling this code?

(In reply to comment #14)
> (In reply to comment #13)
> > This patch can solve the address problem.
> 
> writel() and readl() already convert to/from little endian. Does it work
> better if you remove cpu_to_le32() from all lines using those functions?
> 
> 
> > @@ -751,22 +748,12 @@
> >  	}
> >  
> >  	/* stitch together an UVD destroy msg */
> > -#if 0
> > -	msg[0] = cpu_to_le32(0x00000de4);
> > -	msg[1] = cpu_to_le32(0x00000002);
> > -	msg[2] = cpu_to_le32(handle);
> > -	msg[3] = cpu_to_le32(0x00000000);
> > -	for (i = 4; i < 1024; ++i)
> > -		msg[i] = cpu_to_le32(0x0);
> > -#endif
> > -#if 1
> >  	writel(cpu_to_le32(0x00000de4),&msg[1]);
> >          writel(cpu_to_le32(0x00000002),&msg[2]);
> >          writel(cpu_to_le32(handle),&msg[3]);
> >          writel(cpu_to_le32(0x00000000),&msg[4]);
> >          for (i = 4; i < 1024; ++i)
> >                  writel(cpu_to_le32(0x0),&msg[i]);
> > -#endif
> >  	radeon_bo_kunmap(bo);
> >  	radeon_bo_unreserve(bo);
> 
> Why are you enabling this code?

1. I do not add cpu_to_le32() first ,but when I trace the messages from printk,the value of msg_type is reversed. Add, all is ok.
2. #if 0 ...#endif is the original code from kernel. #if 1 ...#endif is changed code. is the same as 1. Must do cpu_to_le32 transfer

  By the way, u said writel() and readl() already convert to/from little endian.
is based on the X86 arch implement?

(In reply to comment #15)
> 1. I do not add cpu_to_le32() first ,but when I trace the messages from
> printk,the value of msg_type is reversed.

That's in radeon_uvd_cs_msg()? Sounds like the Mesa UVD code writes the messages in host byte order, not in little endian. Maybe Christian can clarify which byte order should be used for them.


> 2. #if 0 ...#endif is the original code from kernel. #if 1 ...#endif is
> changed code.

Ah right, never mind, I misread that hunk before.


> By the way, u said writel() and readl() already convert to/from little
> endian. is based on the X86 arch implement?

It's the same on all architectures: writel() takes a datum in host byte order and writes it in little endian. readl() reads a little endian datum and returns it in host byte order. (This means that on little endian hosts such as x86, the datum is transferred unchanged)

(In reply to comment #16)
> (In reply to comment #15)
> > 1. I do not add cpu_to_le32() first ,but when I trace the messages from
> > printk,the value of msg_type is reversed.
> 
> That's in radeon_uvd_cs_msg()? Sounds like the Mesa UVD code writes the
> messages in host byte order, not in little endian. Maybe Christian can
> clarify which byte order should be used for them.

The hardware supports byte swapping for the message and feedback buffer, but I think always writing/reading it in little endian will be simpler to get working.

The userspace code currently doesn't supports big endian hosts and so will probably write it in the wrong byte order.

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > 1. I do not add cpu_to_le32() first ,but when I trace the messages from
> > > printk,the value of msg_type is reversed.
> > 
> > That's in radeon_uvd_cs_msg()? Sounds like the Mesa UVD code writes the
> > messages in host byte order, not in little endian. Maybe Christian can
> > clarify which byte order should be used for them.
> 
> The hardware supports byte swapping for the message and feedback buffer, but
> I think always writing/reading it in little endian will be simpler to get
> working.
> 
> The userspace code currently doesn't supports big endian hosts and so will
> probably write it in the wrong byte order.

I think you are right. The patch I give it it's not the original point.So I have some work to do on userspace, such as mesa. A huge project!
By the way, which version of mesa add big endian support.or you have some plans to do it.

(In reply to comment #18)
> 
> So I have some work to do on userspace, such as mesa. A huge project!

Actually, I don't think the relevant code for UVD support is that big.


> By the way, which version of mesa add big endian support.or you have some
> plans to do it.

As Christian said, the UVD code currently currently doesn't handle big endian hosts properly yet. I don't know of any plans to fix that either, so don't wait for us to do it. :)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/526.