[Intel-gfx] [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.

Wang, Quanxian quanxian.wang at intel.com
Fri May 26 21:36:58 UTC 2017


"The patch is probably fine. But I can't invent an explanation if I don't know what the problem is."

@Jani @libin, is it possible for you to help contact Intel graphics hardware design engineer to get the reason why M/N doesn't work as you implemented in kernel code in Kabylake platform? I don't find good reason in bspec. Thanks.

-----Original Message-----
From: Jani Nikula [mailto:jani.nikula at linux.intel.com] 
Sent: Friday, May 26, 2017 7:01 PM
To: Wang, Quanxian <quanxian.wang at intel.com>; intel-gfx at lists.freedesktop.org
Cc: Yang, Libin <libin.yang at intel.com>
Subject: RE: [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.

On Fri, 26 May 2017, "Wang, Quanxian" <quanxian.wang at intel.com> wrote:
> [Wang, Quanxian] in Ubuntu 17.04, we do audio testing on KBL/SKL/APL 
> and more, the audio doesn't work on KBL specially, and other platform 
> works fine. Even if with latest upstream kernel, but it works on 4.8 
> kernel. Therefore It is a regression issue. After investigation, we 
> found it is caused by commit 
> "6014ac122ed081feca99217bc57b2e15c7fc1a51] drm/i915/audio: set proper 
> N/M in modeset". Therefore I provided this patch.

If it's a regression, we need to backport the fix to stable kernels, and the patch needs annotation:

Fixes: 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset")
Cc: <stable at vger.kernel.org> # v4.10+

> After getting suggestion from you and Libin, we do more testing on 4K 
> monitor for audio delay issue. Also talked with Libin why not use 
> transcoder disable/enable process described in bspec, it will affect 
> performance.
>
> This is the whole story. You can check LCK number 3791 in Intel JIRA 
> about that.

Actually, I can't. And the commit message needs to have the explanation. I still do not know what the bug is specifically, or why Kabylake, and only Kabylake, needs this.

> [Wang, Quanxian] Basically if upstream could provide a reasonable 
> patch, it will appreciate since you are expert in this area.
> Thanks for your understanding.

The patch is probably fine. But I can't invent an explanation if I don't know what the problem is.


BR,
Jani.

--
Jani Nikula, Intel Open Source Technology Center


More information about the Intel-gfx mailing list