RS780 UVD cause hpet_readl() very slow

Submitted by Christian König on June 17, 2016, 9:31 a.m.

Details

Message ID 4a06a19c-8a27-488c-96b1-9f9288fb4315@email.android.com
State New
Headers show
Series "RS780 UVD cause hpet_readl() very slow" ( rev: 2 ) in DRI devel

Not browsing as part of any series.

Commit Message

Christian König June 17, 2016, 9:31 a.m.
Hi Huacai,

Adding our internal list on CC as well, maybe somebody else has an idea.

I unfortunately don't understand at all how playing something with UVD could delay a simple register read by about 1ms.

And do I get that right that attaching something to the USB controller on the south bridge fixes the issue?

Additional to that the RS780 is already rather old and we don't have any hardware for testing that generation any more.

Sorry no idea of hand,
Christina.

Am 17.06.2016 10:52 schrieb Huacai Chen <chenhuacai@gmail.com>:
Hi, Christian

We found that if we use RS780 UVD decoding, hpet_readl() will need as
long as 1ms.
But, if attach a U-disk on south bridge (SB700) and read some data
from it, hpet_readl() has no problem.
Could you please give me some suggestions or fix it?

How to reproduce:
1, apply the patch on top of kernel (4.2+) and boot with this kernel


2, ensure that no USB device attached on SB700 (except keyboard and mouse)
3, download this file:
http://mirror.lemote.com/fedora-users/ipfootball/video_bench/1920x1080_25fps_h264_ac3.mkv
4, ffmpeg -hwaccel vdpau -i 1920x1080_25fps_h264_acc.mkv  -f rawvideo
-an -y /dev/null
5, dmesg will complain "So big..."

Huacai

Patch hide | download patch | download mbox

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 307a498..a0c8634 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -452,10 +452,12 @@  EXPORT_SYMBOL_GPL(setup_APIC_eilvt);
 /*
  * Program the next event, relative to now
  */
+void check_hpet(void);
 static int lapic_next_event(unsigned long delta,
                            struct clock_event_device *evt)
 {
        apic_write(APIC_TMICT, delta);
+       check_hpet();
        return 0;
 }

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 3acbff4..19329e8 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -367,6 +367,15 @@  static void hpet_set_mode(enum clock_event_mode mode,
        }
 }

+void check_hpet(void)
+{
+       u32 cnt1,cnt2;
+
+       cnt1 = hpet_readl(HPET_COUNTER);
+       cnt2 = hpet_readl(HPET_COUNTER);
+       if(cnt2-cnt1>1000) printk("So big! (%u)\n",cnt2-cnt1);
+}
+
 static int hpet_next_event(unsigned long delta,
                           struct clock_event_device *evt, int timer)
 {

Comments

Yes, USB device can fixes the issue (only attaching a device has no
effect, attching and do data transferring can fix).

Huacai

On Fri, Jun 17, 2016 at 5:31 PM, Koenig, Christian
<Christian.Koenig@amd.com> wrote:
> Hi Huacai,
>
> Adding our internal list on CC as well, maybe somebody else has an idea.
>
> I unfortunately don't understand at all how playing something with UVD could
> delay a simple register read by about 1ms.
>
> And do I get that right that attaching something to the USB controller on
> the south bridge fixes the issue?
>
> Additional to that the RS780 is already rather old and we don't have any
> hardware for testing that generation any more.
>
> Sorry no idea of hand,
> Christina.
>
> Am 17.06.2016 10:52 schrieb Huacai Chen <chenhuacai@gmail.com>:
>
> Hi, Christian
>
> We found that if we use RS780 UVD decoding, hpet_readl() will need as
> long as 1ms.
> But, if attach a U-disk on south bridge (SB700) and read some data
> from it, hpet_readl() has no problem.
> Could you please give me some suggestions or fix it?
>
> How to reproduce:
> 1, apply the patch on top of kernel (4.2+) and boot with this kernel
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 307a498..a0c8634 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -452,10 +452,12 @@ EXPORT_SYMBOL_GPL(setup_APIC_eilvt);
>  /*
>   * Program the next event, relative to now
>   */
> +void check_hpet(void);
>  static int lapic_next_event(unsigned long delta,
>                             struct clock_event_device *evt)
>  {
>         apic_write(APIC_TMICT, delta);
> +       check_hpet();
>         return 0;
>  }
>
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index 3acbff4..19329e8 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -367,6 +367,15 @@ static void hpet_set_mode(enum clock_event_mode mode,
>         }
>  }
>
> +void check_hpet(void)
> +{
> +       u32 cnt1,cnt2;
> +
> +       cnt1 = hpet_readl(HPET_COUNTER);
> +       cnt2 = hpet_readl(HPET_COUNTER);
> +       if(cnt2-cnt1>1000) printk("So big! (%u)\n",cnt2-cnt1);
> +}
> +
>  static int hpet_next_event(unsigned long delta,
>                            struct clock_event_device *evt, int timer)
>  {
>
> 2, ensure that no USB device attached on SB700 (except keyboard and mouse)
> 3, download this file:
> http://mirror.lemote.com/fedora-users/ipfootball/video_bench/1920x1080_25fps_h264_ac3.mkv
> 4, ffmpeg -hwaccel vdpau -i 1920x1080_25fps_h264_acc.mkv  -f rawvideo
> -an -y /dev/null
> 5, dmesg will complain "So big..."
>
> Huacai