date:20170531

Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

2017-05-31 Thread Daniel Vetter

On Wed, May 31, 2017 at 05:57:07PM +0100, Liviu Dudau wrote:
> On Wed, May 31, 2017 at 06:41:05PM +0200, Daniel Vetter wrote:
> > On Wed, May 31, 2017 at 1:22 PM, Liviu Dudau  wrote:
> > > On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote:
> > >> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau  
> > >> wrote:
> > >> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> > >> >> IRQs are properly shut down, so it almost works as race-free shutdown.
> > >> >> Except the irq is stopped after the vblank stuff, so boom anyway.
> > >> >> Proper way would be to call drm_atomic_helper_shutdown before any of
> > >> >> the kms things gets stopped. So no harm in removing the
> > >> >> drm_vblank_cleanup here really.
> > >> >
> > >> > Slightly confused on the implied message in the commit text: is 
> > >> > "Proper way
> > >> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a 
> > >> > future
> > >> > patch? A message to the future us on how to fix things if they blow up?
> > >> >
> > >> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why 
> > >> > does the
> > >> > patch (and the series) avoids doing that? Lack of understanding of the 
> > >> > driver's
> > >> > internal workings? Then I want to help, if I can understand the new 
> > >> > direction.
> > >>
> > >> Yes, I wanted to not make things worse. If you look at the overall
> > >> result (especially last patch) I'm also trying to better document
> > >> stuff in the vblank area, but summarized, if you want to make sure
> > >> that vblank processing has stopped, you need to call drm_vblank_off on
> > >> each active crtc. The simplest way to get that is by using
> > >> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't
> > >> really do anything useful (see the last patch for the only valid
> > >> usecase there ever was).
> > >
> > > OK, so there should be a follow up patch adding 
> > > drm_atomic_helper_shutdown(). I guess
> > > I need to call dibs on it? :)
> > 
> > I googled what "to call dibs on smth" means and still can't figure out
> > what you mean here. Can you pls explain?
> 
> Means I put my name on it. Urban dictionary on "call dibs" gives it a very 
> gender
> specific usage, my intent was to convey the message that I will take it on my 
> TODO list.

Ah ok, thanks for explaining. I was indeed thrown off be the ub entry ...
-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

[Intel-gfx] [PATCH 2/3] drm/i915/skl: New ddb allocation algorithm

2017-05-31 Thread Mahesh Kumar

From: "Kumar, Mahesh" 

This patch implements new DDB allocation algorithm as per HW team
recommendation. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each
plane in crtc, for efficient power saving.

Changes since v1:
 - Rebase on top of Paulo's patch series

Changes since v2:
 - Fix the for loop condition to enable WM

Changes since v3:
 - Fix crash in cursor i-g-t reported by Maarten
 - Rebase after addressing Paulo's comments
 - Few other ULT fixes
Changes since v4:
 - Rebase on drm-tip
 - Added separate function to enable WM levels
Changes since v5:
 - Fix a crash identified in skl-6770HQ system
Changes since v6:
 - Address review comments from Matt
Changes since v7:
 - Fix failure return in skl_compute_plane_wm (Matt)
 - fix typo
Changes since v8:
 - Always check cursor wm enable irrespective of total_data_rate
Changes since v9:
 - fix typo

Signed-off-by: Mahesh Kumar 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 257 +---
 1 file changed, 159 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fce4bc5ccc99..1f9fee30cb4c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4039,13 +4039,41 @@ skl_ddb_calc_min(const struct intel_crtc_state *cstate, 
int num_active,
minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
 }
 
+static void
+skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
+  uint16_t plane_ddb,
+  uint16_t max_level,
+  struct skl_plane_wm *wm)
+{
+   int level;
+   /*
+* Now enable all levels in WM structure which can be enabled
+* using current DDB allocation
+*/
+   for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
+   struct skl_wm_level *level_wm = >wm[level];
+
+   if (level > max_level || level_wm->plane_res_b == 0
+ || level_wm->plane_res_l >= 31
+ || level_wm->plane_res_b >= plane_ddb) {
+   level_wm->plane_en = false;
+   level_wm->plane_res_b = 0;
+   level_wm->plane_res_l = 0;
+   } else {
+   level_wm->plane_en = true;
+   }
+   }
+}
+
 static int
 skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
+ struct skl_pipe_wm *pipe_wm,
  struct skl_ddb_allocation *ddb /* out */)
 {
struct drm_atomic_state *state = cstate->base.state;
struct drm_crtc *crtc = cstate->base.crtc;
struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
struct skl_ddb_entry *alloc = >wm.skl.ddb;
@@ -4058,6 +4086,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
unsigned plane_data_rate[I915_MAX_PLANES] = {};
unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
uint16_t total_min_blocks = 0;
+   uint16_t total_level_ddb;
+   uint16_t plane_blocks = 0;
+   int max_level, level;
 
/* Clear the partitioning for disabled planes. */
memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
@@ -4096,10 +4127,48 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
return -EINVAL;
}
 
-   alloc_size -= total_min_blocks;
-   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
minimum[PLANE_CURSOR];
+   alloc_size -= minimum[PLANE_CURSOR];
+   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end -
+   minimum[PLANE_CURSOR];
ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
 
+   for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
+   total_level_ddb = 0;
+   for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+   /*
+* TODO: We should calculate watermark values for Y/UV
+* plane both in case of NV12 format and use both values
+* for ddb calculation. NV12 is disabled as of now, So
+* using only single/UV plane value here.
+*/
+   struct skl_plane_wm *wm = _wm->planes[plane_id];
+   uint16_t plane_res_b = wm->wm[level].plane_res_b;
+   uint16_t min = minimum[plane_id] + y_minimum[plane_id];
+
+   if

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread kbuild test robot

Hi Rodrigo,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.12-rc3 next-20170531]
[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/Rodrigo-Vivi/drm-i915-cnp-Panel-Power-sequence-changes-for-CNP-PCH/20170601-101509
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x014-201722 (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 error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/mod_devicetable.h:11,
from include/linux/i2c.h:29,
from drivers/gpu//drm/i915/intel_dp.c:28:
   drivers/gpu//drm/i915/intel_dp.c: In function 'intel_pps_get_registers':
>> drivers/gpu//drm/i915/intel_dp.c:801:32: error: implicit declaration of 
>> function 'HAS_PCH_CNP' [-Werror=implicit-function-declaration]
 if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
   ^
   include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu//drm/i915/intel_dp.c:801:2: note: in expansion of macro 'if'
 if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
 ^~
   Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
   Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:ffs
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
   Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
   Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
   Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic64_64.h:atomic64_read
   Cyclomatic Complexity 1 include/asm-generic/atomic-long.h:atomic_long_read
   Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
   Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_save_flags
   Cyclomatic Complexity 1 
arch/x86/include/asm/irqflags.h:arch_irqs_disabled_flags
   Cyclomatic Complexity 1 arch/x86/include/asm/processor.h:rep_nop
   Cyclomatic Complexity 1 arch/x86/include/asm/processor.h:cpu_relax
   Cyclomatic Complexity 1 include/linux/mutex.h:__mutex_owner
   Cyclomatic Complexity 1 include/linux/mutex.h:mutex_is_locked
   Cyclomatic Complexity 1 arch/x86/include/asm/preempt.h:preempt_count
   Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
   Cyclomatic Complexity 5 include/linux/jiffies.h:msecs_to_jiffies
   Cyclomatic Complexity 1 include/linux/jiffies.h:_usecs_to_jiffies
   Cyclomatic Complexity 4 include/linux/jiffies.h:usecs_to_jiffies
   Cyclomatic Complexity 1 include/linux/workqueue.h:to_delayed_work
   Cyclomatic Complexity 1 include/linux/workqueue.h:__init_work
   Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large
   Cyclomatic Complexity 5 include/linux/slab.h:kmalloc
   Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
   Cyclomatic Complexity 1 include/linux/ww_mutex.h:ww_mutex_is_locked
   Cyclomatic Complexity 1 include/drm/drm_modeset_lock.h:drm_modeset_is_locked
   Cyclomatic Complexity 4 include/drm/drmP.h:drm_can_sleep
   Cyclomatic Complexity 1 
include/drm/drm_modeset_helper_vtables.h:drm_connector_helper_add
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_reg.h:i915_mmio_reg_offset
   Cyclomatic Complexity 2 drivers/gpu//drm/i915/i915_drv.h:yesno
   Cyclomatic Complexity 2 drivers/gpu//drm/i915/i915_drv.h:onoff
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_drv.h:to_i915
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_drv.h:intel_info
   Cyclomatic Complexity 1 
drivers/gpu//drm/i915/i915_drv.h:msecs_to_jiffies_timeout
   Cyclomatic Complexity 1 include/drm/drm_dp_helper.h:drm_dp_max_lane_count
   Cyclomatic Complexity 3 include/drm/drm_dp_helper.h:drm_dp_enhanced_frame_cap
   Cyclomatic Complexity 3 include/drm/drm_dp_helper.h:drm_dp_tps3_supported
   Cyclomatic Complexity 1 include/drm/drm_dp_helper.h:drm_dp_is_branch
   Cyclomatic Complexity 1 
drivers/gpu//drm/i915/intel_drv.h:intel_get_crtc_for_pipe
   Cyclomatic Complexity 1 
drivers/gpu//drm/i915/intel_drv.h:intel_attached_encoder
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_drv.h:dp_to_dig_port
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_drv.h:dp_to_lspcon
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_drv.h:intel_crtc_has_type
   Cyclom

Re: [Intel-gfx] [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g

2017-05-31 Thread Chen, Xiaoguang

Hi Gerd,

>-Original Message-
>From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
>Behalf Of Gerd Hoffmann
>Sent: Wednesday, May 31, 2017 8:05 PM
>To: Chen, Xiaoguang ;
>alex.william...@redhat.com; ch...@chris-wilson.co.uk; intel-
>g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A ; Tian, Kevin
>
>Subject: Re: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g
>
>On Sat, 2017-05-27 at 16:38 +0800, Xiaoguang Chen wrote:
>> +   if (plane_id == PLANE_PRIMARY) {
>
>Should be DRM_PLANE_TYPE_PRIMARY (likewise for the cursor).
OK. I will change in the next version.

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

Re: [Intel-gfx] [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

2017-05-31 Thread Chen, Xiaoguang

Hi Kirti,

>-Original Message-
>From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
>Sent: Thursday, June 01, 2017 1:23 AM
>To: Chen, Xiaoguang ; Gerd Hoffmann
>; alex.william...@redhat.com; ch...@chris-wilson.co.uk;
>intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A ; Tian, Kevin
>
>Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
>
>
>
>On 5/31/2017 11:48 AM, Chen, Xiaoguang wrote:
>> Hi,
>>
>>> -Original Message-
>>> From: Gerd Hoffmann [mailto:kra...@redhat.com]
>>> Sent: Monday, May 29, 2017 3:20 PM
>>> To: Chen, Xiaoguang ;
>>> alex.william...@redhat.com; ch...@chris-wilson.co.uk; intel-
>>> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>>> zhen...@linux.intel.com; Lv, Zhiyuan ;
>>> intel-gvt- d...@lists.freedesktop.org; Wang, Zhi A
>>> ; Tian, Kevin 
>>> Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf
>>> operations
>>>
 +struct vfio_vgpu_dmabuf_info {
 +  __u32 argsz;
 +  __u32 flags;
 +  struct vfio_vgpu_plane_info plane_info;
 +  __s32 fd;
 +  __u32 pad;
 +};
>>>
>>> Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...
>>>
>>> I think we should have something like this:
>>>
>>> struct vfio_vgpu_plane_info {
>>> __u64 start;
>>> __u64 drm_format_mod;
>>> __u32 drm_format;
>>> __u32 width;
>>> __u32 height;
>>> __u32 stride;
>>> __u32 size;
>>> __u32 x_pos;
>>> __u32 y_pos;
>>>__u32 padding;
>>> };
>>>
>>> struct vfio_vgpu_query_plane {
>>> __u32 argsz;
>>> __u32 flags;
>>> struct vfio_vgpu_plane_info plane_info;
>>>__u32 plane_id;
>>>__u32 padding;
>>> };
>>>
>>> struct vfio_vgpu_create_dmabuf {
>>> __u32 argsz;
>>> __u32 flags;
>>> struct vfio_vgpu_plane_info plane_info;
>>>__u32 plane_id;
>>>__s32 fd;
>>> };
>> Good suggestion will apply in the next version.
>> Thanks for review :)
>>
>
>Can you define what are the expected values of 'flags' would be?
Flags is not used in this case.  It is defined to follow the rules of vfio 
ioctls.

>
>Thanks,
>Kirti
>
>> Chenxg.
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND 1/6] drm/atomic: initial support for asynchronous plane update

2017-05-31 Thread Gustavo Padovan

2017-05-31 Eric Anholt :

> Gustavo Padovan  writes:
> 
> > From: Gustavo Padovan 
> >
> > In some cases, like cursor updates, it is interesting to update the
> > plane in an asynchronous fashion to avoid big delays. The current queued
> > update could be still waiting for a fence to signal and thus block any
> > subsequent update until its scan out. In cases like this if we update the
> > cursor synchronously through the atomic API it will cause significant
> > delays that would even be noticed by the final user.
> >
> > This patch creates a fast path to jump ahead the current queued state and
> > do single planes updates without going through all atomic steps in
> > drm_atomic_helper_commit(). We take this path for legacy cursor updates.
> >
> > For now only single plane updates are supported, but we plan to support
> > multiple planes updates and async PageFlips through this interface as well
> > in the near future.
> 
> Sorry for taking so long to do some review for this.
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 65 
> > 
> >  drivers/gpu/drm/drm_atomic_helper.c  | 35 +
> >  include/drm/drm_atomic.h |  2 +
> >  include/drm/drm_atomic_helper.h  |  2 +
> >  include/drm/drm_modeset_helper_vtables.h | 48 +++
> >  5 files changed, 152 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index be62774..2a0c297 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -631,6 +631,68 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
> > return 0;
> >  }
> >  
> > +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> > +{
> > +   struct drm_crtc *crtc;
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc_commit *commit;
> > +   struct drm_plane *__plane, *plane = NULL;
> > +   struct drm_plane_state *__plane_state, *plane_state = NULL;
> > +   const struct drm_plane_helper_funcs *funcs;
> > +   int i, j, n_planes = 0;
> > +
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > +   if (drm_atomic_crtc_needs_modeset(crtc_state))
> > +   return false;
> > +   }
> > +
> > +   for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> > +   n_planes++;
> > +   plane = __plane;
> > +   plane_state = __plane_state;
> > +   }
> > +
> > +   /* FIXME: we support only single plane updates for now */
> > +   if (!plane || n_planes != 1)
> > +   return false;
> > +
> > +   if (!plane_state->crtc)
> > +   return false;
> > +
> > +   funcs = plane->helper_private;
> > +   if (!funcs->atomic_async_update)
> > +   return false;
> > +
> > +   if (plane_state->fence)
> > +   return false;
> > +
> 
> Could you add a comment here like:
> 
> /* Don't do an async update if there is an outstanding commit modifying
>  * the plane.  This prevents our async update's changes from getting
>  * overridden by a previous synchronous update's state.
>  */
> 
> (assuming I understand its intent correctly)
> 
> I don't understand KMS locking enough to say if this loop is actually
> safely guaranteeing that.  If you're convinced of that, then with my
> little cleanups this patch will be:

I'm going to check the locking again just to make sure.

> 
> Acked-by: Eric Anholt 
> 
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > +   if (plane->crtc != crtc)
> > +   continue;
> > +
> > +   spin_lock(>commit_lock);
> > +   commit = list_first_entry_or_null(>commit_list,
> > + struct drm_crtc_commit,
> > + commit_entry);
> > +   if (!commit) {
> > +   spin_unlock(>commit_lock);
> > +   continue;
> > +   }
> > +   spin_unlock(>commit_lock);
> > +
> > +   if (!crtc->state->state)
> > +   continue;
> > +
> > +   for_each_plane_in_state(crtc->state->state, __plane,
> > +   __plane_state, j) {
> > +   if (__plane == plane)
> > +   return false;
> > +   }
> > +   }
> > +
> > +   return !funcs->atomic_async_check(plane, plane_state);
> > +}
> > +
> >  static void drm_atomic_crtc_print_state(struct drm_printer *p,
> > const struct drm_crtc_state *state)
> >  {
> > @@ -1591,6 +1653,9 @@ int drm_atomic_check_only(struct drm_atomic_state 
> > *state)
> > }
> > }
> >  
> > +   if (state->legacy_cursor_update)
> > +   state->async_update = drm_atomic_async_check(state);
> > +
> > return ret;
> >  }
> >  EXPORT_SYMBOL(drm_atomic_check_only);
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >

Re: [Intel-gfx] [PATCH 04/13] drm/i915/cnp: Backlight support for CNP.

2017-05-31 Thread Pandiyan, Dhinakaran

On Tue, 2017-05-30 at 15:42 -0700, Rodrigo Vivi wrote:
> Split out BXT and CNP's setup_backlight(),enable_backlight(),
> disable_backlight() and hz_to_pwm() into
> two separate functions instead of reusing BXT function.
> 
> Reuse set_backlight() and get_backlight() since they have
> no reference to the utility pin.
> 
> v2: Reuse BXT functions with controller 0 instead of
> redefining it. (Jani).
> Use dev_priv->rawclk_freq instead of getting the value
> from SFUSE_STRAP.
> v3: Avoid setup backligh controller along with hooks and
> fully reuse hooks setup as suggested by Jani.
> v4: Clean up commit message.
> v5: Implement per PCH instead per platform.
> 
> v6: Introduce a new function for CNP.(Jani and Ville)
> 
> v7: Squash the all CNP Backlight support patches into a
> single patch. (Jani)
> 
> v8: Correct indentation, remove unneeded blank lines and
> correct mail address (Jani).
> 
> v9: Remove unused enum pipe. (by CI)
> 
> Reviewed-by: Jani Nikula 
> Suggested-by: Jani Nikula 
> Suggested-by: Ville Syrjala 
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 93 
> ++
>  1 file changed, 93 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index c8103f8..7e34a1b 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct intel_connector 
> *connector)
>   }
>  }
>  
> +static void cnp_disable_backlight(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_panel *panel = >panel;
> + u32 tmp;
> +
> + intel_panel_actually_set_backlight(connector, 0);
> +
> + tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
> + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
> +tmp & ~BXT_BLC_PWM_ENABLE);
> +}
> +
>  static void pwm_disable_backlight(struct intel_connector *connector)
>  {
>   struct intel_panel *panel = >panel;
> @@ -1086,6 +1099,35 @@ static void bxt_enable_backlight(struct 
> intel_connector *connector)
>   pwm_ctl | BXT_BLC_PWM_ENABLE);
>  }
>  
> +static void cnp_enable_backlight(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_panel *panel = >panel;
> + u32 pwm_ctl;
> +
> + pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));

Shouldn't this be BLC_PWM_PCH_CTL1?

I think reusing CPU register definitions for PCH is confusing. Even more
so, when we already have separate definitions for PCH.

BSpec specifically refers to these registers as SBLC_PWM_CTL1,
SBLC_PWM_FREQ and SBLC_PWM_DUTY.




> + if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
> + DRM_DEBUG_KMS("backlight already enabled\n");
> + pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
> + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
> +pwm_ctl);
> + }
> +
> + I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
> +panel->backlight.max);
> +
> + intel_panel_actually_set_backlight(connector, panel->backlight.level);
> +
> + pwm_ctl = 0;
> + if (panel->backlight.active_low_pwm)
> + pwm_ctl |= BXT_BLC_PWM_POLARITY;
> +
> + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
> + POSTING_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
> + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
> +pwm_ctl | BXT_BLC_PWM_ENABLE);
> +}
> +
>  static void pwm_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_panel *panel = >panel;
> @@ -1250,6 +1292,18 @@ void intel_backlight_device_unregister(struct 
> intel_connector *connector)
>  #endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
>  
>  /*
> + * CNP: PWM clock frequency is 19.2 MHz or 24 MHz.
> + *  Value is found in SFUSE_STRAP.
> + *  PWM increment = 1
> + */
> +static u32 cnp_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> +
> + return DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), pwm_freq_hz);
> +}
> +
> +/*
>   * BXT: PWM clock frequency = 19.2 MHz.
>   */
>  static u32 bxt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
> @@ -1644,6 +1698,37 @@ static int vlv_setup_backlight(struct intel_connector 
> *connector, enum pipe pipe
>   return 0;
>  }
>  
> +static int
> +cnp_setup_backlight(struct intel_connector *connector, enum pipe unused)
> +{
> + struct

Re: [Intel-gfx] [PATCH RESEND 6/6] drm/vc4: update cursors asynchronously through atomic

2017-05-31 Thread Gustavo Padovan

2017-05-31 Eric Anholt :

> Gustavo Padovan  writes:
> 
> > From: Gustavo Padovan 
> >
> > Add support to async updates of cursors by using the new atomic
> 
> "Add support for"
> 
> > interface for that. Basically what this commit does is do what
> > vc4_update_plane() did but through atomic.
> >
> > v3: move size checks back to drivers (Ville Syrjälä)
> >
> > v2: move fb setting to core and use new state (Eric Anholt)
> 
> Given that vc4 isn't using drm_atomic_helper_commit(), isn't this
> effectively disabling async cursor updates on vc4?

Right, yes. I didn't have a chance to run this in at the hw as I don't
have it right now. I'll update the patch and resend.

Gustavo


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

Re: [Intel-gfx] [PATCH] drm/i915: Guard against i915_ggtt_disable_guc() being invoked unconditionally

2017-05-31 Thread Michel Thierry


On 5/31/2017 12:05 PM, Chris Wilson wrote:

Commit 7c3f86b6dc51 ("drm/i915: Invalidate the guc ggtt TLB upon
insertion") added the restoration of the invalidation routine after the
GuC was disabled, but missed that the GuC was unconditionally disabled
when not used. This then overwrites the invalidate routine for the older
chipsets, causing havoc and breaking resume as the most obvious victim.

We place the guard inside i915_ggtt_disable_guc() to be backport
friendly (the bug was introduced into v4.11) but it would be preferred
to be in more control over when this was guard (i.e. do not try and
teardown the data structures before we have enabled them). That should
be true with the reorganisation of the guc loaders.

Reported-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Fixes: 7c3f86b6dc51 ("drm/i915: Invalidate the guc ggtt TLB upon insertion")
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc:  # v4.11+
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4f581adf2fcf..6eb83684b97b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3282,7 +3282,8 @@ void i915_ggtt_enable_guc(struct drm_i915_private *i915)

 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
-   i915->ggtt.invalidate = gen6_ggtt_invalidate;
+   if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+   i915->ggtt.invalidate = gen6_ggtt_invalidate;
 }

 void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)


Reviewed-by: Michel Thierry 

btw the bug can only happen in 4.11; in 4.12+ this safeguard is already 
redundant since enable_guc_loading should be zero and ggtt_disable_guc 
is never called.


-Michel

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

Re: [Intel-gfx] [PATCH RESEND 1/6] drm/atomic: initial support for asynchronous plane update

2017-05-31 Thread Eric Anholt

Gustavo Padovan  writes:

> From: Gustavo Padovan 
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays. The current queued
> update could be still waiting for a fence to signal and thus block any
> subsequent update until its scan out. In cases like this if we update the
> cursor synchronously through the atomic API it will cause significant
> delays that would even be noticed by the final user.
>
> This patch creates a fast path to jump ahead the current queued state and
> do single planes updates without going through all atomic steps in
> drm_atomic_helper_commit(). We take this path for legacy cursor updates.
>
> For now only single plane updates are supported, but we plan to support
> multiple planes updates and async PageFlips through this interface as well
> in the near future.

Sorry for taking so long to do some review for this.

> ---
>  drivers/gpu/drm/drm_atomic.c | 65 
> 
>  drivers/gpu/drm/drm_atomic_helper.c  | 35 +
>  include/drm/drm_atomic.h |  2 +
>  include/drm/drm_atomic_helper.h  |  2 +
>  include/drm/drm_modeset_helper_vtables.h | 48 +++
>  5 files changed, 152 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index be62774..2a0c297 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -631,6 +631,68 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>   return 0;
>  }
>  
> +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc_commit *commit;
> + struct drm_plane *__plane, *plane = NULL;
> + struct drm_plane_state *__plane_state, *plane_state = NULL;
> + const struct drm_plane_helper_funcs *funcs;
> + int i, j, n_planes = 0;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + if (drm_atomic_crtc_needs_modeset(crtc_state))
> + return false;
> + }
> +
> + for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> + n_planes++;
> + plane = __plane;
> + plane_state = __plane_state;
> + }
> +
> + /* FIXME: we support only single plane updates for now */
> + if (!plane || n_planes != 1)
> + return false;
> +
> + if (!plane_state->crtc)
> + return false;
> +
> + funcs = plane->helper_private;
> + if (!funcs->atomic_async_update)
> + return false;
> +
> + if (plane_state->fence)
> + return false;
> +

Could you add a comment here like:

/* Don't do an async update if there is an outstanding commit modifying
 * the plane.  This prevents our async update's changes from getting
 * overridden by a previous synchronous update's state.
 */

(assuming I understand its intent correctly)

I don't understand KMS locking enough to say if this loop is actually
safely guaranteeing that.  If you're convinced of that, then with my
little cleanups this patch will be:

Acked-by: Eric Anholt 

> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + if (plane->crtc != crtc)
> + continue;
> +
> + spin_lock(>commit_lock);
> + commit = list_first_entry_or_null(>commit_list,
> +   struct drm_crtc_commit,
> +   commit_entry);
> + if (!commit) {
> + spin_unlock(>commit_lock);
> + continue;
> + }
> + spin_unlock(>commit_lock);
> +
> + if (!crtc->state->state)
> + continue;
> +
> + for_each_plane_in_state(crtc->state->state, __plane,
> + __plane_state, j) {
> + if (__plane == plane)
> + return false;
> + }
> + }
> +
> + return !funcs->atomic_async_check(plane, plane_state);
> +}
> +
>  static void drm_atomic_crtc_print_state(struct drm_printer *p,
>   const struct drm_crtc_state *state)
>  {
> @@ -1591,6 +1653,9 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   }
>   }
>  
> + if (state->legacy_cursor_update)
> + state->async_update = drm_atomic_async_check(state);
> +
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_atomic_check_only);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5a3c9c0..a8efdfe 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1235,6 +1235,30 @@ static void commit_work(struct work_struct *work)
>  }
>  
>  /**
> + *

Re: [Intel-gfx] [PATCH RESEND 6/6] drm/vc4: update cursors asynchronously through atomic

2017-05-31 Thread Eric Anholt

Gustavo Padovan  writes:

> From: Gustavo Padovan 
>
> Add support to async updates of cursors by using the new atomic

"Add support for"

> interface for that. Basically what this commit does is do what
> vc4_update_plane() did but through atomic.
>
> v3: move size checks back to drivers (Ville Syrjälä)
>
> v2: move fb setting to core and use new state (Eric Anholt)

Given that vc4 isn't using drm_atomic_helper_commit(), isn't this
effectively disabling async cursor updates on vc4?


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

2017-05-31 Thread Patchwork

== Series Details ==

Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.
URL   : https://patchwork.freedesktop.org/series/25136/
State : success

== Summary ==

Series 25136v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25136/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:447s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:578s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:435s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:496s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:569s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  
time:426s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:500s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:437s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC 
integration manifest
da3ebb7 drm/i915/cnp: Panel Power sequence changes for CNP PCH.
bb41028 drm/i915/cnp: add CNP gmbus support
06690d5 drm/i915/cnp: Backlight support for CNP.
9954cfb drm/i915/cnp: Get/set proper Raw clock frequency on CNP.
daefe68 drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH
954a84e drm/i915/cnp: Introduce Cannonpoint PCH.

== Logs ==

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

[Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

2017-05-31 Thread Rodrigo Vivi

Split out BXT and CNP's setup_backlight(),enable_backlight(),
disable_backlight() and hz_to_pwm() into
two separate functions instead of reusing BXT function.

Reuse set_backlight() and get_backlight() since they have
no reference to the utility pin.

v2: Reuse BXT functions with controller 0 instead of
redefining it. (Jani).
Use dev_priv->rawclk_freq instead of getting the value
from SFUSE_STRAP.
v3: Avoid setup backligh controller along with hooks and
fully reuse hooks setup as suggested by Jani.
v4: Clean up commit message.
v5: Implement per PCH instead per platform.

v6: Introduce a new function for CNP.(Jani and Ville)

v7: Squash the all CNP Backlight support patches into a
single patch. (Jani)

v8: Correct indentation, remove unneeded blank lines and
correct mail address (Jani).

v9: Remove unused enum pipe. (by CI)

Reviewed-by: Jani Nikula 
Suggested-by: Jani Nikula 
Suggested-by: Ville Syrjala 
Cc: Ville Syrjala 
Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_panel.c | 93 ++
 1 file changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index c8103f8..7e34a1b 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct intel_connector 
*connector)
}
 }
 
+static void cnp_disable_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 tmp;
+
+   intel_panel_actually_set_backlight(connector, 0);
+
+   tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  tmp & ~BXT_BLC_PWM_ENABLE);
+}
+
 static void pwm_disable_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
@@ -1086,6 +1099,35 @@ static void bxt_enable_backlight(struct intel_connector 
*connector)
pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
+static void cnp_enable_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 pwm_ctl;
+
+   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
+   DRM_DEBUG_KMS("backlight already enabled\n");
+   pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  pwm_ctl);
+   }
+
+   I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
+  panel->backlight.max);
+
+   intel_panel_actually_set_backlight(connector, panel->backlight.level);
+
+   pwm_ctl = 0;
+   if (panel->backlight.active_low_pwm)
+   pwm_ctl |= BXT_BLC_PWM_POLARITY;
+
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
+   POSTING_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  pwm_ctl | BXT_BLC_PWM_ENABLE);
+}
+
 static void pwm_enable_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
@@ -1250,6 +1292,18 @@ void intel_backlight_device_unregister(struct 
intel_connector *connector)
 #endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
 
 /*
+ * CNP: PWM clock frequency is 19.2 MHz or 24 MHz.
+ *  Value is found in SFUSE_STRAP.
+ *  PWM increment = 1
+ */
+static u32 cnp_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+
+   return DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), pwm_freq_hz);
+}
+
+/*
  * BXT: PWM clock frequency = 19.2 MHz.
  */
 static u32 bxt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
@@ -1644,6 +1698,37 @@ static int vlv_setup_backlight(struct intel_connector 
*connector, enum pipe pipe
return 0;
 }
 
+static int
+cnp_setup_backlight(struct intel_connector *connector, enum pipe unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 pwm_ctl, val;
+
+   panel->backlight.controller = dev_priv->vbt.backlight.controller;
+
+   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+
+   panel->backlight.active_low_pwm = pwm_ctl & BXT_BLC_PWM_POLARITY;
+   panel->backlight.max =
+   I915_READ(BXT_BLC_PWM_FREQ(panel->backlight.controller));
+
+   if (!panel->backlight.max)
+

[Intel-gfx] [PATCH 5/6] drm/i915/cnp: add CNP gmbus support

2017-05-31 Thread Rodrigo Vivi

On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.

v2: Don't drop "_BXT" as the indicator of the first platform
supporting this pin numbers. Suggested by Daniel.
v3: Add missing else and fix register table since CNP GPIO_CTL
starts on 0xC5014.
v4: Fix pin number and map according to the current available VBT.
Re-add pin 4 for port D. Lost during some rebase.
v5: Use table as spec. If VBT is wrong it should be ignored.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++-
 drivers/gpu/drm/i915/intel_hdmi.c |  8 +---
 drivers/gpu/drm/i915/intel_i2c.c  | 15 +--
 3 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cb83fb7..1329420 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2626,9 +2626,10 @@ enum skl_disp_power_wells {
 #define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
 #define   GMBUS_PIN_DPD6 /* HDMID */
 #define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
-#define   GMBUS_PIN_1_BXT  1
+#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
 #define   GMBUS_PIN_2_BXT  2
 #define   GMBUS_PIN_3_BXT  3
+#define   GMBUS_PIN_4_CNP  4
 #define   GMBUS_NUM_PINS   7 /* including 0 */
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 41267ff..ec0779a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1802,19 +1802,21 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
*dev_priv,
 
switch (port) {
case PORT_B:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_1_BXT;
else
ddc_pin = GMBUS_PIN_DPB;
break;
case PORT_C:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_2_BXT;
else
ddc_pin = GMBUS_PIN_DPC;
break;
case PORT_D:
-   if (IS_CHERRYVIEW(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   ddc_pin = GMBUS_PIN_4_CNP;
+   else if (IS_CHERRYVIEW(dev_priv))
ddc_pin = GMBUS_PIN_DPD_CHV;
else
ddc_pin = GMBUS_PIN_DPD;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b6401e8..3c9e00d 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -68,11 +68,20 @@ struct gmbus_pin {
[GMBUS_PIN_3_BXT] = { "misc", GPIOD },
 };
 
+static const struct gmbus_pin gmbus_pins_cnp[] = {
+   [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
+   [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
+   [GMBUS_PIN_3_BXT] = { "misc", GPIOD },
+   [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
+};
+
 /* pin is expected to be valid */
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   return _pins_cnp[pin];
+   else if (IS_GEN9_LP(dev_priv))
return _pins_bxt[pin];
else if (IS_GEN9_BC(dev_priv))
return _pins_skl[pin];
@@ -87,7 +96,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   size = ARRAY_SIZE(gmbus_pins_cnp);
+   else if (IS_GEN9_LP(dev_priv))
size = ARRAY_SIZE(gmbus_pins_bxt);
else if (IS_GEN9_BC(dev_priv))
size = ARRAY_SIZE(gmbus_pins_skl);
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/6] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

2017-05-31 Thread Rodrigo Vivi

From: Dhinakaran Pandiyan 

The first two bytes of PCI ID for CNP_LP PCH are the same as that of
SPT_LP. We should really be looking at the first 9 bits instead of the
first 8 to identify platforms, although this seems to have not caused any
problems on earlier platforms. Introduce a 9 bit extended mask for SPT and
CNP while not touching the code for any of the other platforms.

v2: (Rodrigo) Make platform agnostic and fix commit message.

Signed-off-by: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_drv.c | 8 +++-
 drivers/gpu/drm/i915/i915_drv.h | 4 
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9e4c13e..90b646c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -170,6 +170,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
if (pch->vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch->device & 
INTEL_PCH_DEVICE_ID_MASK;
+   unsigned short id_ext = pch->device &
+   INTEL_PCH_DEVICE_ID_MASK_EXT;
+
dev_priv->pch_id = id;
 
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
@@ -206,7 +209,7 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
-   } else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
+   } else if (id_ext == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
@@ -219,6 +222,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
} else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_CNP;
DRM_DEBUG_KMS("Found CannonPoint PCH\n");
+   } else if (id_ext == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_CNP;
+   DRM_DEBUG_KMS("Found CannonPoint LP PCH\n");
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0b82604..c31c0cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2959,6 +2959,7 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
 
 #define INTEL_PCH_DEVICE_ID_MASK   0xff00
+#define INTEL_PCH_DEVICE_ID_MASK_EXT   0xff80
 #define INTEL_PCH_IBX_DEVICE_ID_TYPE   0x3b00
 #define INTEL_PCH_CPT_DEVICE_ID_TYPE   0x1c00
 #define INTEL_PCH_PPT_DEVICE_ID_TYPE   0x1e00
@@ -2968,12 +2969,15 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA200
 #define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
+#define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
 #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
+#define HAS_PCH_CNP_LP(dev_priv) \
+   ((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
-- 
1.9.1

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

[Intel-gfx] [PATCH 6/6] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread Rodrigo Vivi

Panel Power sequences for CNP is similar to Broxton,
but with only one sequencer.

Main difference from SPT is that PP_DIVISOR was removed
and power cycle delay has been moved to PP_CONTROL.

v2: Add missed pp_div write, that is now part of PP_CONTROL[8:4]
as on Broxton. (Found by DK)

v3: Improve commit message. (By DK)

Cc: Dhinakaran Pandiyan 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Clinton Taylor 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 58dca87..db51338 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct drm_i915_private 
*dev_priv,
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
regs->pp_off = PP_OFF_DELAYS(pps_idx);
-   if (!IS_GEN9_LP(dev_priv))
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
regs->pp_div = PP_DIVISOR(pps_idx);
 }
 
@@ -5099,7 +5099,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 
pp_on = I915_READ(regs.pp_on);
pp_off = I915_READ(regs.pp_off);
-   if (!IS_GEN9_LP(dev_priv)) {
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
I915_WRITE(regs.pp_ctrl, pp_ctl);
pp_div = I915_READ(regs.pp_div);
}
@@ -5117,7 +5117,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
   PANEL_POWER_DOWN_DELAY_SHIFT;
 
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
BXT_POWER_CYCLE_DELAY_SHIFT;
if (tmp > 0)
@@ -5274,7 +5274,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
/* Compute the divisor for the pp clock, simply match the Bspec
 * formula. */
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
pp_div = I915_READ(regs.pp_ctrl);
pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
@@ -5300,7 +5300,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 
I915_WRITE(regs.pp_on, pp_on);
I915_WRITE(regs.pp_off, pp_off);
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
I915_WRITE(regs.pp_ctrl, pp_div);
else
I915_WRITE(regs.pp_div, pp_div);
@@ -5308,7 +5308,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
PP_OFF %#x, PP_DIV %#x\n",
  I915_READ(regs.pp_on),
  I915_READ(regs.pp_off),
- IS_GEN9_LP(dev_priv) ?
+ (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
  (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
  I915_READ(regs.pp_div));
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

2017-05-31 Thread Rodrigo Vivi

Most of south engine display that is in PCH is still the
same as SPT and KBP, except for this key differences:

- Backlight: Backlight programming changed in CNP PCH.
- Panel Power: Sligh programming changed in CNP PCH.
- GMBUS and GPIO: The pin mapping has changed in CNP PCH.

All of these changes follow more the BXT style.

v2: Update definition to use dev_priv isntead of dev (Tvrtko).

Cc: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 +++
 drivers/gpu/drm/i915/i915_drv.h | 3 +++
 drivers/gpu/drm/i915/i915_irq.c | 6 --
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2fdfaf1..9e4c13e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -216,6 +216,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found KabyPoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
+   } else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_CNP;
+   DRM_DEBUG_KMS("Found CannonPoint PCH\n");
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bde554e..0b82604 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1151,6 +1151,7 @@ enum intel_pch {
PCH_LPT,/* Lynxpoint PCH */
PCH_SPT,/* Sunrisepoint PCH */
PCH_KBP,/* Kabypoint PCH */
+   PCH_CNP,/* Cannonpoint PCH */
PCH_NOP,
 };
 
@@ -2966,11 +2967,13 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define INTEL_PCH_SPT_DEVICE_ID_TYPE   0xA100
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA200
+#define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
+#define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7b7f55a..4cd9ee1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2548,7 +2548,8 @@ static void bxt_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
I915_WRITE(SDEIIR, iir);
ret = IRQ_HANDLED;
 
-   if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv))
+   if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
+   HAS_PCH_CNP(dev_priv))
spt_irq_handler(dev_priv, iir);
else
cpt_irq_handler(dev_priv, iir);
@@ -4289,7 +4290,8 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->disable_vblank = gen8_disable_vblank;
if (IS_GEN9_LP(dev_priv))
dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
-   else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv))
+   else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
+HAS_PCH_CNP(dev_priv))
dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
else
dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/6] drm/i915/cnp: Get/set proper Raw clock frequency on CNP.

2017-05-31 Thread Rodrigo Vivi

RAWCLK_FREQ register has changed for platforms with CNP+.

[29:26] This field provides the denominator for the fractional
part of the microsecond counter divider.  The numerator
is fixed at 1. Program this field to the denominator of
the fractional portion of reference frequency minus one.
If the fraction is 0, program to 0.
0100b = Fraction .2 MHz = Fraction 1/5.
b = Fraction .0 MHz.

[25:16] This field provides the integer part of the microsecond
counter divider. Program this field to the integer portion
of the reference frequenct minus one.

Also this register tells us that proper raw clock should be read
from SFUSE_STRAP and programmed to this register. Up to this point
on other platforms we are reading instead of programming it so
probably relying on whatever BIOS had configured here.

Now on let's follow the spec and also program this register
fetching the right value from SFUSE_STRAP as Spec tells us to do.

v2: Read from SFUSE_STRAP and Program RAWCLK_FREQ instead of
reading the value relying someone else will program that
for us.
v3: Add missing else. (Jani)
v4: Addressing all Ville's catches:
Use macro for shift bits instead of defining shift.
Remove shift from the cleaning bits with mask that already
has it.
Add missing I915_WRITE to actually write the reg.
Stop using useless DIV_ROUND_* on divider that is exact
dividion and use DIV_ROUND_CLOSEST for the fraction part.
v5: Remove useless Read-Modify-Write on raclk_freq reg. (Ville).
v6: Change is per PCH instead of per platform.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h|  5 +
 drivers/gpu/drm/i915/intel_cdclk.c | 29 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 231ee86..cb83fb7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6838,6 +6838,10 @@ enum {
 #define  FDL_TP2_TIMER_SHIFT10
 #define  FDL_TP2_TIMER_MASK (3<<10)
 #define  RAWCLK_FREQ_MASK   0x3ff
+#define  CNP_RAWCLK_DIV_MASK   (0x3ff << 16)
+#define  CNP_RAWCLK_DIV(div)   ((div) << 16)
+#define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
+#define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
 
 #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
 
@@ -8141,6 +8145,7 @@ enum {
 /* SFUSE_STRAP */
 #define SFUSE_STRAP_MMIO(0xc2014)
 #define  SFUSE_STRAP_FUSE_LOCK (1<<13)
+#define  SFUSE_STRAP_RAW_FREQUENCY (1<<8)
 #define  SFUSE_STRAP_DISPLAY_DISABLED  (1<<7)
 #define  SFUSE_STRAP_CRT_DISABLED  (1<<6)
 #define  SFUSE_STRAP_DDIB_DETECTED (1<<2)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 2979297..634c89f 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1780,6 +1780,30 @@ void intel_update_cdclk(struct drm_i915_private 
*dev_priv)
   DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000));
 }
 
+static int cnp_rawclk(struct drm_i915_private *dev_priv)
+{
+   u32 rawclk;
+   int divider, fraction;
+
+   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
+   /* 24 MHz */
+   divider = 24000;
+   fraction = 0;
+   } else {
+   /* 19.2 MHz */
+   divider = 19000;
+   fraction = 200;
+   }
+
+   rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
+   if (fraction)
+   rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
+   fraction) - 1);
+
+   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
+   return divider + fraction;
+}
+
 static int pch_rawclk(struct drm_i915_private *dev_priv)
 {
return (I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK) * 1000;
@@ -1827,7 +1851,10 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-   if (HAS_PCH_SPLIT(dev_priv))
+
+   if (HAS_PCH_CNP(dev_priv))
+   dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
+   else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
dev_priv->rawclk_freq = vlv_hrawclk(dev_priv);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

2017-05-31 Thread kbuild test robot

Hi Andy,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.12-rc3 next-20170531]
[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-et-al-convert-to-use-new-UUID-API/20170601-072311
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: x86_64-randconfig-x018-201722 (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/acpi.h:44:0,
from drivers/usb/host/xhci-pci.c:26:
   include/acpi/acpi_bus.h:64:47: error: unknown type name 'guid_t'
bool acpi_check_dsm(acpi_handle handle, const guid_t *guid, u64 rev, u64 
funcs);
  ^~
   include/acpi/acpi_bus.h:65:64: error: unknown type name 'guid_t'
union acpi_object *acpi_evaluate_dsm(acpi_handle handle, const guid_t *guid,
   ^~
   include/acpi/acpi_bus.h:69:51: error: unknown type name 'guid_t'
acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t *guid, u64 rev,
  ^~
   drivers/usb/host/xhci-pci.c: In function 'xhci_pme_acpi_rtd3_enable':
>> drivers/usb/host/xhci-pci.c:216:15: error: unknown type name 'guid_t'
 static const guid_t intel_dsm_guid =
  ^~
>> drivers/usb/host/xhci-pci.c:217:3: error: implicit declaration of function 
>> 'GUID' [-Werror=implicit-function-declaration]
  GUID(0xac340cb7, 0xe901, 0x45bf,
  ^~~~
>> drivers/usb/host/xhci-pci.c:217:3: error: initializer element is not constant
   cc1: some warnings being treated as errors

vim +/guid_t +216 drivers/usb/host/xhci-pci.c

   210  "QUIRK: Resetting on resume");
   211  }
   212  
   213  #ifdef CONFIG_ACPI
   214  static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
   215  {
 > 216  static const guid_t intel_dsm_guid =
 > 217  GUID(0xac340cb7, 0xe901, 0x45bf,
   218   0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23);
   219  union acpi_object *obj;
   220  

---
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

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

2017-05-31 Thread kbuild test robot

Hi Andy,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.12-rc3 next-20170531]
[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-et-al-convert-to-use-new-UUID-API/20170601-072311
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: i386-randconfig-x072-05301437 (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 include/linux/acpi.h:44:0,
from drivers/usb/misc/ucsi.c:15:
   include/acpi/acpi_bus.h:64:47: error: unknown type name 'guid_t'
bool acpi_check_dsm(acpi_handle handle, const guid_t *guid, u64 rev, u64 
funcs);
  ^~
   include/acpi/acpi_bus.h:65:64: error: unknown type name 'guid_t'
union acpi_object *acpi_evaluate_dsm(acpi_handle handle, const guid_t *guid,
   ^~
   include/acpi/acpi_bus.h:69:51: error: unknown type name 'guid_t'
acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t *guid, u64 rev,
  ^~
   drivers/usb/misc/ucsi.c: In function 'ucsi_acpi_cmd':
>> drivers/usb/misc/ucsi.c:58:2: error: unknown type name 'guid_t'
 guid_t guid = GUID(0x6f8398c2, 0x7ca4, 0x11e4,
 ^~
>> drivers/usb/misc/ucsi.c:58:16: error: implicit declaration of function 
>> 'GUID' [-Werror=implicit-function-declaration]
 guid_t guid = GUID(0x6f8398c2, 0x7ca4, 0x11e4,
   ^~~~
   cc1: some warnings being treated as errors

vim +/guid_t +58 drivers/usb/misc/ucsi.c

52  #define EVENT_PENDING   0
53  #define COMMAND_PENDING 1
54  };
55  
56  static int ucsi_acpi_cmd(struct ucsi *ucsi, struct ucsi_control *ctrl)
57  {
  > 58  guid_t guid = GUID(0x6f8398c2, 0x7ca4, 0x11e4,
59 0xad, 0x36, 0x63, 0x10, 0x42, 0xb5, 0x00, 
0x8f);
60  union acpi_object *obj;
61  

---
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

Re: [Intel-gfx] [PATCH] drm/i915/cnp: add CNP gmbus support

2017-05-31 Thread kbuild test robot

Hi Rodrigo,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.12-rc3 next-20170531]
[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/Rodrigo-Vivi/drm-i915-cnp-add-CNP-gmbus-support/20170601-070244
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x014-201722 (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 error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/mod_devicetable.h:11,
from include/linux/i2c.h:29,
from drivers/gpu//drm/i915/intel_hdmi.c:29:
   drivers/gpu//drm/i915/intel_hdmi.c: In function 'intel_hdmi_ddc_pin':
>> drivers/gpu//drm/i915/intel_hdmi.c:1805:31: error: implicit declaration of 
>> function 'HAS_PCH_CNP' [-Werror=implicit-function-declaration]
  if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
  ^
   include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu//drm/i915/intel_hdmi.c:1805:3: note: in expansion of macro 'if'
  if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
  ^~
   Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
   Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
   Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
   Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large
   Cyclomatic Complexity 5 include/linux/slab.h:kmalloc
   Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
   Cyclomatic Complexity 1 
include/drm/drm_modeset_helper_vtables.h:drm_connector_helper_add
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_drv.h:to_i915
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_drv.h:intel_info
   Cyclomatic Complexity 1 
drivers/gpu//drm/i915/intel_drv.h:intel_get_crtc_for_pipe
   Cyclomatic Complexity 1 
drivers/gpu//drm/i915/intel_drv.h:intel_attached_encoder
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_drv.h:hdmi_to_dig_port
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_hdmi.c:intel_hdmi_to_dev
   Cyclomatic Complexity 1 
drivers/gpu//drm/i915/intel_hdmi.c:hsw_infoframe_enabled
   Cyclomatic Complexity 1 
drivers/gpu//drm/i915/intel_hdmi.c:hdmi_sink_is_deep_color
   Cyclomatic Complexity 12 
drivers/gpu//drm/i915/intel_hdmi.c:gcp_default_phase_possible
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_hdmi.c:vlv_enable_hdmi
   Cyclomatic Complexity 23 
drivers/gpu//drm/i915/intel_hdmi.c:hdmi_12bpc_possible
   Cyclomatic Complexity 8 
drivers/gpu//drm/i915/intel_hdmi.c:intel_hdmi_source_max_tmds_clock
   Cyclomatic Complexity 15 
drivers/gpu//drm/i915/intel_hdmi.c:hdmi_port_clock_limit
   Cyclomatic Complexity 16 
drivers/gpu//drm/i915/intel_hdmi.c:hdmi_port_clock_valid
   Cyclomatic Complexity 3 
drivers/gpu//drm/i915/intel_hdmi.c:cpt_infoframe_enabled
   Cyclomatic Complexity 9 
drivers/gpu//drm/i915/intel_hdmi.c:intel_hdmi_set_gcp_infoframe
   Cyclomatic Complexity 2 
drivers/gpu//drm/i915/intel_hdmi.c:assert_hdmi_port_disabled
   Cyclomatic Complexity 5 
drivers/gpu//drm/i915/intel_hdmi.c:g4x_infoframe_index
   Cyclomatic Complexity 5 
drivers/gpu//drm/i915/intel_hdmi.c:g4x_infoframe_enable
   Cyclomatic Complexity 6 
drivers/gpu//drm/i915/intel_hdmi.c:cpt_write_infoframe
   Cyclomatic Complexity 4 drivers/gpu//drm/i915/intel_drv.h:enc_to_dig_port
   Cyclomatic Complexity 5 
drivers/gpu//drm/i915/intel_hdmi.c:ibx_infoframe_enabled
   Cyclomatic Complexity 5 
drivers/gpu//drm/i915/intel_hdmi.c:g4x_infoframe_enabled
   Cyclomatic Complexity 5 
drivers/gpu//drm/i915/intel_hdmi.c:vlv_infoframe_enabled
   Cyclomatic Complexity 4 
drivers/gpu//drm/i915/intel_hdmi.c:ibx_write_infoframe
   Cyclomatic Complexity 5 drivers/gpu//drm/i915/intel_hdmi.c:hsw_dip_data_reg
   Cyclomatic Complexity 5 
drivers/gpu//drm/i915/intel_hdmi.c:hsw_infoframe_enable
   Cyclomatic Complexity 3 
drivers/gpu//drm/i915/intel_hdmi.c:hsw_write_infoframe
   Cyclomatic Complexity 4 
drivers/gpu//drm/i915/intel_hdmi.c:g4x_write_infoframe
   Cyclomatic Complexity 4 
drivers/gpu//drm/i915/intel_hdmi.c:vlv_write_infoframe
   Cyclomatic Complexity 3 
drivers/gpu//drm/i915/intel_hdmi.c:intel_hdmi_get_modes
   Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_hdmi.c:intel_hdmi_destroy
   Cyclomatic Complexity 1

Re: [Intel-gfx] [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API

2017-05-31 Thread kbuild test robot

Hi Andy,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.12-rc3 next-20170531]
[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-et-al-convert-to-use-new-UUID-API/20170601-072311
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: x86_64-randconfig-x019-201722 (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 >>):

   drivers/acpi/bus.c: In function 'acpi_run_osc':
>> drivers/acpi/bus.c:228:2: error: unknown type name 'guid_t'
 guid_t guid;
 ^~
>> drivers/acpi/bus.c:234:6: error: implicit declaration of function 
>> 'guid_parse' [-Werror=implicit-function-declaration]
 if (guid_parse(context->uuid_str, ))
 ^~
   cc1: some warnings being treated as errors

vim +/guid_t +228 drivers/acpi/bus.c

   222  acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context 
*context)
   223  {
   224  acpi_status status;
   225  struct acpi_object_list input;
   226  union acpi_object in_params[4];
   227  union acpi_object *out_obj;
 > 228  guid_t guid;
   229  u32 errors;
   230  struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
   231  
   232  if (!context)
   233  return AE_ERROR;
 > 234  if (guid_parse(context->uuid_str, ))
   235  return AE_ERROR;
   236  context->ret.length = ACPI_ALLOCATE_BUFFER;
   237  context->ret.pointer = NULL;

---
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

Re: [Intel-gfx] [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API

2017-05-31 Thread kbuild test robot

Hi Andy,

[auto build test WARNING on pm/linux-next]
[also build test WARNING on v4.12-rc3 next-20170531]
[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-et-al-convert-to-use-new-UUID-API/20170601-072311
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: x86_64-randconfig-x010-201722 (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 warnings (new ones prefixed by >>):

   drivers/acpi/bus.c: In function 'acpi_run_osc':
   drivers/acpi/bus.c:228:2: error: unknown type name 'guid_t'
 guid_t guid;
 ^~
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from drivers/acpi/bus.c:21:
   drivers/acpi/bus.c:234:6: error: implicit declaration of function 
'guid_parse' [-Werror=implicit-function-declaration]
 if (guid_parse(context->uuid_str, ))
 ^
   include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/acpi/bus.c:234:2: note: in expansion of macro 'if'
 if (guid_parse(context->uuid_str, ))
 ^~
   cc1: some warnings being treated as errors

vim +/if +234 drivers/acpi/bus.c

   218  return AE_OK;
   219  }
   220  EXPORT_SYMBOL_GPL(acpi_str_to_uuid);
   221  
   222  acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context 
*context)
   223  {
   224  acpi_status status;
   225  struct acpi_object_list input;
   226  union acpi_object in_params[4];
   227  union acpi_object *out_obj;
   228  guid_t guid;
   229  u32 errors;
   230  struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
   231  
   232  if (!context)
   233  return AE_ERROR;
 > 234  if (guid_parse(context->uuid_str, ))
   235  return AE_ERROR;
   236  context->ret.length = ACPI_ALLOCATE_BUFFER;
   237  context->ret.pointer = NULL;
   238  
   239  /* Setting up input parameters */
   240  input.count = 4;
   241  input.pointer = in_params;
   242  in_params[0].type   = ACPI_TYPE_BUFFER;

---
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

Re: [Intel-gfx] [PATCH v2 2/5] ACPI / APEI: Switch to use new generic UUID API

2017-05-31 Thread kbuild test robot

Hi Andy,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.12-rc3 next-20170531]
[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-et-al-convert-to-use-new-UUID-API/20170601-072311
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: x86_64-randconfig-x013-201722 (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 >>):

   drivers/acpi/apei/ghes.c: In function 'ghes_do_proc':
>> drivers/acpi/apei/ghes.c:434:2: error: unknown type name 'guid_t'
 guid_t *sec_type;
 ^~
>> drivers/acpi/apei/ghes.c:438:15: error: 'guid_t' undeclared (first use in 
>> this function)
  sec_type = (guid_t *)gdata->section_type;
  ^~
   drivers/acpi/apei/ghes.c:438:15: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/acpi/apei/ghes.c:438:23: error: expected expression before ')' token
  sec_type = (guid_t *)gdata->section_type;
  ^
>> drivers/acpi/apei/ghes.c:440:8: error: implicit declaration of function 
>> 'guid_equal' [-Werror=implicit-function-declaration]
  if (!guid_equal(sec_type, _SEC_PLATFORM_MEM)) {
   ^~
   cc1: some warnings being treated as errors

vim +/guid_t +434 drivers/acpi/apei/ghes.c

   428  
   429  static void ghes_do_proc(struct ghes *ghes,
   430   const struct acpi_hest_generic_status *estatus)
   431  {
   432  int sev, sec_sev;
   433  struct acpi_hest_generic_data *gdata;
 > 434  guid_t *sec_type;
   435  
   436  sev = ghes_severity(estatus->error_severity);
   437  apei_estatus_for_each_section(estatus, gdata) {
 > 438  sec_type = (guid_t *)gdata->section_type;
   439  sec_sev = ghes_severity(gdata->error_severity);
 > 440  if (!guid_equal(sec_type, _SEC_PLATFORM_MEM)) {
   441  struct cper_sec_mem_err *mem_err;
   442  mem_err = (struct cper_sec_mem_err *)(gdata+1);
   443  ghes_edac_report_mem_error(ghes, sev, mem_err);

---
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

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread Pandiyan, Dhinakaran

On Wed, 2017-05-31 at 23:46 +, Vivi, Rodrigo wrote:
> On Wed, 2017-05-31 at 23:07 +, Pandiyan, Dhinakaran wrote:
> > On Wed, 2017-05-31 at 14:54 -0700, Rodrigo Vivi wrote:
> > > As for BXT, PP_DIVISOR was removed from CNP PCH and power
> > > cycle delay has been moved to PP_CONTROL.
> > > 
> > > v2: Add missed pp_div write, that is now part of PP_CONTROL[8:4]
> > > as on Broxton. (Found by DK)
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Jani Nikula 
> > > Signed-off-by: Rodrigo Vivi 
> > 
> > I believe I've covered all instances of IS_GEN9_LP in PPS related code
> > and I've verified changes against BSpec. So,
> > Reviewed-by: Dhinakaran Pandiyan 
> 
> Thanks
> 
> > 
> > I would've preferred if you mentioned somewhere that this is similar to
> > BXT except for having just one instance of PPS.
> 
> I can improve the commit message with:
> 
> Panel Power sequences for CNP is similar to Broxton, but with only one
> sequencer.
> 
> Main difference from SPT is that PP_DIVISOR was removed and power cycle
> delay has been moved to PP_CONTROL.
> 

Sounds good!

> > 
> > -DK
> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 12 ++--
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 58dca87..db51338 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct 
> > > drm_i915_private *dev_priv,
> > >   regs->pp_stat = PP_STATUS(pps_idx);
> > >   regs->pp_on = PP_ON_DELAYS(pps_idx);
> > >   regs->pp_off = PP_OFF_DELAYS(pps_idx);
> > > - if (!IS_GEN9_LP(dev_priv))
> > > + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
> > >   regs->pp_div = PP_DIVISOR(pps_idx);
> > >  }
> > >  
> > > @@ -5099,7 +5099,7 @@ static void 
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > >  
> > >   pp_on = I915_READ(regs.pp_on);
> > >   pp_off = I915_READ(regs.pp_off);
> > > - if (!IS_GEN9_LP(dev_priv)) {
> > > + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
> > >   I915_WRITE(regs.pp_ctrl, pp_ctl);
> > >   pp_div = I915_READ(regs.pp_div);
> > >   }
> > > @@ -5117,7 +5117,7 @@ static void 
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > >   seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
> > >  PANEL_POWER_DOWN_DELAY_SHIFT;
> > >  
> > > - if (IS_GEN9_LP(dev_priv)) {
> > > + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> > >   u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
> > >   BXT_POWER_CYCLE_DELAY_SHIFT;
> > >   if (tmp > 0)
> > > @@ -5274,7 +5274,7 @@ static void 
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > >(seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
> > >   /* Compute the divisor for the pp clock, simply match the Bspec
> > >* formula. */
> > > - if (IS_GEN9_LP(dev_priv)) {
> > > + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> > >   pp_div = I915_READ(regs.pp_ctrl);
> > >   pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
> > >   pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
> > > @@ -5300,7 +5300,7 @@ static void 
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > >  
> > >   I915_WRITE(regs.pp_on, pp_on);
> > >   I915_WRITE(regs.pp_off, pp_off);
> > > - if (IS_GEN9_LP(dev_priv))
> > > + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
> > >   I915_WRITE(regs.pp_ctrl, pp_div);
> > >   else
> > >   I915_WRITE(regs.pp_div, pp_div);
> > > @@ -5308,7 +5308,7 @@ static void 
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > >   DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
> > > PP_OFF %#x, PP_DIV %#x\n",
> > > I915_READ(regs.pp_on),
> > > I915_READ(regs.pp_off),
> > > -   IS_GEN9_LP(dev_priv) ?
> > > +   (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
> > > (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
> > > I915_READ(regs.pp_div));
> > >  }
> > 
> 

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

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread Vivi, Rodrigo

On Wed, 2017-05-31 at 23:07 +, Pandiyan, Dhinakaran wrote:
> On Wed, 2017-05-31 at 14:54 -0700, Rodrigo Vivi wrote:
> > As for BXT, PP_DIVISOR was removed from CNP PCH and power
> > cycle delay has been moved to PP_CONTROL.
> > 
> > v2: Add missed pp_div write, that is now part of PP_CONTROL[8:4]
> > as on Broxton. (Found by DK)
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Jani Nikula 
> > Signed-off-by: Rodrigo Vivi 
> 
> I believe I've covered all instances of IS_GEN9_LP in PPS related code
> and I've verified changes against BSpec. So,
> Reviewed-by: Dhinakaran Pandiyan 

Thanks

> 
> I would've preferred if you mentioned somewhere that this is similar to
> BXT except for having just one instance of PPS.

I can improve the commit message with:

Panel Power sequences for CNP is similar to Broxton, but with only one
sequencer.

Main difference from SPT is that PP_DIVISOR was removed and power cycle
delay has been moved to PP_CONTROL.

> 
> -DK
> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 58dca87..db51338 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct 
> > drm_i915_private *dev_priv,
> > regs->pp_stat = PP_STATUS(pps_idx);
> > regs->pp_on = PP_ON_DELAYS(pps_idx);
> > regs->pp_off = PP_OFF_DELAYS(pps_idx);
> > -   if (!IS_GEN9_LP(dev_priv))
> > +   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
> > regs->pp_div = PP_DIVISOR(pps_idx);
> >  }
> >  
> > @@ -5099,7 +5099,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> >  
> > pp_on = I915_READ(regs.pp_on);
> > pp_off = I915_READ(regs.pp_off);
> > -   if (!IS_GEN9_LP(dev_priv)) {
> > +   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
> > I915_WRITE(regs.pp_ctrl, pp_ctl);
> > pp_div = I915_READ(regs.pp_div);
> > }
> > @@ -5117,7 +5117,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
> >PANEL_POWER_DOWN_DELAY_SHIFT;
> >  
> > -   if (IS_GEN9_LP(dev_priv)) {
> > +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> > u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
> > BXT_POWER_CYCLE_DELAY_SHIFT;
> > if (tmp > 0)
> > @@ -5274,7 +5274,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> >  (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
> > /* Compute the divisor for the pp clock, simply match the Bspec
> >  * formula. */
> > -   if (IS_GEN9_LP(dev_priv)) {
> > +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> > pp_div = I915_READ(regs.pp_ctrl);
> > pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
> > pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
> > @@ -5300,7 +5300,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> >  
> > I915_WRITE(regs.pp_on, pp_on);
> > I915_WRITE(regs.pp_off, pp_off);
> > -   if (IS_GEN9_LP(dev_priv))
> > +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
> > I915_WRITE(regs.pp_ctrl, pp_div);
> > else
> > I915_WRITE(regs.pp_div, pp_div);
> > @@ -5308,7 +5308,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
> > PP_OFF %#x, PP_DIV %#x\n",
> >   I915_READ(regs.pp_on),
> >   I915_READ(regs.pp_off),
> > - IS_GEN9_LP(dev_priv) ?
> > + (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
> >   (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
> >   I915_READ(regs.pp_div));
> >  }
> 

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

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread Pandiyan, Dhinakaran

On Wed, 2017-05-31 at 14:54 -0700, Rodrigo Vivi wrote:
> As for BXT, PP_DIVISOR was removed from CNP PCH and power
> cycle delay has been moved to PP_CONTROL.
> 
> v2: Add missed pp_div write, that is now part of PP_CONTROL[8:4]
> as on Broxton. (Found by DK)
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 

I believe I've covered all instances of IS_GEN9_LP in PPS related code
and I've verified changes against BSpec. So,
Reviewed-by: Dhinakaran Pandiyan 

I would've preferred if you mentioned somewhere that this is similar to
BXT except for having just one instance of PPS.

-DK

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 58dca87..db51338 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct 
> drm_i915_private *dev_priv,
>   regs->pp_stat = PP_STATUS(pps_idx);
>   regs->pp_on = PP_ON_DELAYS(pps_idx);
>   regs->pp_off = PP_OFF_DELAYS(pps_idx);
> - if (!IS_GEN9_LP(dev_priv))
> + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
>   regs->pp_div = PP_DIVISOR(pps_idx);
>  }
>  
> @@ -5099,7 +5099,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>  
>   pp_on = I915_READ(regs.pp_on);
>   pp_off = I915_READ(regs.pp_off);
> - if (!IS_GEN9_LP(dev_priv)) {
> + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
>   I915_WRITE(regs.pp_ctrl, pp_ctl);
>   pp_div = I915_READ(regs.pp_div);
>   }
> @@ -5117,7 +5117,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>   seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
>  PANEL_POWER_DOWN_DELAY_SHIFT;
>  
> - if (IS_GEN9_LP(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
>   u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
>   BXT_POWER_CYCLE_DELAY_SHIFT;
>   if (tmp > 0)
> @@ -5274,7 +5274,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>(seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
>   /* Compute the divisor for the pp clock, simply match the Bspec
>* formula. */
> - if (IS_GEN9_LP(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
>   pp_div = I915_READ(regs.pp_ctrl);
>   pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
>   pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
> @@ -5300,7 +5300,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>  
>   I915_WRITE(regs.pp_on, pp_on);
>   I915_WRITE(regs.pp_off, pp_off);
> - if (IS_GEN9_LP(dev_priv))
> + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
>   I915_WRITE(regs.pp_ctrl, pp_div);
>   else
>   I915_WRITE(regs.pp_div, pp_div);
> @@ -5308,7 +5308,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>   DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
> PP_OFF %#x, PP_DIV %#x\n",
> I915_READ(regs.pp_on),
> I915_READ(regs.pp_off),
> -   IS_GEN9_LP(dev_priv) ?
> +   (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
> (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
> I915_READ(regs.pp_div));
>  }

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

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

2017-05-31 Thread Rafael J. Wysocki

On Wednesday, May 31, 2017 10:41:52 PM Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use guid_t 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.

Acked-by: Rafael J. Wysocki 

with one caveat.

I have a pending patch that will use acpi_evaluate_dsm(), so I'd like this to
be made available in an immutable branch once applied.

Thanks,
Rafael

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

Re: [Intel-gfx] [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API

2017-05-31 Thread Rafael J. Wysocki

On Wednesday, May 31, 2017 10:41:50 PM Andy Shevchenko wrote:
> There are new types and helpers that are supposed to be used in new code.
> 
> As a preparation to get rid of legacy types and API functions do
> the conversion here.
> 
> Signed-off-by: Andy Shevchenko 

Acked-by: Rafael J. Wysocki 

Thanks,
Rafael

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/skl: New ddb allocation algorithm

2017-05-31 Thread Matt Roper

On Fri, May 26, 2017 at 08:45:45PM +0530, Mahesh Kumar wrote:
> This patch implements new DDB allocation algorithm as per HW team
> recommendation. This algo takecare of scenario where we allocate less DDB
> for the planes with lower relative pixel rate, but they require more DDB
> to work.
> It also takes care of enabling same watermark level for each
> plane in crtc, for efficient power saving.
> 
> Changes since v1:
>  - Rebase on top of Paulo's patch series
> 
> Changes since v2:
>  - Fix the for loop condition to enable WM
> 
> Changes since v3:
>  - Fix crash in cursor i-g-t reported by Maarten
>  - Rebase after addressing Paulo's comments
>  - Few other ULT fixes
> Changes since v4:
>  - Rebase on drm-tip
>  - Added separate function to enable WM levels
> Changes since v5:
>  - Fix a crash identified in skl-6770HQ system
> Changes since v6:
>  - Address review comments from Matt
> Changes since v7:
>  - Fix failure return in skl_compute_plane_wm (Matt)
>  - fix typo
> Changes since v8:
>  - Always check cursor wm enable irrespective of total_data_rate
> 
> Signed-off-by: Mahesh Kumar 
> Reviewed-by: Maarten Lankhorst 
> ---
...
> @@ -4114,13 +4183,24 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   total_data_rate = skl_get_total_relative_data_rate(cstate,
>  plane_data_rate,
>  plane_y_data_rate);
> + /*
> +  * PLANE_CURSOR data rate is not included in total_data_rate.
> +  * If, only cursor plane is enabled we have to enable it's WM

A couple minor typo's here.  You probably don't want the comma after
"If," and the "it's" at the end of the line should be "its."

With those fixed,

Reviewed-by: Matt Roper 


> +  * levels explicitly before returning. Cursor has fixed ddb allocation,
> +  * So it's ok to always check cursor WM enabling before return.
> +  */
> + plane_blocks = skl_ddb_entry_size(>plane[pipe][PLANE_CURSOR]);
> + skl_enable_plane_wm_levels(dev_priv, plane_blocks, max_level,
> +_wm->planes[PLANE_CURSOR]);
>   if (total_data_rate == 0)
>   return 0;
>  
>   start = alloc->start;
>   for_each_plane_id_on_crtc(intel_crtc, plane_id) {
>   unsigned int data_rate, y_data_rate;
> - uint16_t plane_blocks, y_plane_blocks = 0;
> + uint16_t plane_blocks = 0, y_plane_blocks = 0;
> + struct skl_plane_wm *wm = _wm->planes[plane_id];
> + uint16_t plane_res_b = wm->wm[max_level].plane_res_b;
>  
>   if (plane_id == PLANE_CURSOR)
>   continue;
...

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/13] drm/i915/cnp: Introduce Cannonpoint PCH. (rev3)

2017-05-31 Thread Patchwork

== Series Details ==

Series: series starting with [01/13] drm/i915/cnp: Introduce Cannonpoint PCH. 
(rev3)
URL   : https://patchwork.freedesktop.org/series/25070/
State : success

== Summary ==

Series 25070v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25070/revisions/3/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:442s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:430s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:573s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:437s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:587s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:465s
fi-skl-6700hqtotal:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  
time:428s
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:499s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:438s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:549s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:409s

593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC 
integration manifest
44b9c8d drm/i915/cfl: Coffe Lake reuses Kabylake DMC.
c27cae8 drm/i915/cfl: Introduce Coffee Lake workardounds.
cc122a6 drm/i915/cfl: Add CFL PCI IDs for U SKU
d6d7f7a drm/i915/cfl: Add Coffee Lake PCI IDs for H and S Skus.
3c73119 drm/i915/cfl: Basic PM plumbing for Coffee Lake.
7f55a8d drm/i915/cfl: Coffee Lake uses CNP PCH.
ca5cc1d drm/i915/cfl: Introduce Coffee Lake platform definition.
2413280 drm/i915/cnp: Panel Power sequence changes for CNP PCH.
5983e52 drm/i915/cnp: add CNP gmbus support
0a5a491 drm/i915/cnp: Backlight support for CNP.
8254669 drm/i915/cnp: Get/set proper Raw clock frequency on CNP.
78728ef drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH
657bcfc drm/i915/cnp: Introduce Cannonpoint PCH.

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.

2017-05-31 Thread Matt Roper

On Wed, May 31, 2017 at 05:42:36PM +0200, Maarten Lankhorst wrote:
> On some systems there can be a race condition in which no crtc state is
> added to the first atomic commit. This results in all crtc's having a
> null DDB allocation, causing a FIFO underrun on any update until the
> first modeset.
> 
> Changes since v1:
> - Do not take the connection_mutex, this is already done below.
> 
> Reported-by: Maarten Lankhorst 
> Inspired-by: Mahesh Kumar 
> Signed-off-by: Maarten Lankhorst 
> Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
> check time (v4)")
> Cc:  # v4.8+
> Cc: Mahesh Kumar 
> Cc: Matt Roper 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 936eef1634c7..fce4bc5ccc99 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4819,11 +4819,19 @@ skl_compute_wm(struct drm_atomic_state *state)
>   struct drm_crtc_state *cstate;
>   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>   struct skl_wm_values *results = _state->wm_results;
> + struct drm_device *dev = state->dev;
>   struct skl_pipe_wm *pipe_wm;
>   bool changed = false;
>   int ret, i;
>  
>   /*
> +  * When we distrust bios wm we always need to recompute to set the
> +  * expected DDB allocations for each CRTC.
> +  */
> + if (to_i915(dev)->wm.distrust_bios_wm)
> + changed = true;
> +
> + /*
>* If this transaction isn't actually touching any CRTC's, don't
>* bother with watermark calculation.  Note that if we pass this
>* test, we're guaranteed to hold at least one CRTC state mutex,
> @@ -4833,6 +4841,7 @@ skl_compute_wm(struct drm_atomic_state *state)
>*/
>   for_each_new_crtc_in_state(state, crtc, cstate, i)
>   changed = true;
> +
>   if (!changed)
>   return 0;
>  
> -- 
> 2.11.0
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread Rodrigo Vivi

As for BXT, PP_DIVISOR was removed from CNP PCH and power
cycle delay has been moved to PP_CONTROL.

v2: Add missed pp_div write, that is now part of PP_CONTROL[8:4]
as on Broxton. (Found by DK)

Cc: Dhinakaran Pandiyan 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 58dca87..db51338 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct drm_i915_private 
*dev_priv,
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
regs->pp_off = PP_OFF_DELAYS(pps_idx);
-   if (!IS_GEN9_LP(dev_priv))
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
regs->pp_div = PP_DIVISOR(pps_idx);
 }
 
@@ -5099,7 +5099,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 
pp_on = I915_READ(regs.pp_on);
pp_off = I915_READ(regs.pp_off);
-   if (!IS_GEN9_LP(dev_priv)) {
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
I915_WRITE(regs.pp_ctrl, pp_ctl);
pp_div = I915_READ(regs.pp_div);
}
@@ -5117,7 +5117,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
   PANEL_POWER_DOWN_DELAY_SHIFT;
 
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
BXT_POWER_CYCLE_DELAY_SHIFT;
if (tmp > 0)
@@ -5274,7 +5274,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
/* Compute the divisor for the pp clock, simply match the Bspec
 * formula. */
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
pp_div = I915_READ(regs.pp_ctrl);
pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
@@ -5300,7 +5300,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 
I915_WRITE(regs.pp_on, pp_on);
I915_WRITE(regs.pp_off, pp_off);
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
I915_WRITE(regs.pp_ctrl, pp_div);
else
I915_WRITE(regs.pp_div, pp_div);
@@ -5308,7 +5308,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
PP_OFF %#x, PP_DIV %#x\n",
  I915_READ(regs.pp_on),
  I915_READ(regs.pp_off),
- IS_GEN9_LP(dev_priv) ?
+ (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
  (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
  I915_READ(regs.pp_div));
 }
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v10 2/3] drm/i915: Add option to support dynamic backlight via DPCD

2017-05-31 Thread Pandiyan, Dhinakaran

On Wed, 2017-05-31 at 14:37 -0700, Puthikorn Voravootivat wrote:
> 
> 
> On Tue, May 30, 2017 at 9:18 PM, Pandiyan, Dhinakaran
>  wrote:
> On Fri, 2017-05-26 at 18:42 -0700, Puthikorn Voravootivat
> wrote:
> > This patch adds option to enable dynamic backlight for eDP
> > panel that supports this feature via DPCD register and
> > set minimum / maximum brightness to 0% and 100% of the
> > normal brightness.
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c|  5 
> >  drivers/gpu/drm/i915/i915_params.h|  3 +-
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 42
> ++-
> >  3 files changed, 41 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> > index 3758ae1f11b4..ce033d58134e 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
> >   .inject_load_failure = 0,
> >   .enable_dpcd_backlight = -1,
> >   .enable_gvt = false,
> > + .enable_dbc = false,
> 
> Based on Daniel's earlier comments on module parameters,
> shouldn't this
> be enabled by default too?
> 
> 
> Yes. Will do.
>  
> 
> Or even more importantly, is this the right approach to
> enable/disable
> dynamic back light control? The reason I recommended having
> some sort of
> control to disable/enable is that the eDP spec. says the
> feature can
> have user visible impact.
> 
> 
> I don't think we should expect end user to set this correctly. For
> power user,
> I think the i915_params is adequate. I don't want to add more
> complication
> to the driver.
>  

Sure, I am not requesting any changes here :) I meant to address the
question to Daniel in case he had any feedback.

-DK
> 
> Table 10-3  Display Control Capabilities
> 
> "While the DBC control bit’s function is defined in this
> Standard, DBC implementation specifics are not defined,
> including
> interaction with other DPCD register settings. The DBC
> implementation,
> visual performance, and power savings characteristics can
> differ between
> specific panels."
> 
> -DK
> 
> >  };
> >
> >  module_param_named(modeset, i915.modeset, int, 0400);
> > @@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> >  module_param_named(enable_gvt, i915.enable_gvt, bool,
> 0400);
> >  MODULE_PARM_DESC(enable_gvt,
> >   "Enable support for Intel GVT-g graphics
> virtualization host support(default:false)");
> > +
> > +module_param_named_unsafe(enable_dbc, i915.enable_dbc,
> bool, 0600);
> > +MODULE_PARM_DESC(enable_dbc,
> > + "Enable support for dynamic backlight control
> (default:false)");
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> > index ac02efce6e22..2de3e2850b54 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -67,7 +67,8 @@
> >   func(bool, nuclear_pageflip); \
> >   func(bool, enable_dp_mst); \
> >   func(int, enable_dpcd_backlight); \
> > - func(bool, enable_gvt)
> > + func(bool, enable_gvt); \
> > + func(bool, enable_dbc)
> >
> >  #define MEMBER(T, member) T member
> >  struct i915_params {
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index c89aae804659..f55af41ce3bd 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -100,11 +100,26 @@ intel_dp_aux_set_backlight(struct
> intel_connector *connector, u32 level)
> >   }
> >  }
> >
> > +/*
> > + * Set minimum / maximum dynamic brightness percentage.
> This value is expressed
> > + * as the percentage of normal brightness in 5% increments.
> > + */
> > +static void
> > +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp
> *intel_dp,
> > +u32 min, u32 max)
> > +{
> > + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5),
> DIV_ROUND_CLOSEST(max, 5) };
> > +
>

Re: [Intel-gfx] [PATCH v10 3/3] drm/i915: Set PWM divider to match desired frequency in vbt

2017-05-31 Thread Puthikorn Voravootivat

On Tue, May 30, 2017 at 8:40 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> The patch looks good overall, it would have been easier to merge if
> you'd sent this as the first patch in this version. Some comments
> inline.
>
>
> Will re-order to make this the first patch in the next version.

>
> On Fri, 2017-05-26 at 18:42 -0700, Puthikorn Voravootivat wrote:
> > Read desired PWM frequency from panel vbt and calculate the
> > value for divider in DPCD address 0x724 and 0x728 to have
> > as many bits as possible for PWM duty cyle for granularity of
> > brightness adjustment while the frequency divisor is still
> > within 25% of the desired value.
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 79
> +++
> >  1 file changed, 79 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index f55af41ce3bd..a8d485a29f29 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -116,6 +116,81 @@ intel_dp_aux_set_dynamic_backlight_percent(struct
> intel_dp *intel_dp,
> >   }
> >  }
> >
> > +/*
> > + * Set PWM Frequency divider to match desired frequency in vbt.
> > + * The PWM Frequency is calculated as 27Mhz / (F x P).
> > + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0
> of the
> > + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> > + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of
> the
> > + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> > + */
> > +static int intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_dp *intel_dp = enc_to_intel_dp(>
> encoder->base);
> > + int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
>
> nit: unnecessary initialization for f?
>
No. We only set f in for (pn = pn_max; pn >= pn_min; pn--) but compiler
wouldn't
know that pn_max  >= pn_min so f might be uninitialized.


> > + u8 pn, pn_min, pn_max;
> > +
> > + /* Find desired value of (F x P)
> > +  * Note that, if F x P is out of supported range, the maximum
> value or
> > +  * minimum value will applied automatically. So no need to check
> that.
> > +  */
> > + freq = dev_priv->vbt.backlight.pwm_freq_hz;
> > + DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
> > + if (!freq) {
> > + DRM_DEBUG_KMS("Use panel default backlight frequency\n");
> > + return -1;
> > + }
> > +
> > + fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ),
> freq);
> > +
> > + /* Use highest possible value of Pn for more granularity of
> brightness
> > +  * adjustment while satifying the conditions below.
> > +  * - Pn is in the range of Pn_min and Pn_max
> > +  * - F is in the range of 1 and 255
> > +  * - FxP is within 25% of desired value.
> > +  *   Note: 25% is arbitrary value and may need some tweak.
> > +  */
> > + if (drm_dp_dpcd_readb(_dp->aux,
> > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min)
> != 1) {
> > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
> > + return -EIO;
>
> The error numbers are not propagated outside, so I don't see a real need
> for them. bool should suffice.
>
> Sure.

>
> > + }
> > + if (drm_dp_dpcd_readb(_dp->aux,
> > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max)
> != 1) {
> > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
> > + return -EIO;
> > + }
> > + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> > + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> > +
> > + fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
> > + fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
> > + if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
> > + DRM_DEBUG_KMS("VBT defined backlight frequency out of
> range\n");
> > + return -ERANGE;
> > + }
> > +
> > + for (pn = pn_max; pn >= pn_min; pn--) {
> > + f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
> > + fxp_actual = f << pn;
> > + if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
> > + break;
> > + }
> > +
> > + if (drm_dp_dpcd_writeb(_dp->aux,
> > +DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
> > + DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
> > + return -EIO;
> > + }
> > + if (drm_dp_dpcd_writeb(_dp->aux,
> > +DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
> > + return -EIO;
> > + }
> > + return

Re: [Intel-gfx] [PATCH 06/13] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread Vivi, Rodrigo

On Wed, 2017-05-31 at 21:08 +, Pandiyan, Dhinakaran wrote:
> On Tue, 2017-05-30 at 15:42 -0700, Rodrigo Vivi wrote:
> > As for BXT, PP_DIVISOR was removed from CNP PCH and power
> > cycle delay has been moved to PP_CONTROL.
> > 
> > Cc: Jani Nikula 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 58dca87..1a27c72 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct 
> > drm_i915_private *dev_priv,
> > regs->pp_stat = PP_STATUS(pps_idx);
> 
> We get the PPS index for BXT from bxt_power_sequencer_idx(), but I don't
> see that in this patch for CNP PCH. Does that mean CNP has just one
> power sequencer? 

exactly, only one power sequencer for CNP.

> 
> 
> > regs->pp_on = PP_ON_DELAYS(pps_idx);
> > regs->pp_off = PP_OFF_DELAYS(pps_idx);
> > -   if (!IS_GEN9_LP(dev_priv))
> > +   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
> > regs->pp_div = PP_DIVISOR(pps_idx);
> >  }
> >  
> > @@ -5099,7 +5099,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> >  
> > pp_on = I915_READ(regs.pp_on);
> > pp_off = I915_READ(regs.pp_off);
> > -   if (!IS_GEN9_LP(dev_priv)) {
> > +   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
> > I915_WRITE(regs.pp_ctrl, pp_ctl);
> > pp_div = I915_READ(regs.pp_div);
> > }
> > @@ -5117,7 +5117,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
> >PANEL_POWER_DOWN_DELAY_SHIFT;
> >  
> > -   if (IS_GEN9_LP(dev_priv)) {
> > +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> > u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
> > BXT_POWER_CYCLE_DELAY_SHIFT;
> > if (tmp > 0)
> > @@ -5274,7 +5274,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> >  (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
> > /* Compute the divisor for the pp clock, simply match the Bspec
> >  * formula. */
> > -   if (IS_GEN9_LP(dev_priv)) {
> > +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> > pp_div = I915_READ(regs.pp_ctrl);
> > pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
> > pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
> 
> 
> I am not seeing the I915_WRITE for pp_div.

good catch!
so far we have reusing what BIOS had left there...
Sending a new version...

> 
> 
> > @@ -5308,7 +5308,7 @@ static void 
> > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
> > PP_OFF %#x, PP_DIV %#x\n",
> >   I915_READ(regs.pp_on),
> >   I915_READ(regs.pp_off),
> > - IS_GEN9_LP(dev_priv) ?
> > + (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
> >   (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
> >   I915_READ(regs.pp_div));
> >  }
> 

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

Re: [Intel-gfx] [PATCH v10 2/3] drm/i915: Add option to support dynamic backlight via DPCD

2017-05-31 Thread Puthikorn Voravootivat

On Tue, May 30, 2017 at 9:18 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Fri, 2017-05-26 at 18:42 -0700, Puthikorn Voravootivat wrote:
> > This patch adds option to enable dynamic backlight for eDP
> > panel that supports this feature via DPCD register and
> > set minimum / maximum brightness to 0% and 100% of the
> > normal brightness.
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c|  5 
> >  drivers/gpu/drm/i915/i915_params.h|  3 +-
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 42
> ++-
> >  3 files changed, 41 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> > index 3758ae1f11b4..ce033d58134e 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
> >   .inject_load_failure = 0,
> >   .enable_dpcd_backlight = -1,
> >   .enable_gvt = false,
> > + .enable_dbc = false,
>
> Based on Daniel's earlier comments on module parameters, shouldn't this
> be enabled by default too?
>

Yes. Will do.


>
> Or even more importantly, is this the right approach to enable/disable
> dynamic back light control? The reason I recommended having some sort of
> control to disable/enable is that the eDP spec. says the feature can
> have user visible impact.
>

I don't think we should expect end user to set this correctly. For power
user,
I think the i915_params is adequate. I don't want to add more complication
to the driver.


>
> Table 10-3  Display Control Capabilities
>
> "While the DBC control bit’s function is defined in this
> Standard, DBC implementation specifics are not defined, including
> interaction with other DPCD register settings. The DBC implementation,
> visual performance, and power savings characteristics can differ between
> specific panels."
>
> -DK
>
> >  };
> >
> >  module_param_named(modeset, i915.modeset, int, 0400);
> > @@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> >  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> >  MODULE_PARM_DESC(enable_gvt,
> >   "Enable support for Intel GVT-g graphics virtualization host
> support(default:false)");
> > +
> > +module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
> > +MODULE_PARM_DESC(enable_dbc,
> > + "Enable support for dynamic backlight control (default:false)");
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> > index ac02efce6e22..2de3e2850b54 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -67,7 +67,8 @@
> >   func(bool, nuclear_pageflip); \
> >   func(bool, enable_dp_mst); \
> >   func(int, enable_dpcd_backlight); \
> > - func(bool, enable_gvt)
> > + func(bool, enable_gvt); \
> > + func(bool, enable_dbc)
> >
> >  #define MEMBER(T, member) T member
> >  struct i915_params {
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index c89aae804659..f55af41ce3bd 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -100,11 +100,26 @@ intel_dp_aux_set_backlight(struct intel_connector
> *connector, u32 level)
> >   }
> >  }
> >
> > +/*
> > + * Set minimum / maximum dynamic brightness percentage. This value is
> expressed
> > + * as the percentage of normal brightness in 5% increments.
> > + */
> > +static void
> > +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> > +u32 min, u32 max)
> > +{
> > + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5)
> };
> > +
> > + if (drm_dp_dpcd_write(_dp->aux,
> DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> > +   dbc, sizeof(dbc)) < 0) {
> > + DRM_DEBUG_KMS("Failed to write aux DBC brightness
> level\n");
> > + }
> > +}
> > +
> >  static void intel_dp_aux_enable_backlight(struct intel_connector
> *connector)
> >  {
> >   struct intel_dp *intel_dp = enc_to_intel_dp(>
> encoder->base);
> > - uint8_t dpcd_buf = 0;
> > - uint8_t edp_backlight_mode = 0;
> > + uint8_t dpcd_buf, new_dpcd_buf, edp_backlight_mode;
> >
> >   if (drm_dp_dpcd_readb(_dp->aux,
> >   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) !=
> 1) {
> > @@ -113,18 +128,15 @@ static void intel_dp_aux_enable_backlight(struct
> intel_connector *connector)
> >   return;
> >   }
> >
> > + new_dpcd_buf = dpcd_buf;
> >   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_
> MASK;
> >
> >   switch (edp_backlight_mode) {
> >   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> >   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> >   case

Re: [Intel-gfx] [PATCH] drm/i915/cnp: add CNP gmbus support

2017-05-31 Thread Srivatsa, Anusha



>-Original Message-
>From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
>Sent: Wednesday, May 31, 2017 11:29 AM
>To: Vivi, Rodrigo ; Srivatsa, Anusha
>
>Cc: intel-gfx ; Nikula, Jani
>; Vetter, Daniel 
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/cnp: add CNP gmbus support
>
>Anusha, when going to merge I noticed that we had the wrong version here.
>
>The incorrect version would break hdmi on CFL. The right workaround is not to
>respect the CNL bios for the pin number.
>
>So, I hope I can keep your rv-b on this one, but I'd like you to confirm 
>please.

Looked into the spec again. You are right, mapping has to be changed.

Anusha 

>Thanks,
>Rodrigo.
>
>On Wed, May 31, 2017 at 11:26 AM, Rodrigo Vivi 
>wrote:
>> On CNP PCH based platforms the gmbus is on the south display that is
>> on PCH. The existing implementation for previous platforms already
>> covers the need for CNP expect for the pin pair configuration that
>> follows similar definitions that we had on BXT.
>>
>> v2: Don't drop "_BXT" as the indicator of the first platform
>> supporting this pin numbers. Suggested by Daniel.
>> v3: Add missing else and fix register table since CNP GPIO_CTL
>> starts on 0xC5014.
>> v4: Fix pin number and map according to the current available VBT.
>> Re-add pin 4 for port D. Lost during some rebase.
>> v5: Use table as spec. If VBT is wrong it should be ignored.
>>
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Signed-off-by: Rodrigo Vivi 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h   |  3 ++-
>>  drivers/gpu/drm/i915/intel_hdmi.c |  8 +---
>> drivers/gpu/drm/i915/intel_i2c.c  | 15 +--
>>  3 files changed, 20 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 6826547..efbbeb8 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -2618,9 +2618,10 @@ enum skl_disp_power_wells {
>>  #define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
>>  #define   GMBUS_PIN_DPD6 /* HDMID */
>>  #define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
>> -#define   GMBUS_PIN_1_BXT  1
>> +#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
>>  #define   GMBUS_PIN_2_BXT  2
>>  #define   GMBUS_PIN_3_BXT  3
>> +#define   GMBUS_PIN_4_CNP  4
>>  #define   GMBUS_NUM_PINS   7 /* including 0 */
>>  #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /*
>command/status */
>>  #define   GMBUS_SW_CLR_INT (1<<31)
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 6efc3cb..f8c40ae 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1892,19 +1892,21 @@ static u8 intel_hdmi_ddc_pin(struct
>> drm_i915_private *dev_priv,
>>
>> switch (port) {
>> case PORT_B:
>> -   if (IS_GEN9_LP(dev_priv))
>> +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
>> ddc_pin = GMBUS_PIN_1_BXT;
>> else
>> ddc_pin = GMBUS_PIN_DPB;
>> break;
>> case PORT_C:
>> -   if (IS_GEN9_LP(dev_priv))
>> +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
>> ddc_pin = GMBUS_PIN_2_BXT;
>> else
>> ddc_pin = GMBUS_PIN_DPC;
>> break;
>> case PORT_D:
>> -   if (IS_CHERRYVIEW(dev_priv))
>> +   if (HAS_PCH_CNP(dev_priv))
>> +   ddc_pin = GMBUS_PIN_4_CNP;
>> +   else if (IS_CHERRYVIEW(dev_priv))
>> ddc_pin = GMBUS_PIN_DPD_CHV;
>> else
>> ddc_pin = GMBUS_PIN_DPD; diff --git
>> a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
>> index b6401e8..3c9e00d 100644
>> --- a/drivers/gpu/drm/i915/intel_i2c.c
>> +++ b/drivers/gpu/drm/i915/intel_i2c.c
>> @@ -68,11 +68,20 @@ struct gmbus_pin {
>> [GMBUS_PIN_3_BXT] = { "misc", GPIOD },  };
>>
>> +static const struct gmbus_pin gmbus_pins_cnp[] = {
>> +   [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
>> +   [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
>> +   [GMBUS_PIN_3_BXT] = { "misc", GPIOD },
>> +   [GMBUS_PIN_4_CNP] = { "dpd", GPIOE }, };
>> +
>>  /* pin is expected to be valid */
>>  static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private
>*dev_priv,
>>  unsigned int pin)  {
>> -   if (IS_GEN9_LP(dev_priv))
>> +   if (HAS_PCH_CNP(dev_priv))
>> +   return _pins_cnp[pin];
>> +   else if (IS_GEN9_LP(dev_priv))
>> return _pins_bxt[pin];

Re: [Intel-gfx] [PATCH 06/13] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread Pandiyan, Dhinakaran

On Tue, 2017-05-30 at 15:42 -0700, Rodrigo Vivi wrote:
> As for BXT, PP_DIVISOR was removed from CNP PCH and power
> cycle delay has been moved to PP_CONTROL.
> 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 58dca87..1a27c72 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct 
> drm_i915_private *dev_priv,
>   regs->pp_stat = PP_STATUS(pps_idx);

We get the PPS index for BXT from bxt_power_sequencer_idx(), but I don't
see that in this patch for CNP PCH. Does that mean CNP has just one
power sequencer? 


>   regs->pp_on = PP_ON_DELAYS(pps_idx);
>   regs->pp_off = PP_OFF_DELAYS(pps_idx);
> - if (!IS_GEN9_LP(dev_priv))
> + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
>   regs->pp_div = PP_DIVISOR(pps_idx);
>  }
>  
> @@ -5099,7 +5099,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>  
>   pp_on = I915_READ(regs.pp_on);
>   pp_off = I915_READ(regs.pp_off);
> - if (!IS_GEN9_LP(dev_priv)) {
> + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
>   I915_WRITE(regs.pp_ctrl, pp_ctl);
>   pp_div = I915_READ(regs.pp_div);
>   }
> @@ -5117,7 +5117,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>   seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
>  PANEL_POWER_DOWN_DELAY_SHIFT;
>  
> - if (IS_GEN9_LP(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
>   u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
>   BXT_POWER_CYCLE_DELAY_SHIFT;
>   if (tmp > 0)
> @@ -5274,7 +5274,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>(seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
>   /* Compute the divisor for the pp clock, simply match the Bspec
>* formula. */
> - if (IS_GEN9_LP(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
>   pp_div = I915_READ(regs.pp_ctrl);
>   pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
>   pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)


I am not seeing the I915_WRITE for pp_div.


> @@ -5308,7 +5308,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>   DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
> PP_OFF %#x, PP_DIV %#x\n",
> I915_READ(regs.pp_on),
> I915_READ(regs.pp_off),
> -   IS_GEN9_LP(dev_priv) ?
> +   (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
> (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
> I915_READ(regs.pp_div));
>  }

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

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

2017-05-31 Thread Mark Brown

On Wed, May 31, 2017 at 10:41:52PM +0300, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use guid_t type. At the same time we
> convert current users.

Acked-by: Mark Brown 


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

[Intel-gfx] [PATCH] tests/kms_setmode: Dynamic crtc/connector combinations

2017-05-31 Thread Harry Wentland

Create crtc/connector combinations based on actual adapter
information obtained from drmModeRes.

Also set MAX_CRTCs to 6 for AMD GPUs.

Signed-off-by: Harry Wentland 
---
 tests/kms_setmode.c | 52 
 1 file changed, 32 insertions(+), 20 deletions(-)

diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 430568a1c24e..3673cfb58951 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -31,15 +31,13 @@
 #include 
 #include 
 #include 
-
+#include 
 #include "intel_bufmgr.h"
 
 #define MAX_CONNECTORS  10
-#define MAX_CRTCS   3
+#define MAX_CRTCS   6
 
 /* max combinations with repetitions */
-#define MAX_COMBINATION_COUNT   \
-   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
 #define MAX_COMBINATION_ELEMS   MAX_CRTCS
 
 static int drm_fd;
@@ -702,7 +700,8 @@ struct combination {
 
 struct combination_set {
int count;
-   struct combination items[MAX_COMBINATION_COUNT];
+   int capacity;
+   struct combination *items;
 };
 
 /*
@@ -716,7 +715,7 @@ static void iterate_combinations(int n, int k, bool 
allow_repetitions,
int v;
 
if (!k) {
-   igt_assert(set->count < ARRAY_SIZE(set->items));
+   igt_assert(set->count < set->capacity);
set->items[set->count++] = *comb;
return;
}
@@ -741,61 +740,74 @@ static void get_combinations(int n, int k, bool 
allow_repetitions,
 }
 
 static void test_combinations(const struct test_config *tconf,
- int connector_count)
+ int crtc_num)
 {
struct combination_set connector_combs;
struct combination_set crtc_combs;
struct connector_config *cconfs;
int i;
 
-   if (connector_count > 2 && (tconf->flags & TEST_STEALING))
+   if (crtc_num > 2 && (tconf->flags & TEST_STEALING))
return;
 
-   get_combinations(tconf->resources->count_connectors, connector_count,
+   igt_assert(tconf->resources);
+
+   connector_combs.capacity = pow(tconf->resources->count_connectors,
+  tconf->resources->count_crtcs + 1);
+   crtc_combs.capacity = pow(tconf->resources->count_crtcs,
+ tconf->resources->count_crtcs + 1);
+
+   connector_combs.items = malloc(connector_combs.capacity * sizeof(struct 
combination));
+   crtc_combs.items = malloc(crtc_combs.capacity * sizeof(struct 
combination));
+
+   get_combinations(tconf->resources->count_connectors, crtc_num,
 false, _combs);
-   get_combinations(tconf->resources->count_crtcs, connector_count,
+   get_combinations(tconf->resources->count_crtcs, crtc_num,
 true, _combs);
 
igt_info("Testing: %s %d connector combinations\n", tconf->name,
-connector_count);
+crtc_num);
for (i = 0; i < connector_combs.count; i++) {
int *connector_idxs;
int ret;
int j;
 
-   cconfs = malloc(sizeof(*cconfs) * connector_count);
+   cconfs = malloc(sizeof(*cconfs) * crtc_num);
igt_assert(cconfs);
 
connector_idxs = _combs.items[i].elems[0];
ret = get_connectors(tconf->resources, connector_idxs,
-connector_count, cconfs);
+crtc_num, cconfs);
if (ret < 0)
goto free_cconfs;
 
for (j = 0; j < crtc_combs.count; j++) {
int *crtc_idxs = _combs.items[j].elems[0];
ret = assign_crtc_to_connectors(tconf, crtc_idxs,
-   connector_count,
+   crtc_num,
cconfs);
if (ret < 0)
continue;
 
-   test_one_combination(tconf, cconfs, connector_count);
+   test_one_combination(tconf, cconfs, crtc_num);
}
 
-   free_connectors(cconfs, connector_count);
+   free_connectors(cconfs, crtc_num);
 free_cconfs:
free(cconfs);
}
+
+   free(connector_combs.items);
+   free(crtc_combs.items);
 }
 
 static void run_test(const struct test_config *tconf)
 {
-   int connector_num;
+   int crtc_num;
 
-   connector_num = tconf->flags & TEST_CLONE ? 2 : 1;
-   for (; connector_num <= tconf->resources->count_crtcs; connector_num++)
-   test_combinations(tconf, connector_num);
+   crtc_num = tconf->flags & TEST_CLONE ? 2 : 1;
+   for (; crtc_num <= tconf->resources->count_crtcs; crtc_num++)
+   test_combinations(tconf, crtc_num);
 }
 
 static int

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_setmode: increase MAX_CRTCS to 6

2017-05-31 Thread Harry Wentland


On 2017-05-31 09:32 AM, Harry Wentland wrote:

On 2017-05-31 05:37 AM, Daniel Vetter wrote:

On Tue, May 30, 2017 at 04:01:40PM -0400, Harry Wentland wrote:

AMD GPUs can have 6 CRTCs.

This requires us to allocate the combinations on the heap.

Signed-off-by: Harry Wentland 


I think just dynamically allocating stuff directly and dropping the
#define would be even neater ... GetResources can tell us how much of 
each

exists.
-Daniel



Agreed. I'll send out a v3 later.



About to send v3 but this code is quite majorly wrong as-is. In 
particular I see these two issues:


1) In iterate_combinations we assign a stack object to our list of
   combinations which is then popped off the stack as soon as
   get_combinations returns. Later on in test_combinations we then try
   to access it with
connector_idxs = _combs.items[i].elems[0];
...
int *crtc_idxs = _combs.items[j].elems[0];

2) This for loop in iterate_combinations will simply override
   comb->elems[depth] with new values:

for (v = base; v < n; v++) {
comb->elems[depth] = v;
[...]
}

It looks like whoever wrote the code tried to do some k choose n 
algorithm to find all possible sets of crtcs and connectors but then 
only ended up picking one crtc and connector out of each list anyways 
(after the item popped from the stack).


If I find time I might rewrite the test_combinations function with a 
simple nested for loop that tries all crtcs with all connectors 
one-to-one as this seems to be currently the intention of this function.


Harry


Harry


---
  tests/kms_setmode.c | 25 +++--
  1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 430568a1c24e..847ad650d27f 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -35,11 +35,13 @@
  #include "intel_bufmgr.h"
  #define MAX_CONNECTORS  10
-#define MAX_CRTCS   3
+#define MAX_CRTCS   6
  /* max combinations with repetitions */
+/* MAX_CONNECTORS ^ MAX_CRTCS */
+/* TODO should really be MAX_CONNECTORS ^ MAX_CONNECTORS ??? */
  #define MAX_COMBINATION_COUNT   \
-(MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
+(MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * 
MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)

  #define MAX_COMBINATION_ELEMS   MAX_CRTCS
  static int drm_fd;
@@ -743,22 +745,25 @@ static void get_combinations(int n, int k, bool 
allow_repetitions,

  static void test_combinations(const struct test_config *tconf,
int connector_count)
  {
-struct combination_set connector_combs;
-struct combination_set crtc_combs;
+struct combination_set *connector_combs;
+struct combination_set *crtc_combs;
  struct connector_config *cconfs;
  int i;
  if (connector_count > 2 && (tconf->flags & TEST_STEALING))
  return;
+connector_combs = malloc(sizeof(*connector_combs));
+crtc_combs = malloc(sizeof(*crtc_combs));
+
  get_combinations(tconf->resources->count_connectors, 
connector_count,

- false, _combs);
+ false, connector_combs);
  get_combinations(tconf->resources->count_crtcs, connector_count,
- true, _combs);
+ true, crtc_combs);
  igt_info("Testing: %s %d connector combinations\n", tconf->name,
   connector_count);
-for (i = 0; i < connector_combs.count; i++) {
+for (i = 0; i < connector_combs->count; i++) {
  int *connector_idxs;
  int ret;
  int j;
@@ -766,14 +771,14 @@ static void test_combinations(const struct 
test_config *tconf,

  cconfs = malloc(sizeof(*cconfs) * connector_count);
  igt_assert(cconfs);
-connector_idxs = _combs.items[i].elems[0];
+connector_idxs = _combs->items[i].elems[0];
  ret = get_connectors(tconf->resources, connector_idxs,
   connector_count, cconfs);
  if (ret < 0)
  goto free_cconfs;
-for (j = 0; j < crtc_combs.count; j++) {
-int *crtc_idxs = _combs.items[j].elems[0];
+for (j = 0; j < crtc_combs->count; j++) {
+int *crtc_idxs = _combs->items[j].elems[0];
  ret = assign_crtc_to_connectors(tconf, crtc_idxs,
  connector_count,
  cconfs);
--
2.11.0

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



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

Re: [Intel-gfx] [PATCH v2 0/5] ACPI et al: convert to use new UUID API

2017-05-31 Thread Andy Shevchenko

On Wed, 2017-05-31 at 22:41 +0300, Andy Shevchenko wrote:

> [1]: git://git.infradead.org/users/hch/uuid.git
> 
> Changelog v2:
> - append tags I have got so far
> - split single patch to few (5)

> - rebased on top of latest version of uuid-types branch [1]

Fengguang, looking to the above I just got an idea to come up with some
formal syntax in cover letter that will allow your tools to parse the
tree and branch on top of which it should be tested. Do you have
anything like that in place?

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for ACPI et al: convert to use new UUID API

2017-05-31 Thread Patchwork

== Series Details ==

Series: ACPI et al: convert to use new UUID API
URL   : https://patchwork.freedesktop.org/series/25121/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CC  init/main.o
In file included from ./include/linux/acpi.h:44:0,
 from init/main.c:29:
./include/acpi/acpi_bus.h:64:47: error: unknown type name ‘guid_t’
 bool acpi_check_dsm(acpi_handle handle, const guid_t *guid, u64 rev, u64 
funcs);
   ^
./include/acpi/acpi_bus.h:65:64: error: unknown type name ‘guid_t’
 union acpi_object *acpi_evaluate_dsm(acpi_handle handle, const guid_t *guid,
^
./include/acpi/acpi_bus.h:69:51: error: unknown type name ‘guid_t’
 acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t *guid, u64 rev,
   ^
scripts/Makefile.build:302: recipe for target 'init/main.o' failed
make[1]: *** [init/main.o] Error 1
Makefile:1016: recipe for target 'init' failed
make: *** [init] Error 2

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

Re: [Intel-gfx] [PATCH v2 0/5] ACPI et al: convert to use new UUID API

2017-05-31 Thread Christoph Hellwig

On Wed, May 31, 2017 at 10:41:47PM +0300, Andy Shevchenko wrote:
> This series converts ACPI and users of acpi_evaluate_dsm() to new UUID
> API which includes new types and methods.
> 
> Patches are based on uuid tree [1] from Christoph Hellwig and supposed to
> go through it.
> 
> (Christoph, I think it would be nice to attach them to your stuff)

I'd be fine with that in general, as long as we have enough reviewers.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 4/5] ACPI / extlog: Switch to use new generic UUID API

2017-05-31 Thread Andy Shevchenko

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Cc: Borislav Petkov 
Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/acpi_extlog.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index 502ea4dc2080..6b101d595ccc 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -141,9 +141,9 @@ static int extlog_print(struct notifier_block *nb, unsigned 
long val,
int cpu = mce->extcpu;
struct acpi_hest_generic_status *estatus, *tmp;
struct acpi_hest_generic_data *gdata;
-   const uuid_le *fru_id = _UUID_LE;
+   const guid_t *fru_id = _null;
char *fru_text = "";
-   uuid_le *sec_type;
+   guid_t *sec_type;
static u32 err_seq;
 
estatus = extlog_elog_entry_check(cpu, bank);
@@ -165,11 +165,11 @@ static int extlog_print(struct notifier_block *nb, 
unsigned long val,
err_seq++;
gdata = (struct acpi_hest_generic_data *)(tmp + 1);
if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
-   fru_id = (uuid_le *)gdata->fru_id;
+   fru_id = (guid_t *)gdata->fru_id;
if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
fru_text = gdata->fru_text;
-   sec_type = (uuid_le *)gdata->section_type;
-   if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
+   sec_type = (guid_t *)gdata->section_type;
+   if (!guid_equal(sec_type, _SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem = (void *)(gdata + 1);
if (gdata->error_data_length >= sizeof(*mem))
trace_extlog_mem_event(mem, err_seq, fru_id, fru_text,
@@ -182,17 +182,17 @@ static int extlog_print(struct notifier_block *nb, 
unsigned long val,
 
 static bool __init extlog_get_l1addr(void)
 {
-   u8 uuid[16];
+   guid_t guid;
acpi_handle handle;
union acpi_object *obj;
 
-   acpi_str_to_uuid(extlog_dsm_uuid, uuid);
-
+   if (guid_parse(extlog_dsm_uuid, ))
+   return false;
if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", )))
return false;
-   if (!acpi_check_dsm(handle, uuid, EXTLOG_DSM_REV, 1 << EXTLOG_FN_ADDR))
+   if (!acpi_check_dsm(handle, guid.b, EXTLOG_DSM_REV, 1 << 
EXTLOG_FN_ADDR))
return false;
-   obj = acpi_evaluate_dsm_typed(handle, uuid, EXTLOG_DSM_REV,
+   obj = acpi_evaluate_dsm_typed(handle, guid.b, EXTLOG_DSM_REV,
  EXTLOG_FN_ADDR, NULL, ACPI_TYPE_INTEGER);
if (!obj) {
return false;
-- 
2.11.0

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

[Intel-gfx] [PATCH v2 2/5] ACPI / APEI: Switch to use new generic UUID API

2017-05-31 Thread Andy Shevchenko

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Cc: Borislav Petkov 
Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/apei/ghes.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d0855c09f32f..084414a4c5b8 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -431,12 +431,13 @@ static void ghes_do_proc(struct ghes *ghes,
 {
int sev, sec_sev;
struct acpi_hest_generic_data *gdata;
+   guid_t *sec_type;
 
sev = ghes_severity(estatus->error_severity);
apei_estatus_for_each_section(estatus, gdata) {
+   sec_type = (guid_t *)gdata->section_type;
sec_sev = ghes_severity(gdata->error_severity);
-   if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
-CPER_SEC_PLATFORM_MEM)) {
+   if (!guid_equal(sec_type, _SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err;
mem_err = (struct cper_sec_mem_err *)(gdata+1);
ghes_edac_report_mem_error(ghes, sev, mem_err);
@@ -445,8 +446,7 @@ static void ghes_do_proc(struct ghes *ghes,
ghes_handle_memory_failure(gdata, sev);
}
 #ifdef CONFIG_ACPI_APEI_PCIEAER
-   else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
- CPER_SEC_PCIE)) {
+   else if (!guid_equal(sec_type, _SEC_PCIE)) {
struct cper_sec_pcie *pcie_err;
pcie_err = (struct cper_sec_pcie *)(gdata+1);
if (sev == GHES_SEV_RECOVERABLE &&
-- 
2.11.0

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

[Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

2017-05-31 Thread Andy Shevchenko

acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
bytes. Instead we convert them to use guid_t 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.

Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: Amir Goldstein 
Cc: Jarkko Sakkinen 
Reviewed-by: Jani Nikula 
Acked-by: Jani Nikula 
Cc: Ben Skeggs 
Acked-by: Benjamin Tissoires 
Acked-by: Joerg Roedel 
Cc: Adrian Hunter 
Cc: Yisen Zhuang 
Acked-by: Bjorn Helgaas 
Acked-by: Felipe Balbi 
Acked-by: Mathias Nyman 
Reviewed-by: Heikki Krogerus 
Cc: Liam Girdwood 
Cc: Mark Brown 
Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/acpi_extlog.c |  4 ++--
 drivers/acpi/bus.c | 23 --
 drivers/acpi/nfit/core.c   |  6 +++---
 drivers/acpi/utils.c   | 16 +++
 drivers/char/tpm/tpm_crb.c |  9 -
 drivers/char/tpm/tpm_ppi.c | 20 ---
 drivers/gpu/drm/i915/intel_acpi.c  | 14 +
 drivers/gpu/drm/nouveau/nouveau_acpi.c | 20 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c |  9 -
 drivers/hid/i2c-hid/i2c-hid.c  |  9 -
 drivers/iommu/dmar.c   | 11 +--
 drivers/mmc/host/sdhci-pci-core.c  |  9 -
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 15 +++---
 drivers/pci/pci-acpi.c | 13 ++--
 drivers/pci/pci-label.c|  4 ++--
 drivers/usb/dwc3/dwc3-pci.c| 10 +-
 drivers/usb/host/xhci-pci.c|  9 -
 drivers/usb/misc/ucsi.c|  6 +++---
 drivers/usb/typec/typec_wcove.c|  8 
 include/acpi/acpi_bus.h| 11 ++-
 include/linux/acpi.h   |  3 +--
 include/linux/pci-acpi.h   |  2 +-
 sound/soc/intel/skylake/skl-nhlt.c |  7 ---
 tools/testing/nvdimm/test/iomap.c  |  6 +++---
 tools/testing/nvdimm/test/nfit.c   |  2 +-
 25 files changed, 103 insertions(+), 143 deletions(-)

diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index 6b101d595ccc..c9c1d2af9a13 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -190,9 +190,9 @@ static bool __init extlog_get_l1addr(void)
return false;
if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", )))
return false;
-   if (!acpi_check_dsm(handle, guid.b, EXTLOG_DSM_REV, 1 << 
EXTLOG_FN_ADDR))
+   if (!acpi_check_dsm(handle, , EXTLOG_DSM_REV, 1 << EXTLOG_FN_ADDR))
return false;
-   obj = acpi_evaluate_dsm_typed(handle, guid.b, EXTLOG_DSM_REV,
+   obj = acpi_evaluate_dsm_typed(handle, , EXTLOG_DSM_REV,
  EXTLOG_FN_ADDR, NULL, ACPI_TYPE_INTEGER);
if (!obj) {
return false;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 042cd16265b3..5a6fbe0fcaf2 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -196,29 +196,6 @@ static void acpi_print_osc_error(acpi_handle handle,
pr_debug("\n");
 }
 
-acpi_status acpi_str_to_uuid(char *str, u8 *uuid)
-{
-   int i;
-   static int opc_map_to_uuid[16] = {6, 4, 2, 0, 11, 9, 16, 14, 19, 21,
-   24, 26, 28, 30, 32, 34};
-
-   if (strlen(str) != 36)
-   return AE_BAD_PARAMETER;
-   for (i = 0; i < 36; i++) {
-   if (i == 8 || i == 13 || i == 18 || i == 23) {
-   if (str[i] != '-')
-   return AE_BAD_PARAMETER;
-   } else if (!isxdigit(str[i]))
-   return AE_BAD_PARAMETER;
-   }
-   for (i = 0; i < 16; i++) {
-   uuid[i] = hex_to_bin(str[opc_map_to_uuid[i]]) << 4;
-   uuid[i] |= hex_to_bin(str[opc_map_to_uuid[i] + 1]);
-   }
-   return AE_OK;
-}
-EXPORT_SYMBOL_GPL(acpi_str_to_uuid);
-
 acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
 {
acpi_status status;
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 50753582a0b1..56a5b2ca927a 100644
--- a/drivers/acpi/nfit/core.c
+++

[Intel-gfx] [PATCH v2 0/5] ACPI et al: convert to use new UUID API

2017-05-31 Thread Andy Shevchenko

This series converts ACPI and users of acpi_evaluate_dsm() to new UUID
API which includes new types and methods.

Patches are based on uuid tree [1] from Christoph Hellwig and supposed to
go through it.

(Christoph, I think it would be nice to attach them to your stuff)

[1]: git://git.infradead.org/users/hch/uuid.git

Changelog v2:
- append tags I have got so far
- split single patch to few (5)
- rebased on top of latest version of uuid-types branch [1]

Andy Shevchenko (5):
  acpi, nfit: Switch to use new generic UUID API
  ACPI / APEI: Switch to use new generic UUID API
  ACPI / bus: Switch to use new generic UUID API
  ACPI / extlog: Switch to use new generic UUID API
  ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

 drivers/acpi/acpi_extlog.c | 20 
 drivers/acpi/apei/ghes.c   |  8 ++--
 drivers/acpi/bus.c | 29 ++--
 drivers/acpi/nfit/core.c   | 54 +++---
 drivers/acpi/nfit/nfit.h   |  3 +-
 drivers/acpi/utils.c   | 16 +++
 drivers/char/tpm/tpm_crb.c |  9 ++--
 drivers/char/tpm/tpm_ppi.c | 20 
 drivers/gpu/drm/i915/intel_acpi.c  | 14 ++
 drivers/gpu/drm/nouveau/nouveau_acpi.c | 20 
 drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c |  9 ++--
 drivers/hid/i2c-hid/i2c-hid.c  |  9 ++--
 drivers/iommu/dmar.c   | 11 ++---
 drivers/mmc/host/sdhci-pci-core.c  |  9 ++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 15 +++---
 drivers/pci/pci-acpi.c | 13 +++---
 drivers/pci/pci-label.c|  4 +-
 drivers/usb/dwc3/dwc3-pci.c| 10 ++--
 drivers/usb/host/xhci-pci.c|  9 ++--
 drivers/usb/misc/ucsi.c|  6 +--
 drivers/usb/typec/typec_wcove.c|  8 ++--
 include/acpi/acpi_bus.h| 11 +++--
 include/linux/acpi.h   |  4 +-
 include/linux/pci-acpi.h   |  2 +-
 sound/soc/intel/skylake/skl-nhlt.c |  7 +--
 tools/testing/nvdimm/test/iomap.c  |  6 +--
 tools/testing/nvdimm/test/nfit.c   |  2 +-
 27 files changed, 144 insertions(+), 184 deletions(-)

-- 
2.11.0

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

[Intel-gfx] [PATCH v2 1/5] acpi, nfit: Switch to use new generic UUID API

2017-05-31 Thread Andy Shevchenko

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Cc: Dan Williams 
Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/nfit/core.c | 54 
 drivers/acpi/nfit/nfit.h |  3 +--
 include/linux/acpi.h |  1 +
 3 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 656acb5d7166..50753582a0b1 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 guid_t nfit_uuid[NFIT_UUID_MAX];
 
-const u8 *to_nfit_uuid(enum nfit_uuids id)
+const guid_t *to_nfit_uuid(enum nfit_uuids id)
 {
-   return nfit_uuid[id];
+   return _uuid[id];
 }
 EXPORT_SYMBOL(to_nfit_uuid);
 
@@ -222,7 +222,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 guid_t *guid;
int rc, i;
 
func = cmd;
@@ -245,7 +245,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, 
struct nvdimm *nvdimm,
cmd_mask = nvdimm_cmd_mask(nvdimm);
dsm_mask = nfit_mem->dsm_mask;
desc = nd_cmd_dimm_desc(cmd);
-   uuid = to_nfit_uuid(nfit_mem->family);
+   guid = to_nfit_uuid(nfit_mem->family);
handle = adev->handle;
} else {
struct acpi_device *adev = to_acpi_dev(acpi_desc);
@@ -254,7 +254,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, 
struct nvdimm *nvdimm,
cmd_mask = nd_desc->cmd_mask;
dsm_mask = cmd_mask;
desc = nd_cmd_bus_desc(cmd);
-   uuid = to_nfit_uuid(NFIT_DEV_BUS);
+   guid = to_nfit_uuid(NFIT_DEV_BUS);
handle = adev->handle;
dimm_name = "bus";
}
@@ -289,7 +289,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, 
struct nvdimm *nvdimm,
in_buf.buffer.pointer,
min_t(u32, 256, in_buf.buffer.length), true);
 
-   out_obj = acpi_evaluate_dsm(handle, uuid, 1, func, _obj);
+   out_obj = acpi_evaluate_dsm(handle, guid.b, 1, func, _obj);
if (!out_obj) {
dev_dbg(dev, "%s:%s _DSM failed cmd: %s\n", __func__, dimm_name,
cmd_name);
@@ -409,7 +409,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 (!guid_equal(to_nfit_uuid(i), (guid_t *)>range_guid))
return i;
return -1;
 }
@@ -1415,7 +1415,7 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc 
*acpi_desc,
struct acpi_device *adev, *adev_dimm;
struct device *dev = acpi_desc->dev;
unsigned long dsm_mask;
-   const u8 *uuid;
+   const guid_t *guid;
int i;
int family = -1;
 
@@ -1444,7 +1444,7 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc 
*acpi_desc,
/*
 * Until standardization materializes we need to consider 4
 * different command sets.  Note, that checking for function0 (bit0)
-* tells us if any commands are reachable through this uuid.
+* tells us if any commands are reachable through this GUID.
 */
for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_MSFT; i++)
if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1))
@@ -1474,9 +1474,9 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc 
*acpi_desc,
return 0;
}
 
-   uuid = to_nfit_uuid(nfit_mem->family);
+   guid = to_nfit_uuid(nfit_mem->family);
for_each_set_bit(i, _mask, BITS_PER_LONG)
-   if (acpi_check_dsm(adev_dimm->handle, uuid, 1, 1ULL << i))
+   if (acpi_check_dsm(adev_dimm->handle, guid.b, 1, 1ULL << i))
set_bit(i, _mem->dsm_mask);
 
return 0;
@@ -1611,7 +1611,7 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc 
*acpi_desc)
 static void acpi_nfit_init_dsms(struct acpi_nfit_desc *acpi_desc)
 {
struct nvdimm_bus_descriptor *nd_desc = _desc->nd_desc;
-   const u8 *uuid = to_nfit_uuid(NFIT_DEV_BUS);
+   const guid_t *guid = to_nfit_uuid(NFIT_DEV_BUS);
struct acpi_device *adev;
int i;
 
@@ -1621,7 +1621,7 @@ static void acpi_nfit_init_dsms(struct acpi_nfit_desc 
*acpi_desc)
return;
 
for (i = ND_CMD_ARS_CAP; i <= ND_CMD_CLEAR_ERROR; i++)
-   if (acpi_check_dsm(adev->handle, uuid, 1, 1ULL << i))
+

[Intel-gfx] [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API

2017-05-31 Thread Andy Shevchenko

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/bus.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 784bda663d16..042cd16265b3 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -225,13 +225,13 @@ acpi_status acpi_run_osc(acpi_handle handle, struct 
acpi_osc_context *context)
struct acpi_object_list input;
union acpi_object in_params[4];
union acpi_object *out_obj;
-   u8 uuid[16];
+   guid_t guid;
u32 errors;
struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
 
if (!context)
return AE_ERROR;
-   if (ACPI_FAILURE(acpi_str_to_uuid(context->uuid_str, uuid)))
+   if (guid_parse(context->uuid_str, ))
return AE_ERROR;
context->ret.length = ACPI_ALLOCATE_BUFFER;
context->ret.pointer = NULL;
@@ -241,7 +241,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct 
acpi_osc_context *context)
input.pointer = in_params;
in_params[0].type   = ACPI_TYPE_BUFFER;
in_params[0].buffer.length  = 16;
-   in_params[0].buffer.pointer = uuid;
+   in_params[0].buffer.pointer = (u8 *)
in_params[1].type   = ACPI_TYPE_INTEGER;
in_params[1].integer.value  = context->rev;
in_params[2].type   = ACPI_TYPE_INTEGER;
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 05/15] drm/i915: align the vma start to the largest gtt page size

2017-05-31 Thread Chris Wilson

On Wed, May 31, 2017 at 07:52:00PM +0100, Matthew Auld wrote:
> When inserting into a 48bit PPGTT we should the align the vma start
> address to the required page size boundary, to guarantee we use said
> page size in the gtt. If we are dealing with multiple page-sizes, we
> can't guarantee anything and just align to the largest. For soft pinning
> we don't force any alignment.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_vma.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 1aba47024656..c355ccb01872 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -485,6 +485,18 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
> alignment, u64 flags)
>   if (ret)
>   goto err_unpin;
>   } else {
> + if (i915_vm_is_48bit(vma->vm) &&

I would use end > 4G here. As that encapsulates the i915_vm_is_48bit()
test and avoids us applying the extra padding to objects that must be
tightly packed into the low 32bits.

> + obj->mm.page_sizes.sg > I915_GTT_PAGE_SIZE) {
> + unsigned int page_alignment = obj->mm.page_sizes.sg;
> +
> + /* Align to the largest and hope for the best */
> + if (!is_power_of_2(page_alignment))
> + page_alignment = BIT(fls64(page_alignment)-1);

fls64() - 1 == ilog2()

BIT(ilog2()) == roundup_pow_of_two()

linux/log2.h is your friend.

> +
> + alignment = max_t(typeof(alignment), alignment,
> +   page_alignment);

Make page_alignment be u64 and be happy.
-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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Guard against i915_ggtt_disable_guc() being invoked unconditionally

2017-05-31 Thread Patchwork

== Series Details ==

Series: drm/i915: Guard against i915_ggtt_disable_guc() being invoked 
unconditionally
URL   : https://patchwork.freedesktop.org/series/25119/
State : success

== Summary ==

Series 25119v1 drm/i915: Guard against i915_ggtt_disable_guc() being invoked 
unconditionally
https://patchwork.freedesktop.org/api/1.0/series/25119/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:439s
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:585s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:516s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:499s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:574s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:459s
fi-skl-6700hqtotal:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  
time:428s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:402s

593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC 
integration manifest
540e762 drm/i915: Guard against i915_ggtt_disable_guc() being invoked 
unconditionally

== Logs ==

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

Re: [Intel-gfx] [PATCH 04/15] drm/i915: introduce gem object page_sizes

2017-05-31 Thread Chris Wilson

On Wed, May 31, 2017 at 07:51:59PM +0100, Matthew Auld wrote:
>   err = mutex_lock_interruptible(>mm.lock);
> @@ -2533,7 +2543,33 @@ int __i915_gem_object_get_pages(struct 
> drm_i915_gem_object *obj)
>  
>  unlock:
>   mutex_unlock(>mm.lock);
> - return err;
> +
> + if (err)
> + return err;
> +
> + for_each_sg(obj->mm.pages->sgl, sg, obj->mm.pages->nents, i)
> + sg_mask |= sg->length;

This is the worst place to put a loop over sg. Not only is this
synchronous, but pages may not have been allocated yet. Using
set_pages was at least correct in that regard! The interface I will keep
nagging for is for each task to compute sg_mask as they populate the
scatterlist, and then they pass sg_mask to
__i915_gem_object_set_pages() alongside the pages.

Since this didn't fail BAT, that only means we do not have any userptr
tests there...
-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 03/15] drm/i915: introduce page_size_mask to dev_info

2017-05-31 Thread Chris Wilson

On Wed, May 31, 2017 at 07:51:58PM +0100, Matthew Auld wrote:
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
> b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> index 7f038ea15ef5..bb12e6fe24ec 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> @@ -147,6 +147,9 @@ struct drm_i915_private *mock_gem_device(void)
>  
>   mkwrite_device_info(i915)->gen = -1;
>  
> + mkwrite_device_info(i915)->page_size_mask =
> + I915_GTT_PAGE_SIZE_4K;
> +

The next person to add mock device_info details will be moving these to
a function. You have been warned.
-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 01/15] drm/i915: really simple gemfs

2017-05-31 Thread Chris Wilson

On Wed, May 31, 2017 at 07:51:56PM +0100, Matthew Auld wrote:
> Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
> moves us away from the shmemfs shm_mnt, and gives us the much needed
> flexibility to do things like set our own mount options, namely huge=
> which should allow us to enable the use of transparent-huge-pages for
> our shmem backed objects.

After we get the kinks worked out, this should be in drm_gem.c With a
default mountpoint, it should present the same interface to the existing
users. But we will not be the only ones who will custom mount options.
Even for ttm who may only use shmemfs for swap, with the advent of fast
swapping for huge pages that will be win (if any improvement to swap
hell can be a win!).

Just food for thought, not the actual review.
-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

[Intel-gfx] ✓ Fi.CI.BAT: success for huge gtt pages

2017-05-31 Thread Patchwork

== Series Details ==

Series: huge gtt pages
URL   : https://patchwork.freedesktop.org/series/25118/
State : success

== Summary ==

Series 25118v1 huge gtt pages
https://patchwork.freedesktop.org/api/1.0/series/25118/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:446s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:438s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:568s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:475s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:473s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:566s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:452s
fi-skl-6700hqtotal:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  
time:433s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:465s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:489s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:533s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:403s

593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC 
integration manifest
7f3e1da drm/i915: enable platform support for 1G pages
14bccb0 drm/i915: enable platform support for 2M pages
d4e64ea drm/i915: enable platform support for 64K pages
b31a68e drm/i915/debugfs: include some gtt page size metrics
4770028 drm/i915: accurate page size tracking for the ppgtt
2e4fbc8 drm/i915: support huge gtt pages for the 48b PPGTT
9e817e0 drm/i915: disable GTT cache for 2M/1G pages
f30b433 drm/i915: enable IPS bit for 64K pages
bfc2fa4 drm/i915: pass mm.gtt_page_sizes to ppgtt insert_entries
73ee6a0 drm/i915: align 64K objects to 2M
84d06ac drm/i915: align the vma start to the largest gtt page size
2fdf461 drm/i915: introduce gem object page_sizes
cfd5167 drm/i915: introduce page_size_mask to dev_info
79c3010 drm/i915: enable THP for gemfs
4738e84 drm/i915: really simple gemfs

== Logs ==

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

Re: [Intel-gfx] [PATCH 07/15] drm/i915: pass mm.gtt_page_sizes to ppgtt insert_entries

2017-05-31 Thread Chris Wilson

On Wed, May 31, 2017 at 07:52:02PM +0100, Matthew Auld wrote:
> In preparation for supporting huge-pages for the ppgtt, we need to know
> the details of mm.page_sizes at insertion time, such that we can we can
> easily determine the page sizes we are allowed to use.  This is
> especially true for 64K where we can't just arbitrarily use it, since we
> require aligning/padding the vm space to 2M, which sometimes we can't
> enforce.

I haven't considered the implications yet, but this information should
be available on the vma. In principle, the intent here is to more or less
do vma->vm->insert_entries(vma, flags); Just wondering how practical it
will be to get the relevant bits into the vma. Looks doable at first
glance, and it prevent the issue of having multiple vma cloberring the
obj->mm.page_sizes.gtt.
-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

[Intel-gfx] [PATCH] drm/i915: Guard against i915_ggtt_disable_guc() being invoked unconditionally

2017-05-31 Thread Chris Wilson

Commit 7c3f86b6dc51 ("drm/i915: Invalidate the guc ggtt TLB upon
insertion") added the restoration of the invalidation routine after the
GuC was disabled, but missed that the GuC was unconditionally disabled
when not used. This then overwrites the invalidate routine for the older
chipsets, causing havoc and breaking resume as the most obvious victim.

We place the guard inside i915_ggtt_disable_guc() to be backport
friendly (the bug was introduced into v4.11) but it would be preferred
to be in more control over when this was guard (i.e. do not try and
teardown the data structures before we have enabled them). That should
be true with the reorganisation of the guc loaders.

Reported-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Fixes: 7c3f86b6dc51 ("drm/i915: Invalidate the guc ggtt TLB upon insertion")
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc:  # v4.11+
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4f581adf2fcf..6eb83684b97b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3282,7 +3282,8 @@ void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
-   i915->ggtt.invalidate = gen6_ggtt_invalidate;
+   if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+   i915->ggtt.invalidate = gen6_ggtt_invalidate;
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)
-- 
2.11.0

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

[Intel-gfx] [PATCH 14/15] drm/i915: enable platform support for 2M pages

2017-05-31 Thread Matthew Auld

For gen8+ enable platform level support for 2M pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 9 ++---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 0a6940c3841d..452f061fd7b3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -319,7 +319,8 @@ static const struct intel_device_info intel_haswell_info = {
 #define BDW_FEATURES \
HSW_FEATURES, \
BDW_COLORS, \
-   GEN_DEFAULT_PAGE_SIZES, \
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K | \
+ I915_GTT_PAGE_SIZE_2M, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
.has_64bit_reloc = 1
@@ -355,7 +356,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_full_ppgtt = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
.page_size_mask = I915_GTT_PAGE_SIZE_4K |
- I915_GTT_PAGE_SIZE_64K,
+ I915_GTT_PAGE_SIZE_64K |
+ I915_GTT_PAGE_SIZE_2M,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
@@ -363,7 +365,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
 
 #define GEN9_DEFAULT_PAGE_SIZES \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
- I915_GTT_PAGE_SIZE_64K
+ I915_GTT_PAGE_SIZE_64K | \
+ I915_GTT_PAGE_SIZE_2M
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 14e5b11312a7..97d7e84f9893 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -149,7 +149,8 @@ struct drm_i915_private *mock_gem_device(void)
 
mkwrite_device_info(i915)->page_size_mask =
I915_GTT_PAGE_SIZE_4K |
-   I915_GTT_PAGE_SIZE_64K;
+   I915_GTT_PAGE_SIZE_64K |
+   I915_GTT_PAGE_SIZE_2M;
 
spin_lock_init(>mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

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

[Intel-gfx] [PATCH 10/15] drm/i915: support huge gtt pages for the 48b PPGTT

2017-05-31 Thread Matthew Auld

Support inserting huge gtt pages into the 48b PPGTT, including
mixed-mode where we allow a mixture of gtt page sizes.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 79 ++---
 drivers/gpu/drm/i915/i915_gem_gtt.h |  5 +++
 2 files changed, 79 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 935656802f09..924aec4adf6d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -934,17 +934,86 @@ static void gen8_ppgtt_insert_4lvl(struct 
i915_address_space *vm,
   u32 unused)
 {
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+   struct gen8_insert_pte idx = gen8_insert_pte(start);
+   struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
+   struct i915_page_directory_pointer *pdp = pdps[idx.pml4e];
+   struct i915_page_directory *pd = pdp->page_directory[idx.pdpe];
+   struct i915_page_table *pt = pd->page_table[idx.pde];
+   gen8_pte_t *pdp_vaddr = kmap_atomic_px(pdp);
+   gen8_pte_t *pd_vaddr = kmap_atomic_px(pd);
+   gen8_pte_t *pt_vaddr = kmap_atomic_px(pt);
+   const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
struct sgt_dma iter = {
.sg = pages->sgl,
.dma = sg_dma_address(iter.sg),
.max = iter.dma + iter.sg->length,
};
-   struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
-   struct gen8_insert_pte idx = gen8_insert_pte(start);
 
-   while (gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++], ,
-, cache_level))
-   GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4);
+   do {
+   unsigned int page_size;
+
+   pt_vaddr[idx.pte] = pte_encode | iter.dma;
+   page_size = I915_GTT_PAGE_SIZE;
+
+   if (!idx.pte && page_sizes->sg > I915_GTT_PAGE_SIZE) {
+   dma_addr_t remaining = iter.max - iter.dma;
+
+   if (unlikely(page_sizes->sg & I915_GTT_PAGE_SIZE_1G) &&
+   remaining >= I915_GTT_PAGE_SIZE_1G && !idx.pde) {
+   pdp_vaddr[idx.pdpe] = pte_encode | 
GEN8_PDPE_PS_1G | iter.dma;
+   page_size = I915_GTT_PAGE_SIZE_1G;
+   } else if (page_sizes->sg & I915_GTT_PAGE_SIZE_2M &&
+  remaining >= I915_GTT_PAGE_SIZE_2M) {
+   pd_vaddr[idx.pde] = pte_encode | GEN8_PDE_PS_2M 
| iter.dma;
+   page_size = I915_GTT_PAGE_SIZE_2M;
+   /* We don't support 64K in mixed mode for now */
+   } else if (page_sizes->sg == I915_GTT_PAGE_SIZE_64K) {
+   pd_vaddr[idx.pde] |= GEN8_PDE_IPS_64K;
+   }
+   }
+
+   start += page_size;
+   iter.dma += page_size;
+   if (iter.dma >= iter.max) {
+   iter.sg = __sg_next(iter.sg);
+   if (!iter.sg)
+   break;
+
+   iter.dma = sg_dma_address(iter.sg);
+   iter.max = iter.dma + iter.sg->length;
+   }
+
+   idx.pte = gen8_pte_index(start);
+   if (!idx.pte) {
+   idx.pde = gen8_pde_index(start);
+
+   if (!idx.pde) {
+   idx.pdpe = gen8_pdpe_index(start);
+
+   if (!idx.pdpe) {
+   GEM_BUG_ON(idx.pml4e >= 
GEN8_PML4ES_PER_PML4);
+   pdp = pdps[idx.pml4e++];
+
+   kunmap_atomic(pdp_vaddr);
+   pdp_vaddr = kmap_atomic_px(pdp);
+   }
+
+   pd = pdp->page_directory[idx.pdpe];
+
+   kunmap_atomic(pd_vaddr);
+   pd_vaddr = kmap_atomic_px(pd);
+   }
+
+   pt = pd->page_table[idx.pde];
+
+   kunmap_atomic(pt_vaddr);
+   pt_vaddr = kmap_atomic_px(pt);
+   }
+   } while (1);
+
+   kunmap_atomic(pt_vaddr);
+   kunmap_atomic(pd_vaddr);
+   kunmap_atomic(pdp_vaddr);
 }
 
 static void gen8_free_page_tables(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index d45729b9da0c..0811859b3a55 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@

[Intel-gfx] [PATCH 15/15] drm/i915: enable platform support for 1G pages

2017-05-31 Thread Matthew Auld

For gen8+ enable platform level support for 1G pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 9 ++---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 452f061fd7b3..68baefe6566c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -320,7 +320,8 @@ static const struct intel_device_info intel_haswell_info = {
HSW_FEATURES, \
BDW_COLORS, \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
- I915_GTT_PAGE_SIZE_2M, \
+ I915_GTT_PAGE_SIZE_2M | \
+ I915_GTT_PAGE_SIZE_1G, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
.has_64bit_reloc = 1
@@ -357,7 +358,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
.display_mmio_offset = VLV_DISPLAY_BASE,
.page_size_mask = I915_GTT_PAGE_SIZE_4K |
  I915_GTT_PAGE_SIZE_64K |
- I915_GTT_PAGE_SIZE_2M,
+ I915_GTT_PAGE_SIZE_2M |
+ I915_GTT_PAGE_SIZE_1G,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
@@ -366,7 +368,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
 #define GEN9_DEFAULT_PAGE_SIZES \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
  I915_GTT_PAGE_SIZE_64K | \
- I915_GTT_PAGE_SIZE_2M
+ I915_GTT_PAGE_SIZE_2M | \
+ I915_GTT_PAGE_SIZE_1G
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 97d7e84f9893..8d8068083597 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -150,7 +150,8 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->page_size_mask =
I915_GTT_PAGE_SIZE_4K |
I915_GTT_PAGE_SIZE_64K |
-   I915_GTT_PAGE_SIZE_2M;
+   I915_GTT_PAGE_SIZE_2M |
+   I915_GTT_PAGE_SIZE_1G;
 
spin_lock_init(>mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

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

[Intel-gfx] [PATCH 12/15] drm/i915/debugfs: include some gtt page size metrics

2017-05-31 Thread Matthew Auld

Good to know, mostly for debugging purposes.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 40 ++---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7e0816ccdc21..bdcbbd9635c5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -117,6 +117,26 @@ static u64 i915_gem_obj_total_ggtt_size(struct 
drm_i915_gem_object *obj)
return size;
 }
 
+static const char *stringify_page_sizes(unsigned int page_sizes)
+{
+   switch (page_sizes) {
+   case I915_GTT_PAGE_SIZE_4K:
+   return "4K";
+   case I915_GTT_PAGE_SIZE_64K:
+   return "64K";
+   case I915_GTT_PAGE_SIZE_2M:
+   return "2M";
+   case I915_GTT_PAGE_SIZE_1G:
+   return "1G";
+   default:
+   /* mixed-mode? */
+   if (page_sizes)
+   return "M";
+
+   return "";
+   }
+}
+
 static void
 describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
 {
@@ -128,7 +148,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
 
lockdep_assert_held(>base.dev->struct_mutex);
 
-   seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %02x %02x %s%s%s",
+   seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %3s %02x %02x %s%s%s",
   >base,
   get_active_flag(obj),
   get_pin_flag(obj),
@@ -136,6 +156,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
   get_global_flag(obj),
   get_pin_mapped_flag(obj),
   obj->base.size / 1024,
+  stringify_page_sizes(obj->mm.page_sizes.gtt),
   obj->base.read_domains,
   obj->base.write_domain,
   i915_cache_level_str(dev_priv, obj->cache_level),
@@ -399,8 +420,8 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct drm_device *dev = _priv->drm;
struct i915_ggtt *ggtt = _priv->ggtt;
-   u32 count, mapped_count, purgeable_count, dpy_count;
-   u64 size, mapped_size, purgeable_size, dpy_size;
+   u32 count, mapped_count, purgeable_count, dpy_count, huge_count;
+   u64 size, mapped_size, purgeable_size, dpy_size, huge_size;
struct drm_i915_gem_object *obj;
struct drm_file *file;
int ret;
@@ -416,6 +437,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
size = count = 0;
mapped_size = mapped_count = 0;
purgeable_size = purgeable_count = 0;
+   huge_size = huge_count = 0;
list_for_each_entry(obj, _priv->mm.unbound_list, global_link) {
size += obj->base.size;
++count;
@@ -429,6 +451,11 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
mapped_count++;
mapped_size += obj->base.size;
}
+
+   if (obj->mm.page_sizes.gtt > I915_GTT_PAGE_SIZE) {
+   huge_count++;
+   huge_size += obj->base.size;
+   }
}
seq_printf(m, "%u unbound objects, %llu bytes\n", count, size);
 
@@ -451,6 +478,11 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
mapped_count++;
mapped_size += obj->base.size;
}
+
+   if (obj->mm.page_sizes.gtt > I915_GTT_PAGE_SIZE) {
+   huge_count++;
+   huge_size += obj->base.size;
+   }
}
seq_printf(m, "%u bound objects, %llu bytes\n",
   count, size);
@@ -458,6 +490,8 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
   purgeable_count, purgeable_size);
seq_printf(m, "%u mapped objects, %llu bytes\n",
   mapped_count, mapped_size);
+   seq_printf(m, "%u huge-paged objects, %llu bytes\n",
+  huge_count, huge_size);
seq_printf(m, "%u display objects (pinned), %llu bytes\n",
   dpy_count, dpy_size);
 
-- 
2.9.4

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

[Intel-gfx] [PATCH 13/15] drm/i915: enable platform support for 64K pages

2017-05-31 Thread Matthew Auld

For gen9+ enable platform level support for 64K pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 6 --
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 7caccb5bf963..0a6940c3841d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -354,14 +354,16 @@ static const struct intel_device_info 
intel_cherryview_info = {
.has_aliasing_ppgtt = 1,
.has_full_ppgtt = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
-   GEN_DEFAULT_PAGE_SIZES,
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K |
+ I915_GTT_PAGE_SIZE_64K,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
 };
 
 #define GEN9_DEFAULT_PAGE_SIZES \
-   .page_size_mask = I915_GTT_PAGE_SIZE_4K
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K | \
+ I915_GTT_PAGE_SIZE_64K
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index bb12e6fe24ec..14e5b11312a7 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -148,7 +148,8 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->gen = -1;
 
mkwrite_device_info(i915)->page_size_mask =
-   I915_GTT_PAGE_SIZE_4K;
+   I915_GTT_PAGE_SIZE_4K |
+   I915_GTT_PAGE_SIZE_64K;
 
spin_lock_init(>mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

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

[Intel-gfx] [PATCH 01/15] drm/i915: really simple gemfs

2017-05-31 Thread Matthew Auld

Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
moves us away from the shmemfs shm_mnt, and gives us the much needed
flexibility to do things like set our own mount options, namely huge=
which should allow us to enable the use of transparent-huge-pages for
our shmem backed objects.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |  13 +++
 drivers/gpu/drm/i915/i915_gem.c  |  30 ++-
 drivers/gpu/drm/i915/i915_gemfs.c| 105 +++
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  12 ++-
 5 files changed, 159 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gemfs.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 16dccf550412..1a70af7d51ec 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -46,6 +46,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_tiling.o \
  i915_gem_timeline.o \
  i915_gem_userptr.o \
+ i915_gemfs.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d2a57493ac2e..ca3196e2566f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2227,6 +2227,9 @@ struct drm_i915_private {
DECLARE_HASHTABLE(mm_structs, 7);
struct mutex mm_lock;
 
+   /* Our tmpfs instance used for shmem backed objects */
+   struct vfsmount *gemfs_mnt;
+
/* The hw wants to have a stable context identifier for the lifetime
 * of the context (for OA, PASID, faults, etc). This is limited
 * in execlists to 21 bits.
@@ -4169,4 +4172,14 @@ static inline bool i915_gem_object_is_coherent(struct 
drm_i915_gem_object *obj)
HAS_LLC(to_i915(obj->base.dev)));
 }
 
+/* i915_gemfs.c */
+struct vfsmount *i915_gemfs_create(void);
+
+void i915_gemfs_destroy(struct vfsmount *gemfs_mnt);
+
+struct file *i915_gemfs_file_setup(struct vfsmount *gemfs_mnt,
+  const char *name, size_t size);
+
+int i915_gemfs_unlink(struct file *filp);
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ab47a84671f..30f9af590969 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4245,6 +4245,24 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
.pwrite = i915_gem_object_pwrite_gtt,
 };
 
+static int i915_drm_gem_object_init(struct drm_device *dev,
+   struct drm_gem_object *obj,
+   size_t size)
+{
+   struct drm_i915_private *i915 = to_i915(dev);
+   struct file *filp;
+
+   drm_gem_private_object_init(dev, obj, size);
+
+   filp = i915_gemfs_file_setup(i915->gemfs_mnt, "i915 mm object", size);
+   if (IS_ERR(filp))
+   return PTR_ERR(filp);
+
+   obj->filp = filp;
+
+   return 0;
+}
+
 struct drm_i915_gem_object *
 i915_gem_object_create(struct drm_i915_private *dev_priv, u64 size)
 {
@@ -4268,7 +4286,7 @@ i915_gem_object_create(struct drm_i915_private *dev_priv, 
u64 size)
if (obj == NULL)
return ERR_PTR(-ENOMEM);
 
-   ret = drm_gem_object_init(_priv->drm, >base, size);
+   ret = i915_drm_gem_object_init(_priv->drm, >base, size);
if (ret)
goto fail;
 
@@ -4383,6 +4401,9 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
drm_prime_gem_destroy(>base, NULL);
 
reservation_object_fini(>__builtin_resv);
+
+   if (obj->base.filp)
+   i915_gemfs_unlink(obj->base.filp);
drm_gem_object_release(>base);
i915_gem_info_remove_obj(i915, obj->base.size);
 
@@ -4843,6 +4864,10 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
 {
int err = -ENOMEM;
 
+   dev_priv->gemfs_mnt = i915_gemfs_create();
+   if (IS_ERR(dev_priv->gemfs_mnt))
+   return PTR_ERR(dev_priv->gemfs_mnt);
+
dev_priv->objects = KMEM_CACHE(drm_i915_gem_object, SLAB_HWCACHE_ALIGN);
if (!dev_priv->objects)
goto err_out;
@@ -4908,6 +4933,7 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
 err_objects:
kmem_cache_destroy(dev_priv->objects);
 err_out:
+   i915_gemfs_destroy(dev_priv->gemfs_mnt);
return err;
 }
 
@@ -4930,6 +4956,8 @@ void i915_gem_load_cleanup(struct drm_i915_private 
*dev_priv)
 
/* And ensure that our DESTROY_BY_RCU slabs are truly destroyed */
rcu_barrier();
+
+   i915_gemfs_destroy(dev_priv->gemfs_mnt);
 }
 
 int i915_gem_freeze(struct

[Intel-gfx] [PATCH 03/15] drm/i915: introduce page_size_mask to dev_info

2017-05-31 Thread Matthew Auld

In preparation for huge gtt pages expose a page_size_mask as part of the
device info, to indicate the page sizes supported by the HW.  Currently
only 4K is supported.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem_gtt.h  |  8 +++-
 drivers/gpu/drm/i915/i915_pci.c  | 21 +
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  3 +++
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ca3196e2566f..8be48e5d8c1f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -840,6 +840,7 @@ struct intel_device_info {
enum intel_platform platform;
u8 ring_mask; /* Rings supported by the HW */
u8 num_rings;
+   unsigned int page_size_mask; /* page sizes supported by the HW */
 #define DEFINE_FLAG(name) u8 name:1
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG);
 #undef DEFINE_FLAG
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index fb15684c1d83..f8db231c28aa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -42,7 +42,13 @@
 #include "i915_gem_request.h"
 #include "i915_selftest.h"
 
-#define I915_GTT_PAGE_SIZE 4096UL
+#define I915_GTT_PAGE_SIZE_4K BIT(12)
+#define I915_GTT_PAGE_SIZE_64K BIT(16)
+#define I915_GTT_PAGE_SIZE_2M BIT(21)
+#define I915_GTT_PAGE_SIZE_1G BIT(30)
+
+#define I915_GTT_PAGE_SIZE I915_GTT_PAGE_SIZE_4K
+
 #define I915_GTT_MIN_ALIGNMENT I915_GTT_PAGE_SIZE
 
 #define I915_FENCE_REG_NONE -1
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f80db2ccd92f..7caccb5bf963 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -56,6 +56,10 @@
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
 
 /* Keep in gen based order, and chronological order within a gen */
+
+#define GEN_DEFAULT_PAGE_SIZES \
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K
+
 #define GEN2_FEATURES \
.gen = 2, .num_pipes = 1, \
.has_overlay = 1, .overlay_needs_physical = 1, \
@@ -64,6 +68,7 @@
.unfenced_needs_alignment = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_i830_info = {
@@ -96,6 +101,7 @@ static const struct intel_device_info intel_i865g_info = {
.has_gmch_display = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_i915g_info = {
@@ -158,6 +164,7 @@ static const struct intel_device_info intel_pineview_info = 
{
.has_gmch_display = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_i965g_info = {
@@ -198,6 +205,7 @@ static const struct intel_device_info intel_gm45_info = {
.has_gmbus_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_ironlake_d_info = {
@@ -222,6 +230,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_gmbus_irq = 1, \
.has_aliasing_ppgtt = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_sandybridge_d_info = {
@@ -247,6 +256,7 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.has_aliasing_ppgtt = 1, \
.has_full_ppgtt = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
IVB_CURSOR_OFFSETS
 
 static const struct intel_device_info intel_ivybridge_d_info = {
@@ -284,6 +294,7 @@ static const struct intel_device_info intel_valleyview_info 
= {
.has_full_ppgtt = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING,
.display_mmio_offset = VLV_DISPLAY_BASE,
+   GEN_DEFAULT_PAGE_SIZES,
GEN_DEFAULT_PIPEOFFSETS,
CURSOR_OFFSETS
 };
@@ -308,6 +319,7 @@ static const struct intel_device_info intel_haswell_info = {
 #define BDW_FEATURES \
HSW_FEATURES, \
BDW_COLORS, \
+   GEN_DEFAULT_PAGE_SIZES, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
.has_64bit_reloc = 1
@@ -342,13 +354,18 @@ static const struct intel_device_info 
intel_cherryview_info = {
.has_aliasing_ppgtt = 1,
.has_full_ppgtt = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+

[Intel-gfx] [PATCH 04/15] drm/i915: introduce gem object page_sizes

2017-05-31 Thread Matthew Auld

We need to track the possible page sizes given the layout of the sg
table, in preparation for supporting huge gtt pages. Note that this does
in any way represent the real gtt page size usage.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/i915_gem.c| 38 +-
 drivers/gpu/drm/i915/i915_gem_object.h |  5 +
 3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8be48e5d8c1f..e6d1e1df4454 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2896,6 +2896,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define USES_PPGTT(dev_priv)   (i915.enable_ppgtt)
 #define USES_FULL_PPGTT(dev_priv)  (i915.enable_ppgtt >= 2)
 #define USES_FULL_48BIT_PPGTT(dev_priv)(i915.enable_ppgtt == 3)
+#define HAS_PAGE_SIZE(dev_priv, page_size) \
+   ((dev_priv)->info.page_size_mask & (page_size))
 
 #define HAS_OVERLAY(dev_priv)   ((dev_priv)->info.has_overlay)
 #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 30f9af590969..e8ebf39448a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj,
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
 
+   obj->mm.page_sizes.phys = obj->mm.page_sizes.sg = 0;
+
 unlock:
mutex_unlock(>mm.lock);
 }
@@ -2473,6 +2475,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
 void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
 struct sg_table *pages)
 {
+
lockdep_assert_held(>mm.lock);
 
obj->mm.get_page.sg_pos = pages->sgl;
@@ -2516,6 +2519,13 @@ static int i915_gem_object_get_pages(struct 
drm_i915_gem_object *obj)
  */
 int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
 {
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   unsigned long supported_page_sizes = INTEL_INFO(i915)->page_size_mask;
+   struct scatterlist *sg;
+   unsigned int sg_mask = 0;
+   unsigned int i;
+   unsigned int bit;
+   unsigned int max_page_size;
int err;
 
err = mutex_lock_interruptible(>mm.lock);
@@ -2533,7 +2543,33 @@ int __i915_gem_object_get_pages(struct 
drm_i915_gem_object *obj)
 
 unlock:
mutex_unlock(>mm.lock);
-   return err;
+
+   if (err)
+   return err;
+
+   for_each_sg(obj->mm.pages->sgl, sg, obj->mm.pages->nents, i)
+   sg_mask |= sg->length;
+
+   GEM_BUG_ON(!sg_mask);
+
+   obj->mm.page_sizes.phys = sg_mask;
+
+   obj->mm.page_sizes.sg = 0;
+
+   for_each_set_bit(bit, _page_sizes, BITS_PER_LONG) {
+   if (obj->mm.page_sizes.phys & ~0u << bit)
+   obj->mm.page_sizes.sg |= BIT(bit);
+   }
+
+   max_page_size = BIT(fls64(obj->mm.page_sizes.sg)-1);
+
+   /* If were are actually dealing with a single page-size, mark it so */
+   if (IS_ALIGNED(obj->mm.page_sizes.phys, max_page_size))
+   obj->mm.page_sizes.sg = max_page_size;
+
+   GEM_BUG_ON(!HAS_PAGE_SIZE(i915, obj->mm.page_sizes.sg));
+
+   return 0;
 }
 
 /* The 'mapping' part of i915_gem_object_pin_map() below */
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
b/drivers/gpu/drm/i915/i915_gem_object.h
index 35e1a27729dc..6db34eac9794 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -129,6 +129,11 @@ struct drm_i915_gem_object {
struct sg_table *pages;
void *mapping;
 
+   struct i915_page_sizes {
+   unsigned int phys;
+   unsigned int sg;
+   } page_sizes;
+
struct i915_gem_object_page_iter {
struct scatterlist *sg_pos;
unsigned int sg_idx; /* in pages, but 32bit eek! */
-- 
2.9.4

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

[Intel-gfx] [PATCH 06/15] drm/i915: align 64K objects to 2M

2017-05-31 Thread Matthew Auld

We can't mix 64K and 4K pte's in the same page-table, so for now we
align 64K objects to 2M to avoid any potential mixing. This is
potentially wasteful but in reality shouldn't be too bad since this only
applies to the virtual address space of a 48b PPGTT.

Suggested-by: Chris Wilson 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_vma.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index c355ccb01872..af950d92fa13 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -479,6 +479,15 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
goto err_unpin;
}
 
+   /* A current limitation in our implementation is that 64K
+* objects must be aligned to 2M, and given that we can't
+* enforce this for soft pinning, we need to fallback to normal
+* pages if don't meet this restriction.
+*/
+   if (obj->mm.page_sizes.sg == I915_GTT_PAGE_SIZE_64K &&
+   !IS_ALIGNED(offset | size, I915_GTT_PAGE_SIZE_2M))
+   obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE;
+
ret = i915_gem_gtt_reserve(vma->vm, >node,
   size, offset, obj->cache_level,
   flags);
@@ -493,6 +502,15 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
if (!is_power_of_2(page_alignment))
page_alignment = BIT(fls64(page_alignment)-1);
 
+   /* We can't mix 64K and 4K pte's in the same page-table 
(2M
+* block), and so to avoid the ugliness and complexity 
of
+* coloring we opt for just aligning 64K objects to 2M.
+*/
+   if (obj->mm.page_sizes.sg == I915_GTT_PAGE_SIZE_64K) {
+   page_alignment = I915_GTT_PAGE_SIZE_2M;
+   size = roundup(size, page_alignment);
+   }
+
alignment = max_t(typeof(alignment), alignment,
  page_alignment);
}
-- 
2.9.4

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

[Intel-gfx] [PATCH 07/15] drm/i915: pass mm.gtt_page_sizes to ppgtt insert_entries

2017-05-31 Thread Matthew Auld

In preparation for supporting huge-pages for the ppgtt, we need to know
the details of mm.page_sizes at insertion time, such that we can we can
easily determine the page sizes we are allowed to use.  This is
especially true for 64K where we can't just arbitrarily use it, since we
require aligning/padding the vm space to 2M, which sometimes we can't
enforce.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 24 
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  3 +++
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  3 ++-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 +
 4 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0c1008a2bbda..935656802f09 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -208,7 +208,8 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
pte_flags |= PTE_READ_ONLY;
 
vma->vm->insert_entries(vma->vm, vma->pages, vma->node.start,
-   cache_level, pte_flags);
+   >obj->mm.page_sizes, cache_level,
+   pte_flags);
 
return 0;
 }
@@ -909,6 +910,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
 static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
   struct sg_table *pages,
   u64 start,
+  struct i915_page_sizes *page_sizes,
   enum i915_cache_level cache_level,
   u32 unused)
 {
@@ -927,6 +929,7 @@ static void gen8_ppgtt_insert_3lvl(struct 
i915_address_space *vm,
 static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
   struct sg_table *pages,
   u64 start,
+  struct i915_page_sizes *page_sizes,
   enum i915_cache_level cache_level,
   u32 unused)
 {
@@ -1623,6 +1626,7 @@ static void gen6_ppgtt_clear_range(struct 
i915_address_space *vm,
 static void gen6_ppgtt_insert_entries(struct i915_address_space *vm,
  struct sg_table *pages,
  u64 start,
+ struct i915_page_sizes *page_sizes,
  enum i915_cache_level cache_level,
  u32 flags)
 {
@@ -2092,6 +2096,7 @@ static void gen8_ggtt_insert_page(struct 
i915_address_space *vm,
 static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *st,
 u64 start,
+struct i915_page_sizes *page_sizes,
 enum i915_cache_level level,
 u32 unused)
 {
@@ -2139,6 +2144,7 @@ static void gen6_ggtt_insert_page(struct 
i915_address_space *vm,
 static void gen6_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *st,
 u64 start,
+struct i915_page_sizes *page_sizes,
 enum i915_cache_level level,
 u32 flags)
 {
@@ -2238,7 +2244,7 @@ static int bxt_vtd_ggtt_insert_entries__cb(void *_arg)
 {
struct insert_entries *arg = _arg;
 
-   gen8_ggtt_insert_entries(arg->vm, arg->st, arg->start, arg->level, 0);
+   gen8_ggtt_insert_entries(arg->vm, arg->st, arg->start, 0, arg->level, 
0);
bxt_vtd_ggtt_wa(arg->vm);
 
return 0;
@@ -2247,6 +2253,7 @@ static int bxt_vtd_ggtt_insert_entries__cb(void *_arg)
 static void bxt_vtd_ggtt_insert_entries__BKL(struct i915_address_space *vm,
 struct sg_table *st,
 u64 start,
+struct i915_page_sizes *page_sizes,
 enum i915_cache_level level,
 u32 unused)
 {
@@ -2318,6 +2325,7 @@ static void i915_ggtt_insert_page(struct 
i915_address_space *vm,
 static void i915_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *pages,
 u64 start,
+struct i915_page_sizes *page_sizes,
 enum i915_cache_level cache_level,
 u32 unused)
 {
@@ -2353,7 +2361,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,

[Intel-gfx] [PATCH 05/15] drm/i915: align the vma start to the largest gtt page size

2017-05-31 Thread Matthew Auld

When inserting into a 48bit PPGTT we should the align the vma start
address to the required page size boundary, to guarantee we use said
page size in the gtt. If we are dealing with multiple page-sizes, we
can't guarantee anything and just align to the largest. For soft pinning
we don't force any alignment.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_vma.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 1aba47024656..c355ccb01872 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -485,6 +485,18 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
if (ret)
goto err_unpin;
} else {
+   if (i915_vm_is_48bit(vma->vm) &&
+   obj->mm.page_sizes.sg > I915_GTT_PAGE_SIZE) {
+   unsigned int page_alignment = obj->mm.page_sizes.sg;
+
+   /* Align to the largest and hope for the best */
+   if (!is_power_of_2(page_alignment))
+   page_alignment = BIT(fls64(page_alignment)-1);
+
+   alignment = max_t(typeof(alignment), alignment,
+ page_alignment);
+   }
+
ret = i915_gem_gtt_insert(vma->vm, >node,
  size, alignment, obj->cache_level,
  start, end, flags);
-- 
2.9.4

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

[Intel-gfx] [PATCH 09/15] drm/i915: disable GTT cache for 2M/1G pages

2017-05-31 Thread Matthew Auld

When SW enables the use of 2M/1G pages, it must disable the GTT cache.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_pm.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 936eef1634c7..496b64f65eb2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8195,10 +8195,10 @@ static void broadwell_init_clock_gating(struct 
drm_i915_private *dev_priv)
 
/*
 * WaGttCachingOffByDefault:bdw
-* GTT cache may not work with big pages, so if those
-* are ever enabled GTT cache may need to be disabled.
+* The GTT cache must be disabled if the system is planning to use
+* 2M/1G pages.
 */
-   I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
+   I915_WRITE(HSW_GTT_CACHE_EN, 0);
 
/* WaKVMNotificationOnConfigChange:bdw */
I915_WRITE(CHICKEN_PAR2_1, I915_READ(CHICKEN_PAR2_1)
@@ -8474,10 +8474,10 @@ static void cherryview_init_clock_gating(struct 
drm_i915_private *dev_priv)
gen8_set_l3sqc_credits(dev_priv, 38, 2);
 
/*
-* GTT cache may not work with big pages, so if those
-* are ever enabled GTT cache may need to be disabled.
+* The GTT cache must be disabled if the system is planning to use
+* 2M/1G pages.
 */
-   I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
+   I915_WRITE(HSW_GTT_CACHE_EN, 0);
 }
 
 static void g4x_init_clock_gating(struct drm_i915_private *dev_priv)
-- 
2.9.4

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

[Intel-gfx] [PATCH 11/15] drm/i915: accurate page size tracking for the ppgtt

2017-05-31 Thread Matthew Auld

Now that we support multiple page sizes for the ppgtt, it would be
useful to track the real usage for debugging purposes.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 10 ++
 drivers/gpu/drm/i915/i915_gem_object.h|  2 ++
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  1 +
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 924aec4adf6d..84de1618594e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -217,6 +217,8 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
 static void ppgtt_unbind_vma(struct i915_vma *vma)
 {
vma->vm->clear_range(vma->vm, vma->node.start, vma->size);
+
+   vma->obj->mm.page_sizes.gtt = 0;
 }
 
 static gen8_pte_t gen8_pte_encode(dma_addr_t addr,
@@ -924,6 +926,8 @@ static void gen8_ppgtt_insert_3lvl(struct 
i915_address_space *vm,
 
gen8_ppgtt_insert_pte_entries(ppgtt, >pdp, , ,
  cache_level);
+
+   page_sizes->gtt = I915_GTT_PAGE_SIZE;
 }
 
 static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
@@ -972,6 +976,8 @@ static void gen8_ppgtt_insert_4lvl(struct 
i915_address_space *vm,
}
}
 
+   page_sizes->gtt |= page_size;
+
start += page_size;
iter.dma += page_size;
if (iter.dma >= iter.max) {
@@ -1731,6 +1737,8 @@ static void gen6_ppgtt_insert_entries(struct 
i915_address_space *vm,
}
} while (1);
kunmap_atomic(vaddr);
+
+   page_sizes->gtt = I915_GTT_PAGE_SIZE;
 }
 
 static int gen6_alloc_va_range(struct i915_address_space *vm,
@@ -2525,6 +2533,8 @@ static void aliasing_gtt_unbind_vma(struct i915_vma *vma)
struct i915_address_space *vm = >mm.aliasing_ppgtt->base;
 
vm->clear_range(vm, vma->node.start, vma->size);
+
+   vma->obj->mm.page_sizes.gtt = 0;
}
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
b/drivers/gpu/drm/i915/i915_gem_object.h
index 6db34eac9794..9b00947bf856 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -129,9 +129,11 @@ struct drm_i915_gem_object {
struct sg_table *pages;
void *mapping;
 
+   /* TODO: whack some of this into the error state */
struct i915_page_sizes {
unsigned int phys;
unsigned int sg;
+   unsigned int gtt;
} page_sizes;
 
struct i915_gem_object_page_iter {
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 81c0d6b87e68..954f4140d902 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -267,6 +267,7 @@ static int lowlevel_hole(struct drm_i915_private *i915,
 
GEM_BUG_ON(addr + BIT_ULL(size) > vm->total);
vm->clear_range(vm, addr, BIT_ULL(size));
+   obj->mm.page_sizes.gtt = 0;
}
 
i915_gem_object_unpin_pages(obj);
-- 
2.9.4

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

[Intel-gfx] [PATCH 02/15] drm/i915: enable THP for gemfs

2017-05-31 Thread Matthew Auld

Enable transparent-huge-pages through gemfs by mounting with
huge=within_size.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gemfs.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gemfs.c 
b/drivers/gpu/drm/i915/i915_gemfs.c
index e1b2af1d9946..7b50ff97623e 100644
--- a/drivers/gpu/drm/i915/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/i915_gemfs.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static const struct dentry_operations anon_ops = {
.d_dname = simple_dname
@@ -41,6 +42,28 @@ struct vfsmount *i915_gemfs_create(void)
 
gemfs_mnt = kern_mount(type);
 
+#if defined(CONFIG_TRANSPARENT_HUGE_PAGECACHE)
+   if (!IS_ERR(gemfs_mnt) && has_transparent_hugepage()) {
+   struct super_block *sb = gemfs_mnt->mnt_sb;
+   char options[] = "huge=within_size";
+   int flags = 0;
+   int ret;
+
+   /* Idealy we would just pass the mount options when mounting,
+* but for some reason shmem chooses not to parse the options
+* for MS_KERNMOUNT, probably because shm_mnt is the only tmpfs
+* kernel mount other than this, where the mount options aren't
+* used. To workaround this we do a remount, which is fairly
+* inexpensive, where we know the options are never igonored.
+*/
+   ret = sb->s_op->remount_fs(sb, , options);
+   if (ret) {
+   kern_unmount(gemfs_mnt);
+   return ERR_PTR(ret);
+   }
+   }
+#endif
+
return gemfs_mnt;
 }
 
-- 
2.9.4

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

[Intel-gfx] [PATCH 00/15] huge gtt pages

2017-05-31 Thread Matthew Auld

Not too different from the last posting, except we now request thp through our
own tmpfs mount and try to support mixed gtt page sizes for a given object.

Matthew Auld (15):
  drm/i915: really simple gemfs
  drm/i915: enable THP for gemfs
  drm/i915: introduce page_size_mask to dev_info
  drm/i915: introduce gem object page_sizes
  drm/i915: align the vma start to the largest gtt page size
  drm/i915: align 64K objects to 2M
  drm/i915: pass mm.gtt_page_sizes to ppgtt insert_entries
  drm/i915: enable IPS bit for 64K pages
  drm/i915: disable GTT cache for 2M/1G pages
  drm/i915: support huge gtt pages for the 48b PPGTT
  drm/i915: accurate page size tracking for the ppgtt
  drm/i915/debugfs: include some gtt page size metrics
  drm/i915: enable platform support for 64K pages
  drm/i915: enable platform support for 2M pages
  drm/i915: enable platform support for 1G pages

 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  40 ++-
 drivers/gpu/drm/i915/i915_drv.h  |  16 +++
 drivers/gpu/drm/i915/i915_gem.c  |  79 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 113 +---
 drivers/gpu/drm/i915/i915_gem_gtt.h  |  16 ++-
 drivers/gpu/drm/i915/i915_gem_object.h   |   7 ++
 drivers/gpu/drm/i915/i915_gemfs.c| 128 +++
 drivers/gpu/drm/i915/i915_pci.c  |  29 +
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/i915_vma.c  |  30 ++
 drivers/gpu/drm/i915/intel_pm.c  |  12 +--
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|   4 +-
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  18 +++-
 drivers/gpu/drm/i915/selftests/mock_gtt.c|   1 +
 15 files changed, 470 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gemfs.c

-- 
2.9.4

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

[Intel-gfx] [PATCH 08/15] drm/i915: enable IPS bit for 64K pages

2017-05-31 Thread Matthew Auld

Before we can enable 64K pages through the IPS bit, we must first enable
it through MMIO, otherwise the page-walker will simply ignore it.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 11 +++
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e8ebf39448a5..d53e091e8b11 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4738,6 +4738,17 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
}
}
 
+   /* To support 64K PTE's we need to first enable the use of the
+* Intermediate-Page-Size(IPS) bit of the PDE field via some magical
+* mmio, otherwise the page-walker will simply ignore the IPS bit. This
+* shouldn't be needed after GEN10.
+*/
+   if (HAS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K) &&
+   INTEL_GEN(dev_priv) <= 10)
+   I915_WRITE(GEN8_GAMW_ECO_DEV_RW_IA,
+  I915_READ(GEN8_GAMW_ECO_DEV_RW_IA) |
+  GAMW_ECO_ENABLE_64K_IPS_FIELD);
+
i915_gem_init_swizzling(dev_priv);
 
/*
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 89888adb9af1..9b967101b9b2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1993,6 +1993,9 @@ enum skl_disp_power_wells {
 #define GEN9_GAMT_ECO_REG_RW_IA _MMIO(0x4ab0)
 #define   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS  (1<<18)
 
+#define GEN8_GAMW_ECO_DEV_RW_IA _MMIO(0x4080)
+#define   GAMW_ECO_ENABLE_64K_IPS_FIELD 0xF
+
 #define GAMT_CHKN_BIT_REG  _MMIO(0x4ab8)
 #define   GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1<<28)
 
-- 
2.9.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/13] drm/i915/cnp: Introduce Cannonpoint PCH. (rev2)

2017-05-31 Thread Patchwork

== Series Details ==

Series: series starting with [01/13] drm/i915/cnp: Introduce Cannonpoint PCH. 
(rev2)
URL   : https://patchwork.freedesktop.org/series/25070/
State : success

== Summary ==

Series 25070v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25070/revisions/2/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_busy:
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144 +2
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-skl-6700hq) fdo#101154 +7

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:443s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:434s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:580s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:506s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:415s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:418s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:502s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:278  pass:229  dwarn:1   dfail:0   fail:26  skip:22  
time:402s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:474s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:509s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:439s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:403s

593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC 
integration manifest
70f0c4a drm/i915/cfl: Coffe Lake reuses Kabylake DMC.
0674cbd drm/i915/cfl: Introduce Coffee Lake workardounds.
5026cc0 drm/i915/cfl: Add CFL PCI IDs for U SKU
5d82218 drm/i915/cfl: Add Coffee Lake PCI IDs for H and S Skus.
7a0af93 drm/i915/cfl: Basic PM plumbing for Coffee Lake.
a092590 drm/i915/cfl: Coffee Lake uses CNP PCH.
cffd6d9 drm/i915/cfl: Introduce Coffee Lake platform definition.
c027cc9 drm/i915/cnp: Panel Power sequence changes for CNP PCH.
14ffeee drm/i915/cnp: add CNP gmbus support
4910b96 drm/i915/cnp: Backlight support for CNP.
918c713 drm/i915/cnp: Get/set proper Raw clock frequency on CNP.
01dd2f3 drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH
84e5d90 drm/i915/cnp: Introduce Cannonpoint PCH.

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/cnp: add CNP gmbus support

2017-05-31 Thread Rodrigo Vivi

Anusha, when going to merge I noticed that we had the wrong version here.

The incorrect version would break hdmi on CFL. The right workaround is
not to respect the CNL bios for the pin number.

So, I hope I can keep your rv-b on this one, but I'd like you to confirm please.

Thanks,
Rodrigo.

On Wed, May 31, 2017 at 11:26 AM, Rodrigo Vivi  wrote:
> On CNP PCH based platforms the gmbus is on the south display that
> is on PCH. The existing implementation for previous platforms
> already covers the need for CNP expect for the pin pair configuration
> that follows similar definitions that we had on BXT.
>
> v2: Don't drop "_BXT" as the indicator of the first platform
> supporting this pin numbers. Suggested by Daniel.
> v3: Add missing else and fix register table since CNP GPIO_CTL
> starts on 0xC5014.
> v4: Fix pin number and map according to the current available VBT.
> Re-add pin 4 for port D. Lost during some rebase.
> v5: Use table as spec. If VBT is wrong it should be ignored.
>
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   |  3 ++-
>  drivers/gpu/drm/i915/intel_hdmi.c |  8 +---
>  drivers/gpu/drm/i915/intel_i2c.c  | 15 +--
>  3 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6826547..efbbeb8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2618,9 +2618,10 @@ enum skl_disp_power_wells {
>  #define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
>  #define   GMBUS_PIN_DPD6 /* HDMID */
>  #define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
> -#define   GMBUS_PIN_1_BXT  1
> +#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
>  #define   GMBUS_PIN_2_BXT  2
>  #define   GMBUS_PIN_3_BXT  3
> +#define   GMBUS_PIN_4_CNP  4
>  #define   GMBUS_NUM_PINS   7 /* including 0 */
>  #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
> command/status */
>  #define   GMBUS_SW_CLR_INT (1<<31)
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 6efc3cb..f8c40ae 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1892,19 +1892,21 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
> *dev_priv,
>
> switch (port) {
> case PORT_B:
> -   if (IS_GEN9_LP(dev_priv))
> +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
> ddc_pin = GMBUS_PIN_1_BXT;
> else
> ddc_pin = GMBUS_PIN_DPB;
> break;
> case PORT_C:
> -   if (IS_GEN9_LP(dev_priv))
> +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
> ddc_pin = GMBUS_PIN_2_BXT;
> else
> ddc_pin = GMBUS_PIN_DPC;
> break;
> case PORT_D:
> -   if (IS_CHERRYVIEW(dev_priv))
> +   if (HAS_PCH_CNP(dev_priv))
> +   ddc_pin = GMBUS_PIN_4_CNP;
> +   else if (IS_CHERRYVIEW(dev_priv))
> ddc_pin = GMBUS_PIN_DPD_CHV;
> else
> ddc_pin = GMBUS_PIN_DPD;
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index b6401e8..3c9e00d 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -68,11 +68,20 @@ struct gmbus_pin {
> [GMBUS_PIN_3_BXT] = { "misc", GPIOD },
>  };
>
> +static const struct gmbus_pin gmbus_pins_cnp[] = {
> +   [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
> +   [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
> +   [GMBUS_PIN_3_BXT] = { "misc", GPIOD },
> +   [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
> +};
> +
>  /* pin is expected to be valid */
>  static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private 
> *dev_priv,
>  unsigned int pin)
>  {
> -   if (IS_GEN9_LP(dev_priv))
> +   if (HAS_PCH_CNP(dev_priv))
> +   return _pins_cnp[pin];
> +   else if (IS_GEN9_LP(dev_priv))
> return _pins_bxt[pin];
> else if (IS_GEN9_BC(dev_priv))
> return _pins_skl[pin];
> @@ -87,7 +96,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
> *dev_priv,
>  {
> unsigned int size;
>
> -   if (IS_GEN9_LP(dev_priv))
> +   if (HAS_PCH_CNP(dev_priv))
> +   size = ARRAY_SIZE(gmbus_pins_cnp);
> +   else if (IS_GEN9_LP(dev_priv))
> size = ARRAY_SIZE(gmbus_pins_bxt);
> else if (IS_GEN9_BC(dev_priv))
> size = ARRAY_SIZE(gmbus_pins_skl);
> --
> 1.9.1
>
>

[Intel-gfx] [PATCH] drm/i915/cnp: add CNP gmbus support

2017-05-31 Thread Rodrigo Vivi

On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.

v2: Don't drop "_BXT" as the indicator of the first platform
supporting this pin numbers. Suggested by Daniel.
v3: Add missing else and fix register table since CNP GPIO_CTL
starts on 0xC5014.
v4: Fix pin number and map according to the current available VBT.
Re-add pin 4 for port D. Lost during some rebase.
v5: Use table as spec. If VBT is wrong it should be ignored.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++-
 drivers/gpu/drm/i915/intel_hdmi.c |  8 +---
 drivers/gpu/drm/i915/intel_i2c.c  | 15 +--
 3 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6826547..efbbeb8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2618,9 +2618,10 @@ enum skl_disp_power_wells {
 #define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
 #define   GMBUS_PIN_DPD6 /* HDMID */
 #define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
-#define   GMBUS_PIN_1_BXT  1
+#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
 #define   GMBUS_PIN_2_BXT  2
 #define   GMBUS_PIN_3_BXT  3
+#define   GMBUS_PIN_4_CNP  4
 #define   GMBUS_NUM_PINS   7 /* including 0 */
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6efc3cb..f8c40ae 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1892,19 +1892,21 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
*dev_priv,
 
switch (port) {
case PORT_B:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_1_BXT;
else
ddc_pin = GMBUS_PIN_DPB;
break;
case PORT_C:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_2_BXT;
else
ddc_pin = GMBUS_PIN_DPC;
break;
case PORT_D:
-   if (IS_CHERRYVIEW(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   ddc_pin = GMBUS_PIN_4_CNP;
+   else if (IS_CHERRYVIEW(dev_priv))
ddc_pin = GMBUS_PIN_DPD_CHV;
else
ddc_pin = GMBUS_PIN_DPD;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b6401e8..3c9e00d 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -68,11 +68,20 @@ struct gmbus_pin {
[GMBUS_PIN_3_BXT] = { "misc", GPIOD },
 };
 
+static const struct gmbus_pin gmbus_pins_cnp[] = {
+   [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
+   [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
+   [GMBUS_PIN_3_BXT] = { "misc", GPIOD },
+   [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
+};
+
 /* pin is expected to be valid */
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   return _pins_cnp[pin];
+   else if (IS_GEN9_LP(dev_priv))
return _pins_bxt[pin];
else if (IS_GEN9_BC(dev_priv))
return _pins_skl[pin];
@@ -87,7 +96,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   size = ARRAY_SIZE(gmbus_pins_cnp);
+   else if (IS_GEN9_LP(dev_priv))
size = ARRAY_SIZE(gmbus_pins_bxt);
else if (IS_GEN9_BC(dev_priv))
size = ARRAY_SIZE(gmbus_pins_skl);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm: Extract drm_vblank.[hc]

2017-05-31 Thread kbuild test robot

Hi Daniel,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170531]
[cannot apply to v4.12-rc3]
[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/Daniel-Vetter/drm-Extract-drm_vblank-hc/20170531-223258
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id'
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id'
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_zlp_not_supp'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:507: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:507: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:507: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:507: warning: No description found for parameter 
'ioctls'
   inclu

Re: [Intel-gfx] [PATCH] drm/i915/dvo: fix debug logging on unknown DID

2017-05-31 Thread Clint Taylor




On 05/31/2017 03:16 AM, Jani Nikula wrote:

Print DID not VID on the DID error path. Looks like a copy-paste error
from the VID error path. Clarify and clean up error logging, making them
distinguishable from each other, while at it.


Reviewed-by: Clinton Taylor 

-Clint



Reported-by: Petru Mihancea 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101243
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/dvo_ch7xxx.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c 
b/drivers/gpu/drm/i915/dvo_ch7xxx.c
index 44b3159f2fe8..7aeeffd2428b 100644
--- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
@@ -217,9 +217,8 @@ static bool ch7xxx_init(struct intel_dvo_device *dvo,
  
  	name = ch7xxx_get_id(vendor);

if (!name) {
-   DRM_DEBUG_KMS("ch7xxx not detected; got 0x%02x from %s "
-   "slave %d.\n",
- vendor, adapter->name, dvo->slave_addr);
+   DRM_DEBUG_KMS("ch7xxx not detected; got VID 0x%02x from %s slave 
%d.\n",
+ vendor, adapter->name, dvo->slave_addr);
goto out;
}
  
@@ -229,9 +228,8 @@ static bool ch7xxx_init(struct intel_dvo_device *dvo,
  
  	devid = ch7xxx_get_did(device);

if (!devid) {
-   DRM_DEBUG_KMS("ch7xxx not detected; got 0x%02x from %s "
-   "slave %d.\n",
- vendor, adapter->name, dvo->slave_addr);
+   DRM_DEBUG_KMS("ch7xxx not detected; got DID 0x%02x from %s slave 
%d.\n",
+ device, adapter->name, dvo->slave_addr);
goto out;
}
  


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

Re: [Intel-gfx] [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.

2017-05-31 Thread Mahesh Kumar


Reviewed-by: Mahesh Kumar 


On Wednesday 31 May 2017 09:12 PM, Maarten Lankhorst wrote:

On some systems there can be a race condition in which no crtc state is
added to the first atomic commit. This results in all crtc's having a
null DDB allocation, causing a FIFO underrun on any update until the
first modeset.

Changes since v1:
- Do not take the connection_mutex, this is already done below.

Reported-by: Maarten Lankhorst 
Inspired-by: Mahesh Kumar 
Signed-off-by: Maarten Lankhorst 
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc:  # v4.8+
Cc: Mahesh Kumar 
Cc: Matt Roper 
---
  drivers/gpu/drm/i915/intel_pm.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 936eef1634c7..fce4bc5ccc99 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4819,11 +4819,19 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct skl_wm_values *results = _state->wm_results;
+   struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
int ret, i;
  
  	/*

+* When we distrust bios wm we always need to recompute to set the
+* expected DDB allocations for each CRTC.
+*/
+   if (to_i915(dev)->wm.distrust_bios_wm)
+   changed = true;
+
+   /*
 * If this transaction isn't actually touching any CRTC's, don't
 * bother with watermark calculation.  Note that if we pass this
 * test, we're guaranteed to hold at least one CRTC state mutex,
@@ -4833,6 +4841,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 */
for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
+
if (!changed)
return 0;
  


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

2017-05-31 Thread Patchwork

== Series Details ==

Series: drm/i915/ddi: Avoid long delays during system suspend / eDP disabling
URL   : https://patchwork.freedesktop.org/series/25116/
State : success

== Summary ==

Series 25116v1 drm/i915/ddi: Avoid long delays during system suspend / eDP 
disabling
https://patchwork.freedesktop.org/api/1.0/series/25116/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:444s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
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:510s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:428s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:497s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:458s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:572s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:461s
fi-skl-6700hqtotal:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  
time:427s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:469s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:500s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:402s

593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC 
integration manifest
1119300 drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

== Logs ==

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

Re: [Intel-gfx] [PATCH 06/13] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

2017-05-31 Thread Clint Taylor


Reviewed-by: Clinton Taylor 

-Clint

On 05/30/2017 03:42 PM, Rodrigo Vivi wrote:

As for BXT, PP_DIVISOR was removed from CNP PCH and power
cycle delay has been moved to PP_CONTROL.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/intel_dp.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 58dca87..1a27c72 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct drm_i915_private 
*dev_priv,
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
regs->pp_off = PP_OFF_DELAYS(pps_idx);
-   if (!IS_GEN9_LP(dev_priv))
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
regs->pp_div = PP_DIVISOR(pps_idx);
  }
  
@@ -5099,7 +5099,7 @@ static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
  
  	pp_on = I915_READ(regs.pp_on);

pp_off = I915_READ(regs.pp_off);
-   if (!IS_GEN9_LP(dev_priv)) {
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
I915_WRITE(regs.pp_ctrl, pp_ctl);
pp_div = I915_READ(regs.pp_div);
}
@@ -5117,7 +5117,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
   PANEL_POWER_DOWN_DELAY_SHIFT;
  
-	if (IS_GEN9_LP(dev_priv)) {

+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
BXT_POWER_CYCLE_DELAY_SHIFT;
if (tmp > 0)
@@ -5274,7 +5274,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
/* Compute the divisor for the pp clock, simply match the Bspec
 * formula. */
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
pp_div = I915_READ(regs.pp_ctrl);
pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
@@ -5308,7 +5308,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, PP_OFF 
%#x, PP_DIV %#x\n",
  I915_READ(regs.pp_on),
  I915_READ(regs.pp_off),
- IS_GEN9_LP(dev_priv) ?
+ (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
  (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
  I915_READ(regs.pp_div));
  }


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

Re: [Intel-gfx] [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

2017-05-31 Thread Kirti Wankhede



On 5/31/2017 11:48 AM, Chen, Xiaoguang wrote:
> Hi,
> 
>> -Original Message-
>> From: Gerd Hoffmann [mailto:kra...@redhat.com]
>> Sent: Monday, May 29, 2017 3:20 PM
>> To: Chen, Xiaoguang ;
>> alex.william...@redhat.com; ch...@chris-wilson.co.uk; intel-
>> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>> zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt-
>> d...@lists.freedesktop.org; Wang, Zhi A ; Tian, Kevin
>> 
>> Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
>>
>>> +struct vfio_vgpu_dmabuf_info {
>>> +   __u32 argsz;
>>> +   __u32 flags;
>>> +   struct vfio_vgpu_plane_info plane_info;
>>> +   __s32 fd;
>>> +   __u32 pad;
>>> +};
>>
>> Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...
>>
>> I think we should have something like this:
>>
>> struct vfio_vgpu_plane_info {
>> __u64 start;
>> __u64 drm_format_mod;
>> __u32 drm_format;
>> __u32 width;
>> __u32 height;
>> __u32 stride;
>> __u32 size;
>> __u32 x_pos;
>> __u32 y_pos;
>>__u32 padding;
>> };
>>
>> struct vfio_vgpu_query_plane {
>>  __u32 argsz;
>>  __u32 flags;
>>  struct vfio_vgpu_plane_info plane_info;
>>__u32 plane_id;
>>__u32 padding;
>> };
>>
>> struct vfio_vgpu_create_dmabuf {
>>  __u32 argsz;
>>  __u32 flags;
>>  struct vfio_vgpu_plane_info plane_info;
>>__u32 plane_id;
>>__s32 fd;
>> };
> Good suggestion will apply in the next version.
> Thanks for review :)
> 

Can you define what are the expected values of 'flags' would be?

Thanks,
Kirti

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

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

2017-05-31 Thread Ville Syrjälä

On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote:
> Atm disabling either DP or eDP outputs can generate a spurious short
> pulse interrupt. The reason is that after disabling the port the source
> will stop sending a valid stream data, while the sink expects either a
> valid stream or the idle pattern. Since neither of this is sent the sink
> assumes (after an arbitrary delay) that the link is lost and requests
> for link retraining with a short pulse.
> 
> The spurious pulse is a real problem at least for eDP panels with long
> power-off / power-cycle delays: as part of disabling the output we
> disable the panel power. The subsequent spurious short pulse handling
> will have to turn the power back on, which means the driver has to do a
> redundant wait for the power-off and power-cycle delays. During system
> suspend this leads to an unnecessary delay up to ~1s on systems with
> such panels as reported by Rui.
> 
> To fix this put the sink to DPMS D3 state before turning off the port.
> According to the DP spec in this state the sink should not request
> retraining. This is also what we do already on pre-ddi platforms.
> 
> As an alternative I also tried configuring the port to send idle pattern
> - which is against BSPec - and leave the port in normal mode before
> turning off the port. Neither of these resolved the problem.
> 
> Cc: Zhang Rui 
> Cc: David Weinehall 
> Cc: Ville Syrjälä 
> Reported-and-tested-by: Zhang Rui 
> Signed-off-by: Imre Deak 

Makes sense to me.

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0914ad9..8bac628 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1732,12 +1732,18 @@ static void intel_ddi_post_disable(struct 
> intel_encoder *intel_encoder,
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   enum port port = intel_ddi_get_encoder_port(intel_encoder);
>   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> + struct intel_dp *intel_dp = NULL;
>   int type = intel_encoder->type;
>   uint32_t val;
>   bool wait = false;
>  
>   /* old_crtc_state and old_conn_state are NULL when called from DP_MST */
>  
> + if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> + intel_dp = enc_to_intel_dp(encoder);
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + }
> +
>   val = I915_READ(DDI_BUF_CTL(port));
>   if (val & DDI_BUF_CTL_ENABLE) {
>   val &= ~DDI_BUF_CTL_ENABLE;
> @@ -1753,9 +1759,7 @@ static void intel_ddi_post_disable(struct intel_encoder 
> *intel_encoder,
>   if (wait)
>   intel_wait_ddi_buf_idle(dev_priv, port);
>  
> - if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + if (intel_dp) {
>   intel_edp_panel_vdd_on(intel_dp);
>   intel_edp_panel_off(intel_dp);
>   }
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

2017-05-31 Thread Imre Deak

Atm disabling either DP or eDP outputs can generate a spurious short
pulse interrupt. The reason is that after disabling the port the source
will stop sending a valid stream data, while the sink expects either a
valid stream or the idle pattern. Since neither of this is sent the sink
assumes (after an arbitrary delay) that the link is lost and requests
for link retraining with a short pulse.

The spurious pulse is a real problem at least for eDP panels with long
power-off / power-cycle delays: as part of disabling the output we
disable the panel power. The subsequent spurious short pulse handling
will have to turn the power back on, which means the driver has to do a
redundant wait for the power-off and power-cycle delays. During system
suspend this leads to an unnecessary delay up to ~1s on systems with
such panels as reported by Rui.

To fix this put the sink to DPMS D3 state before turning off the port.
According to the DP spec in this state the sink should not request
retraining. This is also what we do already on pre-ddi platforms.

As an alternative I also tried configuring the port to send idle pattern
- which is against BSPec - and leave the port in normal mode before
turning off the port. Neither of these resolved the problem.

Cc: Zhang Rui 
Cc: David Weinehall 
Cc: Ville Syrjälä 
Reported-and-tested-by: Zhang Rui 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_ddi.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0914ad9..8bac628 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1732,12 +1732,18 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
enum port port = intel_ddi_get_encoder_port(intel_encoder);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+   struct intel_dp *intel_dp = NULL;
int type = intel_encoder->type;
uint32_t val;
bool wait = false;
 
/* old_crtc_state and old_conn_state are NULL when called from DP_MST */
 
+   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
+   intel_dp = enc_to_intel_dp(encoder);
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+   }
+
val = I915_READ(DDI_BUF_CTL(port));
if (val & DDI_BUF_CTL_ENABLE) {
val &= ~DDI_BUF_CTL_ENABLE;
@@ -1753,9 +1759,7 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder,
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);
 
-   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+   if (intel_dp) {
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
}
-- 
2.7.4

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

[Intel-gfx] [RFC i-g-t 1/1] tests/gem_bad_address: Fix and update gem_bad_address

2017-05-31 Thread Antonio Argenziano

When writing to an invalid memory location, the HW should be clever
enough to silently discard the write without disrupting execution.
gem_bad_address aim at just that. The test has been updated to move away
from the libDrm wrappers and use the IOCTL wrappers instead. Also the
invalid address has been updated to be just outside of the GTT space.

Since the test is considered to be HW focused, meaning that it doesn't
really exercise the deriver but rather an HW feature, a new folder has
been created to host such tests. The commit moves the test in the newly
created folder for HW focused tests.

Signed-off-by: Antonio Argenziano 
---
 Makefile.am   |  4 ++
 configure.ac  | 11 ++
 tests_hw/Makefile.am  | 36 ++
 tests_hw/Makefile.sources |  8 
 {tests => tests_hw}/gem_bad_address.c | 69 ---
 5 files changed, 98 insertions(+), 30 deletions(-)
 create mode 100644 tests_hw/Makefile.am
 create mode 100644 tests_hw/Makefile.sources
 rename {tests => tests_hw}/gem_bad_address.c (50%)

diff --git a/Makefile.am b/Makefile.am
index 60168628..dca76bf0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,10 @@ ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
 
 SUBDIRS = lib man tools scripts benchmarks
 
+if BUILD_HW_TESTS
+SUBDIRS += tests_hw
+endif
+
 if BUILD_TESTS
 SUBDIRS += tests
 endif
diff --git a/configure.ac b/configure.ac
index 5342e33c..85885f25 100644
--- a/configure.ac
+++ b/configure.ac
@@ -333,6 +333,15 @@ fi
 AM_CONDITIONAL(BUILD_TESTS, [test "x$BUILD_TESTS" = xyes])
 AC_DEFINE_UNQUOTED(TARGET_CPU_PLATFORM, ["$host_cpu"], [Target platform])
 
+AC_ARG_ENABLE(tests_hw,
+ AS_HELP_STRING([--disable-hw-tests],
+ [Disable HW tests build (default: enabled)]),
+ [BUILD_HW_TESTS=$enableval], [BUILD_HW_TESTS="yes"])
+if test "x$BUILD_TESTS" = xyes; then
+   AC_DEFINE(BUILD_HW_TESTS, 1, [Build hw tests])
+fi
+AM_CONDITIONAL(BUILD_HW_TESTS, [test "x$BUILD_HW_TESTS" = xyes])
+
 files="broadwell cherryview haswell ivybridge sandybridge valleyview skylake"
 for file in $files; do
REGISTER_FILES="$REGISTER_FILES $file `cat 
$srcdir/tools/registers/$file`"
@@ -353,6 +362,7 @@ AC_CONFIG_FILES([
 man/Makefile
 scripts/Makefile
 tests/Makefile
+tests_hw/Makefile
 tools/Makefile
 tools/null_state_gen/Makefile
 tools/registers/Makefile
@@ -376,6 +386,7 @@ echo "Intel GPU tools"
 echo ""
 echo " • Tests:"
 echo "   Build tests: ${BUILD_TESTS}"
+echo "   Build hw tests : ${BUILD_HW_TESTS}"
 echo "   Compile prime tests: ${NOUVEAU}"
 echo "   Print stack traces : ${with_libunwind}"
 echo "   Debug flags: ${DEBUG_CFLAGS}"
diff --git a/tests_hw/Makefile.am b/tests_hw/Makefile.am
new file mode 100644
index ..36ed9eb9
--- /dev/null
+++ b/tests_hw/Makefile.am
@@ -0,0 +1,36 @@
+include Makefile.sources
+
+if BUILD_HW_TESTS
+
+hw-test-list.txt: Makefile.sources
+   @echo TESTLIST > $@
+   @echo ${hw_tests_all} >> $@
+   @echo TESTLIST >> $@
+
+all-local: .gitignore
+.gitignore: Makefile.sources
+   @echo "$(HW_TESTS_PROGS) hw-test-list.txt .gitignore" | sed 
's/\s\+/\n/g' | sort > $@
+
+pkglibexec_PROGRAMS = \
+   $(HW_TESTS_PROGS) \
+   $(NULL)
+
+pkgdata_DATA = hw-test-list.txt
+
+CLEANFILES = hw-test-list.txt .gitignore
+
+AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) -Wno-unused-result $(DEBUG_CFLAGS)\
+   -I$(srcdir)/.. \
+   -I$(srcdir)/../lib \
+   -include "$(srcdir)/../lib/check-ndebug.h" \
+   -DIGT_SRCDIR=\""$(abs_srcdir)"\" \
+   -DIGT_DATADIR=\""$(pkgdatadir)"\" \
+   $(LIBUNWIND_CFLAGS) $(WERROR_CFLAGS) \
+   $(NULL)
+
+LDADD = ../lib/libintel_tools.la $(GLIB_LIBS) $(XMLRPC_LIBS) $(DLOPEN_LIBS)
+
+AM_CFLAGS += $(CAIRO_CFLAGS) $(LIBUDEV_CFLAGS) $(GLIB_CFLAGS)
+AM_LDFLAGS = -Wl,--as-needed
+
+endif
diff --git a/tests_hw/Makefile.sources b/tests_hw/Makefile.sources
new file mode 100644
index ..25d181c0
--- /dev/null
+++ b/tests_hw/Makefile.sources
@@ -0,0 +1,8 @@
+HW_TESTS_PROGS =   \
+   gem_bad_address \
+   $(NULL)
+
+#This target contains all testcases
+hw_tests_all = \
+   $(HW_TESTS_PROGS) \
+   $(NULL)
diff --git a/tests/gem_bad_address.c b/tests_hw/gem_bad_address.c
similarity index 50%
rename from tests/gem_bad_address.c
rename to tests_hw/gem_bad_address.c
index a970dfa4..c254f894 100644
--- a/tests/gem_bad_address.c
+++ b/tests_hw/gem_bad_address.c
@@ -23,37 +23,53 @@
  * Authors:
  *Eric Anholt 
  *Jesse Barnes  (based on gem_bad_blit.c)
+ *Antonio Argenziano 
  *
  */
 
 #include "igt.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "drm.h"

[Intel-gfx] [RFC i-g-t 0/1] Introducing HW focused tests

2017-05-31 Thread Antonio Argenziano

The IGT test suite aims at testing the functionalities of the i915
graphics driver. Because of an increasing effort to move development and
validation to the early stages in the development of new platforms, it
is necessary to provide some form of coverage for scenarios where the
driver assumes the HW will have a determined behaviour.

This patch introduces a more HW focused test that will send 'bad commands'
to the GPU and expect they are dealt with accordingly. Since the test will
not exercise i915 as such but rather rely on the HW to manage the issue, it
is not suitable to be merged in the current IGT tests. A new folder,
'tests_hw' has been created to host such tests.

This is not intended to introduce an exhaustive test of the Intel GEN hardware,
but, rather, as an attempt to instigate a discussion on what should be the
proper procedure for managing and maintaining HW focused tests.

Cc: Latvala Petri 

Antonio Argenziano (1):
  tests/gem_bad_address: Fix and update gem_bad_address

 Makefile.am   |  4 ++
 configure.ac  | 11 ++
 tests_hw/Makefile.am  | 36 ++
 tests_hw/Makefile.sources |  8 
 {tests => tests_hw}/gem_bad_address.c | 69 ---
 5 files changed, 98 insertions(+), 30 deletions(-)
 create mode 100644 tests_hw/Makefile.am
 create mode 100644 tests_hw/Makefile.sources
 rename {tests => tests_hw}/gem_bad_address.c (50%)

-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

2017-05-31 Thread Liviu Dudau

On Wed, May 31, 2017 at 06:41:05PM +0200, Daniel Vetter wrote:
> On Wed, May 31, 2017 at 1:22 PM, Liviu Dudau  wrote:
> > On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote:
> >> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau  wrote:
> >> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> >> >> IRQs are properly shut down, so it almost works as race-free shutdown.
> >> >> Except the irq is stopped after the vblank stuff, so boom anyway.
> >> >> Proper way would be to call drm_atomic_helper_shutdown before any of
> >> >> the kms things gets stopped. So no harm in removing the
> >> >> drm_vblank_cleanup here really.
> >> >
> >> > Slightly confused on the implied message in the commit text: is "Proper 
> >> > way
> >> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a 
> >> > future
> >> > patch? A message to the future us on how to fix things if they blow up?
> >> >
> >> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why 
> >> > does the
> >> > patch (and the series) avoids doing that? Lack of understanding of the 
> >> > driver's
> >> > internal workings? Then I want to help, if I can understand the new 
> >> > direction.
> >>
> >> Yes, I wanted to not make things worse. If you look at the overall
> >> result (especially last patch) I'm also trying to better document
> >> stuff in the vblank area, but summarized, if you want to make sure
> >> that vblank processing has stopped, you need to call drm_vblank_off on
> >> each active crtc. The simplest way to get that is by using
> >> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't
> >> really do anything useful (see the last patch for the only valid
> >> usecase there ever was).
> >
> > OK, so there should be a follow up patch adding 
> > drm_atomic_helper_shutdown(). I guess
> > I need to call dibs on it? :)
> 
> I googled what "to call dibs on smth" means and still can't figure out
> what you mean here. Can you pls explain?

Means I put my name on it. Urban dictionary on "call dibs" gives it a very 
gender
specific usage, my intent was to convey the message that I will take it on my 
TODO list.

Best regards,
Liviu

> 
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] pwm: lpss: Add intel-gfx as consumer device in lookup table

2017-05-31 Thread kbuild test robot

Hi Shobhit,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.12-rc3 next-20170531]
[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/Shobhit-Kumar/drm-i915-Encapsulate-the-pwm_device-in-a-pwm_info-structure/20170531-222631
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-i0-201722 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "pwm_add_table" [drivers/pwm/pwm-lpss-platform.ko] undefined!
>> ERROR: "pwm_remove_table" [drivers/pwm/pwm-lpss-platform.ko] undefined!

---
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

Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

2017-05-31 Thread Daniel Vetter

On Wed, May 31, 2017 at 1:22 PM, Liviu Dudau  wrote:
> On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote:
>> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau  wrote:
>> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
>> >> IRQs are properly shut down, so it almost works as race-free shutdown.
>> >> Except the irq is stopped after the vblank stuff, so boom anyway.
>> >> Proper way would be to call drm_atomic_helper_shutdown before any of
>> >> the kms things gets stopped. So no harm in removing the
>> >> drm_vblank_cleanup here really.
>> >
>> > Slightly confused on the implied message in the commit text: is "Proper way
>> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a future
>> > patch? A message to the future us on how to fix things if they blow up?
>> >
>> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why 
>> > does the
>> > patch (and the series) avoids doing that? Lack of understanding of the 
>> > driver's
>> > internal workings? Then I want to help, if I can understand the new 
>> > direction.
>>
>> Yes, I wanted to not make things worse. If you look at the overall
>> result (especially last patch) I'm also trying to better document
>> stuff in the vblank area, but summarized, if you want to make sure
>> that vblank processing has stopped, you need to call drm_vblank_off on
>> each active crtc. The simplest way to get that is by using
>> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't
>> really do anything useful (see the last patch for the only valid
>> usecase there ever was).
>
> OK, so there should be a follow up patch adding drm_atomic_helper_shutdown(). 
> I guess
> I need to call dibs on it? :)

I googled what "to call dibs on smth" means and still can't figure out
what you mean here. Can you pls explain?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

2017-05-31 Thread Liviu Dudau

On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote:
> IRQs are properly shut down, so it almost works as race-free shutdown.
> Except the irq is stopped after the vblank stuff, so boom anyway.
> Proper way would be to call drm_atomic_helper_shutdown before any of
> the kms things gets stopped. So no harm in removing the
> drm_vblank_cleanup here really.
> 
> Same story for both hdlcd and mali.
> 
> v2: Move misplaced malidp hunk to this patch (Liviu).
> 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Signed-off-by: Daniel Vetter 

On the assumption that a subsequent patch will fix the issue highlighted in
the commit message (doesn't have to be part of this series):

Acked-by: Liviu Dudau 

I'm assuming that you are going to carry this patch through one of your trees,
so I will not pull it into mali-dp tree.

Thanks,
Liviu

> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c  | 2 --
>  drivers/gpu/drm/arm/malidp_drv.c | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 0f49c4b12772..345c8357b273 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -340,7 +340,6 @@ static int hdlcd_drm_bind(struct device *dev)
>   }
>  err_fbdev:
>   drm_kms_helper_poll_fini(drm);
> - drm_vblank_cleanup(drm);
>  err_vblank:
>   pm_runtime_disable(drm->dev);
>  err_pm_active:
> @@ -368,7 +367,6 @@ static void hdlcd_drm_unbind(struct device *dev)
>   }
>   drm_kms_helper_poll_fini(drm);
>   component_unbind_all(dev, drm);
> - drm_vblank_cleanup(drm);
>   pm_runtime_get_sync(drm->dev);
>   drm_irq_uninstall(drm);
>   pm_runtime_put_sync(drm->dev);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 0d3eb537d08b..01b13d219917 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -652,7 +652,6 @@ static int malidp_bind(struct device *dev)
>   drm_kms_helper_poll_fini(drm);
>  fbdev_fail:
>   pm_runtime_get_sync(dev);
> - drm_vblank_cleanup(drm);
>  vblank_fail:
>   malidp_se_irq_fini(drm);
>   malidp_de_irq_fini(drm);
> @@ -692,7 +691,6 @@ static void malidp_unbind(struct device *dev)
>   }
>   drm_kms_helper_poll_fini(drm);
>   pm_runtime_get_sync(dev);
> - drm_vblank_cleanup(drm);
>   malidp_se_irq_fini(drm);
>   malidp_de_irq_fini(drm);
>   component_unbind_all(dev, drm);
> -- 
> 2.11.0
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/e1000e-fix

2017-05-31 Thread Daniel Vetter

On Wed, May 31, 2017 at 5:08 PM, David Miller  wrote:
> From: Daniel Vetter 
> Date: Wed, 31 May 2017 08:10:45 +0200
>
>> On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter  
>> wrote:
>>> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie  wrote:
 On 31 May 2017 at 08:10, David Miller  wrote:
> From: Daniel Vetter 
> Date: Tue, 30 May 2017 22:15:42 +0200
>
>> If the e1000e maintainer wants to coalesce or not return statements
>> this simple way, that's imo on him to change the color as needed.
>
> That's not how things work.
>
> If the maintainer wants you to style things a certain way, either you
> do it that way or your patch isn't accepted.
>>>
>>> Consider this pull a regression report, pls handle it.
>>
>> And I guess I pile of more cc, to make this regression report
>> complete. I mean you got the backtrace, bisect and a proposed fix, and
>> the almost-whitespace change demanded is something gcc does in its
>> sleep. I'd understand a request to retest if it would be a real
>> functional change, but in this situation I have no idea why this
>> regression just can't be fixed already.
>
> And we can't understand why respinning with the requested change is
> less work than making several postings such as this one.

I guess next time around we should do even less, i.e. report the
regression + bisect and then escalate this until the netdev folks fix
it on their own?

Like Jani said every -rc1 a pile of our CI machines keel over, and
unfortunately this patch here isn't the only one which seems to not
really move anywhere.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Get rid of the enable_guc_loading module parameter

2017-05-31 Thread Oscar Mateo





On 05/18/2017 05:41 PM, Michal Wajdeczko wrote:

On Fri, May 05, 2017 at 01:23:17PM +, Oscar Mateo wrote:

The decission to enable GuC loading shouldn't be left to the user.
Provided the HW supports the GuC, there are only two reasons to load it:

- The user has requested GuC submission.
- We have a HuC firmware available (so we need the GuC to validate it).

We leave the enable_guc_submission parameter untouched ("auto", "never",
"if supported", "required") but make its behavior a little bit more
consistent. Also, if not really required, we do not try to fetch any
firmware.

Cc: Anusha Srivatsa 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 10 --
  drivers/gpu/drm/i915/i915_drv.c |  2 +-
  drivers/gpu/drm/i915/i915_drv.h | 16 +
  drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
  drivers/gpu/drm/i915/i915_irq.c |  2 +-
  drivers/gpu/drm/i915/i915_params.c  |  6 
  drivers/gpu/drm/i915/i915_params.h  |  2 --
  drivers/gpu/drm/i915/intel_guc_loader.c | 48 +++
  drivers/gpu/drm/i915/intel_huc.c|  5 +--
  drivers/gpu/drm/i915/intel_uc.c | 58 +
  drivers/gpu/drm/i915/intel_uc.h |  4 +--
  drivers/gpu/drm/i915/intel_uncore.c |  3 +-
  13 files changed, 82 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470..e030b41 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2366,8 +2366,10 @@ static int i915_huc_load_status_info(struct seq_file *m, 
void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_uc_fw *huc_fw = _priv->huc.fw;
  
-	if (!HAS_HUC_UCODE(dev_priv))

+   if (!HAS_GUC(dev_priv)) {
+   seq_puts(m, "No HuC support in HW\n");
return 0;
+   }
  
  	seq_puts(m, "HuC firmware status:\n");

seq_printf(m, "\tpath: %s\n", huc_fw->path);
@@ -2399,8 +2401,10 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
struct intel_uc_fw *guc_fw = _priv->guc.fw;
u32 tmp, i;
  
-	if (!HAS_GUC_UCODE(dev_priv))

+   if (!HAS_GUC(dev_priv)) {
+   seq_puts(m, "No GuC support in HW\n");
return 0;
+   }
  
  	seq_printf(m, "GuC firmware status:\n");

seq_printf(m, "\tpath: %s\n",
@@ -2504,7 +2508,7 @@ static int i915_guc_info(struct seq_file *m, void *data)
  
  	if (!guc->execbuf_client) {

seq_printf(m, "GuC submission %s\n",
-  HAS_GUC_SCHED(dev_priv) ?
+  HAS_GUC(dev_priv) ?
   "disabled" :
   "not supported");
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72fb47a..006ed91 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -996,7 +996,7 @@ static void intel_sanitize_options(struct drm_i915_private 
*dev_priv)
i915.semaphores = intel_sanitize_semaphores(dev_priv, i915.semaphores);
DRM_DEBUG_DRIVER("use GPU semaphores? %s\n", yesno(i915.semaphores));
  
-	intel_uc_sanitize_options(dev_priv);

+   intel_guc_sanitize_submission(dev_priv);
  }
  
  /**

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b20ed16..5d00120 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2921,15 +2921,17 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
  #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
  #define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
  
+#define HAS_GUC(dev_priv)	((dev_priv)->info.has_guc)

+#define HAS_GUC_UCODE(dev_priv)((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv)((dev_priv)->huc.fw.path != NULL)
+
  /*
- * For now, anything with a GuC requires uCode loading, and then supports
- * command submission once loaded. But these are logically independent
- * properties, so we have separate macros to test them.
+ * Only two things require us to load the GuC firmware: either we want
+ * to enable GuC submission or we need it to to validate a HuC firmware
   */
-#define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
-#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
+#define NEEDS_GUC_LOADING(dev_priv) \
+   (HAS_GUC(dev_priv) && \
+   (i915.enable_guc_submission || HAS_HUC_UCODE(dev_priv)))
  
  #define HAS_RESOURCE_STREAMER(dev_priv)

Re: [Intel-gfx] [PULL] topic/e1000e-fix

2017-05-31 Thread Jani Nikula

On Wed, 31 May 2017, David Miller  wrote:
> And we can't understand why respinning with the requested change is
> less work than making several postings such as this one.

When our CI hits tons of non-drm issues every merge window, I imagine
our developers can start to get a little frustrated trying to get them
fixed. Especially so when valid fixes like this get blocked by silly
bikesheds from developers who don't even seem to have very many
contributions upstream, and the maintainers don't respond. We have
enough on our plates trying to get our own stuff fixed.

While I understand why our developers aren't willing to jump through all
the hoops, updated patch follows. Please let's move on.

BR,
Jani.

Chris Wilson (1):
  e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

 drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.11.0

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

[Intel-gfx] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

2017-05-31 Thread Jani Nikula

From: Chris Wilson 

An error during suspend (e100e_pm_suspend),

[  429.994338] ACPI : EC: event blocked
[  429.994633] e1000e: EEE TX LPI TIMER: 0011
[  430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[  430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[  430.955458] PM: Device :00:19.0 failed to suspend async: error -2
[  430.955581] PM: Some devices failed to suspend, or early wake event detected
[  430.957709] ACPI : EC: event unblocked

lead to complete failure:

[  432.585002] [ cut here ]
[  432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 
__free_irq+0x9f/0x280
[  432.585015] Trying to free already-free IRQ 20
[  432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal 
intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci 
i915 mmc_core e1000e ptp pps_core prime_numbers
[  432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U  
4.10.0-rc8-CI-Patchwork_3870+ #1
[  432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 
07/02/2012
[  432.585050] Workqueue: events_unbound async_run_entry_fn
[  432.585051] Call Trace:
[  432.585058]  dump_stack+0x67/0x92
[  432.585062]  __warn+0xc6/0xe0
[  432.585065]  warn_slowpath_fmt+0x4a/0x50
[  432.585070]  ? _raw_spin_lock_irqsave+0x49/0x60
[  432.585072]  __free_irq+0x9f/0x280
[  432.585075]  free_irq+0x34/0x80
[  432.585089]  e1000_free_irq+0x65/0x70 [e1000e]
[  432.585098]  e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[  432.585106]  e1000e_pm_suspend+0x21/0x30 [e1000e]
[  432.585113]  pci_pm_suspend+0x71/0x140
[  432.585118]  dpm_run_callback+0x6f/0x330
[  432.585122]  ? pci_pm_freeze+0xe0/0xe0
[  432.585125]  __device_suspend+0xea/0x330
[  432.585128]  async_suspend+0x1a/0x90
[  432.585132]  async_run_entry_fn+0x34/0x160
[  432.585137]  process_one_work+0x1f4/0x6d0
[  432.585140]  ? process_one_work+0x16e/0x6d0
[  432.585143]  worker_thread+0x49/0x4a0
[  432.585145]  kthread+0x107/0x140
[  432.585148]  ? process_one_work+0x6d0/0x6d0
[  432.585150]  ? kthread_create_on_node+0x40/0x40
[  432.585154]  ret_from_fork+0x2e/0x40
[  432.585156] ---[ end trace 6712df7f8c4b9124 ]---

The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.

Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Cc: Tvrtko Ursulin 
Cc: Jeff Kirsher 
Cc: Dave Ertman 
Cc: Bruce Allan 
Cc: intel-wired-...@lists.osuosl.org
Cc: net...@vger.kernel.org
Signed-off-by: Chris Wilson 
[Jani: bikeshed repainted]
Signed-off-by: Jani Nikula 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index b3679728caac..5cad688be609 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6630,12 +6630,17 @@ static int e1000e_pm_thaw(struct device *dev)
 static int e1000e_pm_suspend(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
+   int rc;
 
e1000e_flush_lpic(pdev);
 
e1000e_pm_freeze(dev);
 
-   return __e1000_shutdown(pdev, false);
+   rc = __e1000_shutdown(pdev, false);
+   if (rc)
+   e1000e_pm_thaw(dev);
+
+   return rc;
 }
 
 static int e1000e_pm_resume(struct device *dev)
-- 
2.11.0

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

[Intel-gfx] [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.

2017-05-31 Thread Maarten Lankhorst

On some systems there can be a race condition in which no crtc state is
added to the first atomic commit. This results in all crtc's having a
null DDB allocation, causing a FIFO underrun on any update until the
first modeset.

Changes since v1:
- Do not take the connection_mutex, this is already done below.

Reported-by: Maarten Lankhorst 
Inspired-by: Mahesh Kumar 
Signed-off-by: Maarten Lankhorst 
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc:  # v4.8+
Cc: Mahesh Kumar 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 936eef1634c7..fce4bc5ccc99 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4819,11 +4819,19 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct skl_wm_values *results = _state->wm_results;
+   struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
int ret, i;
 
/*
+* When we distrust bios wm we always need to recompute to set the
+* expected DDB allocations for each CRTC.
+*/
+   if (to_i915(dev)->wm.distrust_bios_wm)
+   changed = true;
+
+   /*
 * If this transaction isn't actually touching any CRTC's, don't
 * bother with watermark calculation.  Note that if we pass this
 * test, we're guaranteed to hold at least one CRTC state mutex,
@@ -4833,6 +4841,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 */
for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
+
if (!changed)
return 0;
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

2017-05-31 Thread Sharma, Shashank


Regards

Shashank


On 5/31/2017 6:11 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 10:00:12PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/30/2017 9:43 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej

Reviewed-by: Andrzej Hajda 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
   drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
   drivers/gpu/drm/bridge/sii902x.c  |  2 +-
   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
   drivers/gpu/drm/drm_edid.c| 12 +++-
   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
   drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
   drivers/gpu/drm/i915/intel_hdmi.c |  5 -
   drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
   drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
   drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
   drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
   drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
   drivers/gpu/drm/tegra/hdmi.c  |  2 +-
   drivers/gpu/drm/tegra/sor.c   |  2 +-
   drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
   drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
   include/drm/drm_edid.h|  3 ++-
   21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 3c62c45..4923ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
   
-	err = drm_hdmi_avi_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c8ed0fa..4101684 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
   
-	err = drm_hdmi_avi_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3e90c19..a7f6b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
   
-	err = drm_hdmi_avi_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void

Re: [Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

2017-05-31 Thread Sharma, Shashank


Regards

Shashank


On 5/31/2017 6:09 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 09:56:56PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/30/2017 9:48 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Still missing the "native bit" handling.

I tried searching the native bit handling in the code, but I could not
get any thing. We are typically doing a (vic & 127) and that's all.

And that's not really correct. We shouldn't discard the msb until we've
checked that we're in the correct range of VICs that have the native
bit. drm_display_mode_from_vic_index() is the place where we should be
checking this I think.
Yep, Even I looked into these function only for the native mode 
processing, But looks like

all its doing is:
vic = (video_db[video_index] & 127);

- Shashank

Can you please point out a bit here ?

- Shashank

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Harry Wentland 

V2: Rebase

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Acked-by: Harry Wentland 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c | 215 
+
   1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8b23435..c3fa3a1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080",

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/opregion: let user specify override VBT via firmware load

2017-05-31 Thread Patchwork

== Series Details ==

Series: drm/i915/opregion: let user specify override VBT via firmware load
URL   : https://patchwork.freedesktop.org/series/25105/
State : success

== Summary ==

Series 25105v1 drm/i915/opregion: let user specify override VBT via firmware 
load
https://patchwork.freedesktop.org/api/1.0/series/25105/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:439s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:574s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:516s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:429s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:415s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:487s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:567s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:462s
fi-skl-6700hqtotal:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  
time:436s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:467s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:502s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:405s

593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC 
integration manifest
58e54f2 drm/i915/opregion: let user specify override VBT via firmware load

== Logs ==

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

1 2 >

1 - 100 of 196 matches

Mail list logo