Re: [Intel-gfx] [PATCH v5 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

[kbuild test robot]

Hi Puthikorn,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20170504]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Puthikorn-Voravootivat/Enhancement-to-intel_dp_aux_backlight-driver/20170505-003007
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from include/linux/module.h:18:0,
from include/drm/drmP.h:59,
from drivers/gpu/drm/i915/i915_drv.h:47,
from drivers/gpu/drm/i915/i915_params.c:26:
   drivers/gpu/drm/i915/i915_params.c: In function 
'__check_enable_dpcd_backlight':
>> include/linux/moduleparam.h:146:27: error: return from incompatible pointer 
>> type [-Werror=incompatible-pointer-types]
 param_check_##type(name, &(value));   \
  ^
   include/linux/moduleparam.h:344:68: note: in definition of macro 
'__param_check'
 static inline type __always_unused *__check_##name(void) { return(p); }
   ^
   include/linux/moduleparam.h:146:2: note: in expansion of macro 
'param_check_bool'
 param_check_##type(name, &(value));   \
 ^~~~
   drivers/gpu/drm/i915/i915_params.c:249:1: note: in expansion of macro 
'module_param_named'
module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
^~
   cc1: some warnings being treated as errors
--
   In file included from include/linux/module.h:18:0,
from include/drm/drmP.h:59,
from drivers/gpu//drm/i915/i915_drv.h:47,
from drivers/gpu//drm/i915/i915_params.c:26:
   drivers/gpu//drm/i915/i915_params.c: In function 
'__check_enable_dpcd_backlight':
>> include/linux/moduleparam.h:146:27: error: return from incompatible pointer 
>> type [-Werror=incompatible-pointer-types]
 param_check_##type(name, &(value));   \
  ^
   include/linux/moduleparam.h:344:68: note: in definition of macro 
'__param_check'
 static inline type __always_unused *__check_##name(void) { return(p); }
   ^
   include/linux/moduleparam.h:146:2: note: in expansion of macro 
'param_check_bool'
 param_check_##type(name, &(value));   \
 ^~~~
   drivers/gpu//drm/i915/i915_params.c:249:1: note: in expansion of macro 
'module_param_named'
module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
^~
   cc1: some warnings being treated as errors

vim +146 include/linux/moduleparam.h

3baee201 Jani Nikula   2014-08-27  130   */
3baee201 Jani Nikula   2014-08-27  131  #define module_param_unsafe(name, type, 
perm)   \
3baee201 Jani Nikula   2014-08-27  132  module_param_named_unsafe(name, 
name, type, perm)
3baee201 Jani Nikula   2014-08-27  133  
3baee201 Jani Nikula   2014-08-27  134  /**
546970bc Rusty Russell 2010-08-11  135   * module_param_named - typesafe helper 
for a renamed module/cmdline parameter
546970bc Rusty Russell 2010-08-11  136   * @name: a valid C identifier which is 
the parameter name.
546970bc Rusty Russell 2010-08-11  137   * @value: the actual lvalue to alter.
546970bc Rusty Russell 2010-08-11  138   * @type: the type of the parameter
546970bc Rusty Russell 2010-08-11  139   * @perm: visibility in sysfs.
546970bc Rusty Russell 2010-08-11  140   *
546970bc Rusty Russell 2010-08-11  141   * Usually it's a good idea to have 
variable names and user-exposed names the
546970bc Rusty Russell 2010-08-11  142   * same, but that's harder if the 
variable must be non-static or is inside a
546970bc Rusty Russell 2010-08-11  143   * structure.  This allows exposure 
under a different name.
546970bc Rusty Russell 2010-08-11  144   */
546970bc Rusty Russell 2010-08-11  145  #define module_param_named(name, value, 
type, perm)\
546970bc Rusty Russell 2010-08-11 @146  param_check_##type(name, 
&(value));\
546970bc Rusty Russell 2010-08-11  147  module_param_cb(name, 
_ops_##type, , perm);\
546970bc Rusty Russell 2010-08-11  148  __MODULE_PARM_TYPE(name, #type)
546970bc Rusty Russell 2010-08-11  149  
546970bc Rusty Russell 2010-08-11  150  /**
3baee201 Jani Nikula   2014-08-27  151   * module_param_named_unsafe - same as 
module_param_named but taints kernel
3baee201 Jani Nikula   2014-08-27  152   */
3baee201 Jani Nikula   2014-08-27  153  #define 

Re: [Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Dong, Chuanxiao]

> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Friday, May 5, 2017 4:55 PM
> To: Zhenyu Wang ; Dong, Chuanxiao
> ; Daniel Vetter 
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC
> submission is enabled
> 
> + Daniel
> 
> On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote:
> > On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote:
> > >
> > > Currently GVT-g cannot work properly when host GuC submission is
> > > enabled, so disable GVT in this case.
> > >
> > > Cc: Zhenyu Wang 
> > > Signed-off-by: Chuanxiao Dong 
> 
> 
> 
> > > @@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private
> *dev_priv)
> > >   goto bail;
> > >   }
> > >
> > > + if (i915.enable_guc_submission) {
> > > + DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to
> > > +enabled GuC submission [i915.enable_guc_submission module
> > > +parameter]\n");
> 
> Guest module parameter is not the correct way of detetecting if host has
> GuC submission enabled. And even if it was, the message is overly verbose
> (and it'll be incorrect once i915.enable_guc_submission defaults to
> something else than zero).

Hi Joonas,

How about just to say " DRM_INFO("GPU guest virtualisation [GVT-g] disabled due 
to enabled GuC submission\n");"

Thanks
Chuanxiao

> 
> > > + goto bail;
> > > + }
> > > +
> > >   /*
> > >    * We're not in host or fail to find a MPT module, disable GVT-g
> > >    */
> > > --
> >
> > Applied, thanks!
> 
> The original patch should've included at least some Cc's, or wait being
> merged through drm-tip as it's not int drm/i915/gvt directory at all (unlike
> the message states).
> 
> The patch should be reverted for being incorrect.
> 
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Joonas Lahtinen]

+ Daniel

On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote:
> On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote:
> > 
> > Currently GVT-g cannot work properly when host GuC submission
> > is enabled, so disable GVT in this case.
> > 
> > Cc: Zhenyu Wang 
> > Signed-off-by: Chuanxiao Dong 



> > @@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
> >     goto bail;
> >     }
> >  
> > +   if (i915.enable_guc_submission) {
> > +   DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to 
> > enabled GuC submission [i915.enable_guc_submission module parameter]\n");

Guest module parameter is not the correct way of detetecting if host
has GuC submission enabled. And even if it was, the message is overly
verbose (and it'll be incorrect once i915.enable_guc_submission
defaults to something else than zero).

> > +   goto bail;
> > +   }
> > +
> >     /*
> >      * We're not in host or fail to find a MPT module, disable GVT-g
> >      */
> > -- 
> 
> Applied, thanks!

The original patch should've included at least some Cc's, or wait being
merged through drm-tip as it's not int drm/i915/gvt directory at all
(unlike the message states).

The patch should be reverted for being incorrect.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv4 3/3] drm/vgem: Enable dmabuf import interfaces

[Chris Wilson]

On Thu, May 04, 2017 at 09:09:54PM -0700, Joe Perches wrote:
> On Thu, 2017-05-04 at 21:25 +0100, Chris Wilson wrote:
> > On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
> > > 
> > > Enable the GEM dma-buf import interfaces in addition to the export
> > > interfaces. This lets vgem be used as a test source for other allocators
> > > (e.g. Ion).
> > > 
> > > Reviewed-by: Chris Wilson 
> > > Signed-off-by: Laura Abbott 
> > > ---
> > > v4: Use new drm_gem_prime_import_dev function
> > > ---
> > >  static const struct vm_operations_struct vgem_gem_vm_ops = {
> > > @@ -114,12 +142,8 @@ static void vgem_postclose(struct drm_device *dev, 
> > > struct drm_file *file)
> > >   kfree(vfile);
> > >  }
> > >  
> > > -/* ioctls */
> > > -
> > > -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> > > -   struct drm_file *file,
> > > -   unsigned int *handle,
> > > -   unsigned long size)
> > > +static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device 
> > > *dev,
> > > + unsigned long size)
> > 
> > I'm going to guess that doesn't line up anymore. If checkpatch isn't
> > complaining, then sorry for the noise.
> 
> Because of the very long identifiers, perhaps a
> nicer way to write this is like:
> 
> static struct drm_vgem_gem_object *
> __vgen_gem_create(struct drm_device *dev, unsigned long size);

Yes, we frequently use that pattern for very_long_function_names.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use a define for the default priority [0]

[Mika Kuoppala]

Chris Wilson  writes:

> On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:
>> On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:
>> > Explicitly assign the default priority, and give it a name (macro).
>> > 
>> > Signed-off-by: Chris Wilson 
>> 
>> 
>> 
>> >    kref_init(>ref);
>> >    list_add_tail(>link, _priv->context_list);
>> >    ctx->i915 = dev_priv;
>> > +  ctx->priority = I915_PRIORITY_DFL;
>> 
>> I915_PRIORITY_DEFAULT would work better.
>
> On the one hand I have the symmetry with MIN, DFL, MAX, on the other
> hand DFL is plain bizarre.

DEF?

[1]: http://www.abbreviations.com/abbreviation/default

-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] i915 I2C failures with recent chips and docking stations

[Sanford Rockowitz]

I am the author of ddcutil (www.ddcutil.com), a Linux utility that
manages monitor settings using DDC/CI. I am seeing a pattern of user
error reports in which I2C communication is not working when a system
with a recent Intel chip, using the i915 driver, is plugged into a
docking station.  Communication works when the video cable is plugged
directly into the laptop.   There also seems to be a correlation with
whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is
being executed), though this correlation is not as clear.

I'm not sure how best to go about reporting these issues.  The usual bug
reporting mechanism asks for detailed information about a specific
system, which I don't have.   What I do have is the ability to see a
pattern.

Because I2C communication is so fragile (dependencies on hardware
quirks, drivers, etc), ddcutil (which is written in C) has an extensive
subsystem devoted to remotely diagnosing user configurations.  It
already reports DDC (i.e. I2C) communication errors, and has interfaces
to udev, libdrm, and x11 libraries.  If there is some i915 specific code
I could add to refine the diagnosis, I would be happy to add that. 
(Note: ddcutil is entirely a user space program, using the i2c-dev
interface.)

Suggestions on how to proceed appreciated.

Sanford Rockowitz

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

[Christoph Hellwig]

On Fri, May 05, 2017 at 10:06:06AM +0300, Amir Goldstein wrote:
> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems code).

Yeah.

> IMO, you should acknowledge that the common use case for filesystems is
> to handle an opaque char[16] which most likely holds a uuid_be and you
> should provide 'neutral' helpers to satisfy this use case.
> 
> The simplest would be to typedef uuid_t to struct uuid_be and to name 
> 'neutral'
> helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my proposal.

It's not jut neutral, it's the right thing to to.  The Apollo / DCE
uuids (later also specified in RFC 4122) are big endian, so we should
use the name there.

> Christoph also suggested a similar treatment to typedef guid_t to
> struct uuid_le.

Exactly.  The whole idea of "little endian UUIDs" comes from the
Wintel world, and if you look at the relevant specs they are almost
exclusively referred to as GUIDs.

The magic XFS and AFS types for specific interpretations of one of
the RFC4122 formats don't really help, but I'll just send a patch
to kill them off for XFS ASAP to at least get that out, and we
probably should revert at least

"afs: Move UUID struct to linux/uuid.h"

That moved the AFS mess to common code as a start, and then
also clean up the way we generate random UUIDs, where we currently
have le helper, a be helper and then also generate_random_uuid
just to confuse the heck out of people.  With no description of
either of them.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv4 3/3] drm/vgem: Enable dmabuf import interfaces

[Daniel Vetter]

On Thu, May 04, 2017 at 09:25:03PM +0100, Chris Wilson wrote:
> On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
> > 
> > Enable the GEM dma-buf import interfaces in addition to the export
> > interfaces. This lets vgem be used as a test source for other allocators
> > (e.g. Ion).
> > 
> > Reviewed-by: Chris Wilson 
> > Signed-off-by: Laura Abbott 
> > ---
> > v4: Use new drm_gem_prime_import_dev function
> > ---
> >  static const struct vm_operations_struct vgem_gem_vm_ops = {
> > @@ -114,12 +142,8 @@ static void vgem_postclose(struct drm_device *dev, 
> > struct drm_file *file)
> > kfree(vfile);
> >  }
> >  
> > -/* ioctls */
> > -
> > -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> > - struct drm_file *file,
> > - unsigned int *handle,
> > - unsigned long size)
> > +static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device 
> > *dev,
> > +   unsigned long size)
> 
> I'm going to guess that doesn't line up anymore. If checkpatch isn't
> complaining, then sorry for the noise.
> 
> > +static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> > + struct drm_file *file,
> > + unsigned int *handle,
> > + unsigned long size)
> 
> Ditto.
> 
> Lgtm, so r-b still good.

I applied all three as-is, I think we can polish more as follow-ups.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Gerd Hoffmann]

  Hi,

> > >>Hmm, that looks like a rather strange way to return a file descriptor.
> > >>
> > >>What is the reason to not use ioctls on the vfio file handle, like
> > >>older version of these patches did?  
> > >If I understood correctly that Alex prefer not to change the ioctls on the 
> > >vfio file
> > >handle like the old version.
> > >So I used this way the smallest change to general vfio framework only 
> > >adding a
> > >subregion definition.
> 
> I think I was hoping we could avoid a separate file descriptor
> altogether and use a vfio region instead.

What exactly did you have in mind?  Put the framebuffer information
(struct intel_vgpu_dmabuf) into the vfio region, then access it using
read/write/mmap?

> However, it was explained
> previously why this really needs to be a separate fd and I agree that
> using a region to expose an fd is really awkward.

Now with this patchset we have *two* kinds of separate file handles.
First the anon-fd created by reading from the region.  This is then used
to run the intel ioctls on, which in turn create the other kind of file
handle (dma-buf-fd).

The dma-buf-fd really needs to be a separate fd, because it gets passed
around as handle and because this is the way dma-bufs work (guess this
is the discussion you are referring to).

I can't see a compelling reason for the anon-fd though.  I suspect this
was done due to a misunderstanding ...

cheers,
  Gerd

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix rawclk readout for g4x

[Jani Nikula]

On Thu, 04 May 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Turns out our skills in decoding the CLKCFG register weren't good
> enough. On this particular elk the answer we got was 400 MHz when
> in reality the clock was running at 266 MHz, which then caused us
> to program a bogus AUX clock divider that caused all AUX communication
> to fail.
>
> Sadly the docs are now in bit heaven, so the fix will have to be based
> on empirical evidence. Using another elk machine I was able to frob
> the FSB frequency from the BIOS and see how it affects the CLKCFG
> register. The machine seesm to use a frequency of 266 MHz by default,
> and fortunately it still boot even with the 50% CPU overclock that
> we get when we bump the FSB up to 400 MHz.
>
> It turns out the actual FSB frequency and the register have no real
> link whatsoever. The register value is based on some straps or something,
> but fortunately those too can be configured from the BIOS on this board,
> although it doesn't seem to respect the settings 100%. In the end I was
> able to derive the following relationship:
>
> BIOS FSB / strap | CLKCFG
> -
> 200  | 0x2
> 266  | 0x0
> 333  | 0x4
> 400  | 0x4
>
> So only the 200 and 400 MHz cases actually match how we're currently
> decoding that register. But as the comment next to some of the defines
> says, we have been just guessing anyway.
>
> So let's fix things up so that at least the 266 MHz case will work
> correctly as that is actually the setting used by both the buggy
> machine and my test machine.
>
> The fact that 333 and 400 MHz BIOS settings result in the same register
> value is a little disappointing, as that means we can't tell them apart.
> However, according to the gmch datasheet for both elk and ctg 400 Mhz is
> not even a supported FSB frequency, so I'm going to make the assumption
> that we should decode it as 333 MHz instead.

If you look at b11248df4c0d ("drm/i915: Add CLKCFG register definition")
and 7662c8bd6545 ("drm/i915: add FIFO watermark support"), the original
values seem to be on the guesswork side as well...

As such can't review, but

Acked-by: Jani Nikula 

>
> Cc: sta...@vger.kernel.org
> Cc: Tomi Sarvela 
> Reported-by: Tomi Sarvela 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h| 10 +++---
>  drivers/gpu/drm/i915/intel_cdclk.c |  6 ++
>  2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ee8170cda93e..524fdfda9d45 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3059,10 +3059,14 @@ enum skl_disp_power_wells {
>  #define CLKCFG_FSB_667   (3 << 0)
> /* hrawclk 166 */
>  #define CLKCFG_FSB_800   (2 << 0)
> /* hrawclk 200 */
>  #define CLKCFG_FSB_1067  (6 << 0)
> /* hrawclk 266 */
> +#define CLKCFG_FSB_1067_ALT  (0 << 0)/* 
> hrawclk 266 */
>  #define CLKCFG_FSB_1333  (7 << 0)
> /* hrawclk 333 */
> -/* Note, below two are guess */
> -#define CLKCFG_FSB_1600  (4 << 0)
> /* hrawclk 400 */
> -#define CLKCFG_FSB_1600_ALT  (0 << 0)/* 
> hrawclk 400 */
> +/*
> + * Note that on at least on ELK the below value is reported for both
> + * 333 and 400 MHz BIOS FSB setting, but given that the gmch datasheet
> + * lists only 200/266/333 MHz FSB as supported let's decode it as 333 MHz.
> + */
> +#define CLKCFG_FSB_1333_ALT  (4 << 0)/* 
> hrawclk 333 */
>  #define CLKCFG_FSB_MASK  (7 << 0)
>  #define CLKCFG_MEM_533   (1 << 4)
>  #define CLKCFG_MEM_667   (2 << 4)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 763010f8ad89..29792972d55d 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1808,13 +1808,11 @@ static int g4x_hrawclk(struct drm_i915_private 
> *dev_priv)
>   case CLKCFG_FSB_800:
>   return 20;
>   case CLKCFG_FSB_1067:
> + case CLKCFG_FSB_1067_ALT:
>   return 27;
>   case CLKCFG_FSB_1333:
> + case CLKCFG_FSB_1333_ALT:
>   return 33;
> - /* these two are just a guess; one of them might be right */
> - case CLKCFG_FSB_1600:
> - case CLKCFG_FSB_1600_ALT:
> - return 40;
>   default:
>   return 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Read link status after exit PSR (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/edp: Read link status after exit PSR (rev3)
URL   : https://patchwork.freedesktop.org/series/23631/
State : success

== Summary ==

Series 23631v3 drm/i915/edp: Read link status after exit PSR
https://patchwork.freedesktop.org/api/1.0/series/23631/revisions/3/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:579s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:548s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:486s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:402s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:489s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:457s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:578s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:452s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:567s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:404s

369880c1680bf9bde467a40d2a03d3ad32341281 drm-tip: 2017y-05m-04d-15h-00m-33s UTC 
integration manifest
7ae2b6b drm/i915/edp: Read link status after exit link training

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4628/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 4.9 regression: DP AUX CH sanitization no longer working on Asus desktops

[Jani Nikula]

On Thu, 04 May 2017, Daniel Drake  wrote:
> Hi,
>
> Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a
> regression on Linux 4.9 where the VGA output is shown all-white.

Would you mind filing a bug over at [1], essentially with this message
copy-pasted and the dmesg attached to the bug please?

Thanks,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


>
> This is a regression caused by:
>
> commit 0ce140d45a8398b501934ac289aef0eb7f47c596
> Author: Ville Syrjälä 
> Date:   Tue Oct 11 20:52:47 2016 +0300
>
> drm/i915: Clean up DDI DDC/AUX CH sanitation
>
>
> On these platforms, the VGA output is detected as DP (presumably
> theres a DP-to-VGA converter on the motherboard). The sanitization
> done by the code that was removed here was correctly realising that
> port E's DP aux channel was DP_AUX_A, so it disabled DP output on port
> A, also showing this message:
>
>[drm:intel_ddi_init] VBT says port A is not DVI/HDMI/DP compatible,
> respect it
>
> But after this cleanup commit, both port A and port E are activated
> and the screen shows all-white. Reverting the commit restores usable
> VGA display output.
>
> The reason the new implementation doesn't catch the duplicate
> configuration is because the new code only considers ports that are
> present in the VBT where parse_ddi_port() has run on them (in order to
> set that port's info->alternate_aux_channel).
>
> In this case, port A is not present in the VBT so it will not have
> info->alternate_aux_channel set, and the new sanitize_aux_ch will run
> on port E but will not consider any overlap with port A.
>
> debug logs from an affected kernel:
> https://gist.github.com/dsd/7e56c9bca7b2345b678cfacdab30ec55
>
> Should we modify sanitize_aux_ch to look at all aux channels, not only
> for the ports specified in the VBT?
>
> Thanks
> Daniel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915/edp: Read link status after exit link training

[Lee, Shawn C]

From: "Lee, Shawn C" 

Display driver read DPCD register 0x202, 0x203 and 0x204 to identify
eDP sink status. If PSR exit and link trainign are ongoing at eDP
sink. And eDP source read these registers at the same time.
eDP sink will report EQ & symbol lock not done. Then caused eDP
display flicking.

So driver have to make sure PSR already at inactive state before
read link status.

Change log:
v2:
- Use intel_wait_for_register() to replace I915_READ().
v3:
- Use to_i915() to retrieve drm_i915_private.
- Remove loop and extend wait_for_register timeout value to 100ms.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99639
TEST=Reboot DUT and no flicking on local display at login screen

Cc: Cooper Chiou 
Cc: Gary C Wang 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jim Bride 
Cc: Ryan Lin 
Cc: Tvrtko Ursulin 
Cc: Ville Syrjala 

Signed-off-by: Shawn Lee 
---
 drivers/gpu/drm/i915/intel_dp.c |   31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 08834f74d396..8be9fd2ef9e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4252,19 +4252,32 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
 }
 
 static void
+intel_edp_wait_link_train_complete(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (!intel_wait_for_register(dev_priv,
+   EDP_PSR_STATUS_CTL,
+   (EDP_PSR_STATUS_SENDING_TP1 |
+EDP_PSR_STATUS_SENDING_TP2_TP3 |
+EDP_PSR_STATUS_SENDING_IDLE |
+EDP_PSR_STATUS_AUX_SENDING),
+0,
+100))
+   return;
+}
+
+static void
 intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dev);
u8 link_status[DP_LINK_STATUS_SIZE];
 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
-   DRM_ERROR("Failed to get link status\n");
-   return;
-   }
-
if (!intel_encoder->base.crtc)
return;
 
@@ -4278,6 +4291,14 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
if (!intel_dp_link_params_valid(intel_dp))
return;
 
+   if (is_edp(intel_dp) && dev_priv->psr.enabled)
+   intel_edp_wait_link_train_complete(intel_dp);
+
+   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   DRM_ERROR("Failed to get link status\n");
+   return;
+   }
+
/* Retrain if Channel EQ or CR not ok */
if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

[Dan Williams]

On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
 wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki 
> Cc: Mika Westerberg 
> Cc: Borislav Petkov 
> Cc: Dan Williams 
> Cc: Amir Goldstein 
> Cc: Jarkko Sakkinen 
> Cc: Jani Nikula 
> Cc: Ben Skeggs 
> Cc: Benjamin Tissoires 
> Cc: Joerg Roedel 
> Cc: Adrian Hunter 
> Cc: Yisen Zhuang 
> Cc: Bjorn Helgaas 
> Cc: Zhang Rui 
> Cc: Felipe Balbi 
> Cc: Mathias Nyman 
> Cc: Heikki Krogerus 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Signed-off-by: Andy Shevchenko 
[..]
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 0f7982a1caaf..bd3e45ede056 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -74,11 +74,11 @@ struct nfit_table_prev {
> struct list_head flushes;
>  };
>
> -static u8 nfit_uuid[NFIT_UUID_MAX][16];
> +static uuid_le nfit_uuid[NFIT_UUID_MAX];
>
> -const u8 *to_nfit_uuid(enum nfit_uuids id)
> +const uuid_le *to_nfit_uuid(enum nfit_uuids id)
>  {
> -   return nfit_uuid[id];
> +   return _uuid[id];
>  }
>  EXPORT_SYMBOL(to_nfit_uuid);
>
> @@ -207,7 +207,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, 
> struct nvdimm *nvdimm,
> u32 offset, fw_status = 0;
> acpi_handle handle;
> unsigned int func;
> -   const u8 *uuid;
> +   const uuid_le *uuid;
> int rc, i;
>
> func = cmd;
> @@ -394,7 +394,7 @@ int nfit_spa_type(struct acpi_nfit_system_address *spa)
> int i;
>
> for (i = 0; i < NFIT_UUID_MAX; i++)
> -   if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0)
> +   if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le 
> *)spa->range_guid))

What is _cmp_pp? Why not _compare?

Other than that, looks ok to me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] ALSA: hda: Use loop counter for hdac_wait_for_cmd_dmas() timeout

[Lofstedt, Marta]

Chris, Jeeja already has a patch that fix this issue in bug 100419, this also 
"happens" to be identical to a patch a sent on an internal mail to Intel audio 
developers on the 5 of April. But, then they replied they wanted another 
solution. I guess it is up to audio dev to decide what solution they want. 

/Marta

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Thursday, May 4, 2017 1:42 PM
> To: Takashi Iwai 
> Cc: Koul, Vinod ; Kp, Jeeja ;
> alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; # v4 . 7+
> 
> Subject: Re: [Intel-gfx] [PATCH] ALSA: hda: Use loop counter for
> hdac_wait_for_cmd_dmas() timeout
> 
> On Thu, May 04, 2017 at 12:25:26PM +0200, Takashi Iwai wrote:
> > On Thu, 04 May 2017 12:18:29 +0200,
> > Chris Wilson wrote:
> > >
> > > hdac_wait_for_cmd_dmas() uses a jiffie timeout to ensure that we do
> > > not wait forever for stuck hardware. However, it is called from an
> > > irq-disabled context which prevents jiffie from advancing and so the
> > > loop doesn't terminate if the hardware fails. This can then cause
> > > NMI watchdog warnings, such as:
> > >
> > > NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
> > > Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi
> x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
> crc32_pclmul snd_hda_codec_realtek snd_hda_codec_generic
> ghash_clmulni_intel e1000e snd_hda_codec snd_hwdep snd_hda_core
> snd_pcm ptp mei_me prime_numbers pps_core mei lpc_ich i2c_hid
> i2c_designware_platform i2c_designware_core [last unloaded: i915]
> > > irq event stamp: 13366
> > > hardirqs last  enabled at (13365): []
> _raw_spin_unlock_irq+0x27/0x50
> > > hardirqs last disabled at (13366): []
> _raw_spin_lock_irq+0x12/0x50
> > > softirqs last  enabled at (12744): []
> __do_softirq+0x1d9/0x4c0
> > > softirqs last disabled at (12721): [] 
> > > irq_exit+0xa9/0xc0
> > > CPU: 3 PID: 10443 Comm: kworker/u8:11 Tainted: G U  
> > > 4.11.0-rc4-
> CI-CI_DRM_319+ #1
> > > Hardware name:  /NUC5i5RYB, BIOS
> RYBDWi35.86A.0362.2017.0118.0940 01/18/2017
> > > Workqueue: events_unbound async_run_entry_fn
> > > task: 88024cd32740 task.stack: c9000162c000
> > > RIP: 0010:preempt_count_add+0xe/0xc0
> > > RSP: 0018:c9000162fbd8 EFLAGS: 0082
> > > RAX: 8001 RBX: 000704b96558 RCX:
> 0002
> > > RDX:  RSI: 81c74f2d RDI: 0001
> > > RBP: c9000162fc08 R08: bbcc90cc R09: 23c7b071
> > > R10: 827901a8 R11: 88024cd32740 R12: 000704b92baa
> > > R13: 3ea0 R14: 0003 R15: a00061f0
> > > FS:  () GS:880256d8()
> knlGS:
> > > CS:  0010 DS:  ES:  CR0: 80050033
> > > CR2: 7f90f84a5144 CR3: 03e0f000 CR4: 003406e0
> > > Call Trace:
> > >  ? delay_tsc+0x3d/0xc0
> > >  __delay+0xa/0x10
> > >  __const_udelay+0x31/0x40
> > >  snd_hdac_bus_stop_cmd_io+0x96/0xe0 [snd_hda_core]
> > >  ? azx_dev_disconnect+0x20/0x20 [snd_hda_intel]
> > >  snd_hdac_bus_stop_chip+0xb1/0x100 [snd_hda_core]
> > >  azx_stop_chip+0x9/0x10 [snd_hda_codec]
> > >  azx_suspend+0x72/0x220 [snd_hda_intel]
> > >  pci_pm_suspend+0x71/0x140
> > >  dpm_run_callback+0x6f/0x330
> > >  ? pci_pm_freeze+0xe0/0xe0
> > >  __device_suspend+0xf9/0x370
> > >  ? dpm_watchdog_set+0x60/0x60
> > >  async_suspend+0x1a/0x90
> > >  async_run_entry_fn+0x34/0x160
> > >  process_one_work+0x1f4/0x6d0
> > >  ? process_one_work+0x16e/0x6d0
> > >  worker_thread+0x49/0x4a0
> > >  kthread+0x107/0x140
> > >  ? process_one_work+0x6d0/0x6d0
> > >  ? kthread_create_on_node+0x40/0x40
> > >  ret_from_fork+0x2e/0x40
> > >
> > > Fixes: 38b19ed7f81e ("ALSA: hda: fix to wait for RIRB & CORB DMA to
> > > set")
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100419
> > > Signed-off-by: Chris Wilson 
> > > Cc: Jeeja KP 
> > > Cc: Vinod Koul 
> > > Cc: Takashi Iwai 
> > > Cc:  # v4.7+
> >
> > Any reason to submit a different fix from what's attached in the
> > bugzilla you mentioned?
> 
> Because I didn't see it when Marta complained on irc and suggested
> reverting 38b19ed7f81e. There's no advantage either way, but even after
> fixing the timeout detection we are still left with the issue that the hw is
> stuck and suffer a 200ms suspend delay. :| -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Make scratch register base and count flexible

[Jani Nikula]

On Thu, 04 May 2017, Chris Wilson  wrote:
> On Thu, May 04, 2017 at 06:26:04PM +0200, Michal Wajdeczko wrote:
>> On Thu, May 04, 2017 at 04:22:15PM +0300, Jani Nikula wrote:
>> > On Thu, 04 May 2017, Michal Wajdeczko  wrote:
>> > > We are using some scratch registers in MMIO based send function.
>> > > Make their base and count flexible in preparation of upcoming
>> > > GuC firmware/hardware changes. While around, change cmd len
>> > > parameter verification from WARN_ON to GEM_BUG_ON as we don't
>> > > need this all the time.
>> > 
>> > I'm not generally fond of caching the registers like this or adding
>> > _MMIO() wrapping outside of i915_reg.h. Sure, we have some of that here
>> > and there, but here it's hard to see the rationale because you do this
>> > in preparation for something that we you're not sharing.
>> > 
>> 
>> I can't share details atm, but as commit message says, there will be a
>> change in both offsets and number of scratch registers.
>> 
>> Imho any wrapping around these values can't go to the i915_[guc_]reg.h file
>> as that file shall include only raw MMIO definitions, without any extra
>> logic that is based on GEN or PLATFORM or FW version.
>
> The guc->send.base + offset approach is reasonable; it is certainly
> the tried and trusted approach. I would stick with it, but we just can't
> help with any suggestions without seeing the destination.

That pretty much sums it up.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

[kbuild test robot]

Hi Andy,

[auto build test ERROR on next-20170503]
[cannot apply to pm/linux-next linus/master linux/master v4.9-rc8 v4.9-rc7 
v4.9-rc6 v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/ACPI-Switch-to-use-generic-UUID-API/20170505-134225
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from init/main.c:29:0:
>> include/linux/acpi.h:744:16: error: unknown type name 'uuid_le'
 const uuid_le *uuid,
   ^~~

vim +/uuid_le +744 include/linux/acpi.h

   738  const struct device_driver 
*drv)
   739  {
   740  return false;
   741  }
   742  
   743  static inline union acpi_object *acpi_evaluate_dsm(acpi_handle handle,
 > 744 const uuid_le *uuid,
   745 int rev, int func,
   746 union acpi_object 
*argv4)
   747  {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx