[Intel-gfx] [PATCH i-g-t] tests/gem_ctx_param_basic.c: fix non-root-set-no-zeromap subtest

[daniele . ceraolospurio]

From: Daniele Ceraolo Spurio 

The test expects an ioctl failure when it tries to set
CONTEXT_PARAM_NO_ZEROMAP from a non-root process. However, there is no
requirement in the kernel for the user to be root to set this parameter,
so the test is failing (it never passed as far as I'm aware of).
Fix the test by making it expect a successful ioctl completion.

Signed-off-by: Daniele Ceraolo Spurio 
---
 tests/gem_ctx_param_basic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/gem_ctx_param_basic.c b/tests/gem_ctx_param_basic.c
index ac5f038..4741821 100644
--- a/tests/gem_ctx_param_basic.c
+++ b/tests/gem_ctx_param_basic.c
@@ -127,7 +127,7 @@ igt_main
ctx_param.context = ctx;
TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_GETPARAM);
ctx_param.value--;
-   TEST_FAIL(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM, EPERM);
+   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
}
 
igt_waitchildren();
-- 
1.9.1

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

[Intel-gfx] [PULL] topic/drm-fixes for v4.3

[Jani Nikula]

Hi Dave -

An atomic bookkeeping fix from Maarten, and DP i2c-over-aux retry loop
fixes from Ville.

BR,
Jani.

The following changes since commit 879a37d00f1882b1e56a66e626af4194d592d257:

  Merge branch 'exynos-drm-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next 
(2015-08-31 10:25:45 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-fixes-2015-09-09

for you to fetch changes up to f36203be608a38a5b5523a7aa52cc72f757b9679:

  drm/dp: Add dp_aux_i2c_speed_khz module param to set the assume i2c bus speed 
(2015-09-02 16:13:43 +0300)


Maarten Lankhorst (1):
  drm/atomic: Fix bookkeeping with TEST_ONLY, v3.

Ville Syrjälä (3):
  drm/dp: Define AUX_RETRY_INTERVAL as 500 us
  drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus 
speed
  drm/dp: Add dp_aux_i2c_speed_khz module param to set the assume i2c bus 
speed

 drivers/gpu/drm/drm_atomic.c| 39 +---
 drivers/gpu/drm/drm_dp_helper.c | 99 ++---
 2 files changed, 117 insertions(+), 21 deletions(-)

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix broken mst get_hw_state.

[Jani Nikula]

On Thu, 03 Sep 2015, Ander Conselvan De Oliveira  wrote:
> On Wed, 2015-09-02 at 16:14 +0200, Maarten Lankhorst wrote:
>> Op 02-09-15 om 16:07 schreef Ander Conselvan De Oliveira:
>> > On Thu, 2015-08-27 at 13:13 +0200, Maarten Lankhorst wrote:
>> > > connector->encoder is initialized as NULL. Fix this by setting it in
>> > > during pre enable. MST connectors are not read out during initial hw
>> > > readout, and have no fixed encoder mappings. So it's harmless to
>> > > return false when the connector has never been assigned to an encoder.
>> > >
>> > > Signed-off-by: Maarten Lankhorst 
>> > > ---
>> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > > b/drivers/gpu/drm/i915/intel_display.c
>> > > index 738178a0ac96..e3922d973db0 100644
>> > > --- a/drivers/gpu/drm/i915/intel_display.c
>> > > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > > @@ -6283,7 +6283,7 @@ static void intel_connector_check_state(struct 
>> > > intel_connector 
>> > > *connector)
>> > >connector->base.name);
>> > >  
>> > >  if (connector->get_hw_state(connector)) {
>> > > -struct drm_encoder *encoder = >encoder->base;
>> > > +struct intel_encoder *encoder = connector->encoder;
>> > >  struct drm_connector_state *conn_state = 
>> > > connector->base.state;
>> > >  
>> > >  I915_STATE_WARN(!crtc,
>> > > @@ -6295,13 +6295,13 @@ static void intel_connector_check_state(struct 
>> > > intel_connector 
>> > > *connector)
>> > >  I915_STATE_WARN(!crtc->state->active,
>> > >"connector is active, but attached crtc isn't\n");
>> > >  
>> > > -if (!encoder)
>> > > +if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
>> > >  return;
>> > >  
>> > > -I915_STATE_WARN(conn_state->best_encoder != encoder,
>> > > +I915_STATE_WARN(conn_state->best_encoder != 
>> > > >base,
>> > >  "atomic encoder doesn't match attached 
>> > > encoder\n");
>> > >  
>> > > -I915_STATE_WARN(conn_state->crtc != encoder->crtc,
>> > > +I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
>> > >  "attached encoder crtc differs from connector 
>> > > crtc\n");
>> > >  } else {
>> > >  I915_STATE_WARN(crtc && crtc->state->active,
>> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
>> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
>> > > index ebf205462631..d606721b1788 100644
>> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
>> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
>> > > @@ -159,6 +159,11 @@ static void intel_mst_pre_enable_dp(struct 
>> > > intel_encoder *encoder)
>> > >  return;
>> > >  }
>> > >  
>> > > +/* MST encoders are bound to a crtc, not to a connector,
>> > > + * force the mapping here for get_hw_state.
>> > > + */
>> > > +found->encoder = encoder;
>> > > +
>> > >  DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
>> > >  intel_mst->port = found->port;
>> > >  
>> > > @@ -392,7 +397,7 @@ static const struct drm_encoder_funcs 
>> > > intel_dp_mst_enc_funcs = {
>> > >  
>> > >  static bool intel_dp_mst_get_hw_state(struct intel_connector *connector)
>> > >  {
>> > > -if (connector->encoder) {
>> > > +if (connector->encoder && connector->base.state->crtc) {
>> > Is this here to cover the case where we disable this connector and assign 
>> > the encoder to a 
>> > different
>> > connector? I guess this should work since if we disable the connector than 
>> > crtc will be null, 
>> > and
>> > we'll assign a proper encoder when re-enabling. But now I'm wondering if 
>> > it would make sense to 
>> > set
>> > connector->encoder back to NULL in post_disable.
>> > 
>> Yes, it's harmless to keep it non-null if conn_state->crtc is checked 
>> though. Saves another 
>> pointless loop.
>
> Fair enough.
>
> Reviewed-by: Ander Conselvan de Oliveira 

Pushed to drm-intel-next-fixes, thanks for the patch and review.

BR,
Jani.


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

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit the number of loops for reading a split 64bit register

[Jani Nikula]

On Tue, 08 Sep 2015, Daniel Vetter  wrote:
> On Tue, Sep 08, 2015 at 02:17:13PM +0100, Chris Wilson wrote:
>> In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
>> reads. Due to the nature of the registers we try to read in this manner,
>> they may increment between the two instruction (e.g. a timestamp
>> counter). To keep the result accurate, we repeat the read if we detect
>> an overflow (i.e. the upper value varies). However, some harware is just
>> plain flaky and may endless loop as the the upper 32bits are not stable.
>> Just give up after a couple of tries and report whatever we read last.
>> 
>> v2: Use the most recent values when erring out on an unstable register.
>> 
>> Reported-by: russianneuroman...@ya.ru
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91906
>> Signed-off-by: Chris Wilson 
>> Cc: Michał Winiarski 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: sta...@vger.kernel.org
>
> Still Reviewed-by: Daniel Vetter 

Pushed to drm-intel-next-fixes, thanks for the patch and review.

BR,
Jani.


>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 12870073d58f..51a88e70a6f7 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -3402,13 +3402,13 @@ int intel_freq_opcode(struct drm_i915_private 
>> *dev_priv, int val);
>>  #define I915_READ64(reg)dev_priv->uncore.funcs.mmio_readq(dev_priv, 
>> (reg), true)
>>  
>>  #define I915_READ64_2x32(lower_reg, upper_reg) ({   \
>> -u32 upper, lower, tmp;  \
>> -tmp = I915_READ(upper_reg); \
>> +u32 upper, lower, old_upper, loop = 0;  \
>> +upper = I915_READ(upper_reg);   \
>>  do {\
>> -upper = tmp;\
>> +old_upper = upper;  \
>>  lower = I915_READ(lower_reg);   \
>> -tmp = I915_READ(upper_reg); \
>> -} while (upper != tmp); \
>> +upper = I915_READ(upper_reg);   \
>> +} while (upper != old_upper && loop++ < 2); \
>>  (u64)upper << 32 | lower; })
>>  
>>  #define POSTING_READ(reg)   (void)I915_READ_NOTRACE(reg)
>> -- 
>> 2.5.1
>> 
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

[Intel-gfx] Skylake Linux 4.2 FIFO underruns

[Daniel Drake]

Hi,

Using Linux 4.2 on a new Skylake laptop, I frequently see the display
go momentarily black, with a coinciding message in the logs:

[drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun

Testing linus master, the problem is gone. Does anyone know what
commit might have fixed this? I would like to backport to 4.2.

I already tried cherry-picking the patches that mention skl that apply
trivially, and while that fixed some GPU hangs I was seeing, the FIFO
underrun is still present with 4.2 plus:

 drm/i915/skl: Retrieve the Rpe value from Pcode
 drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A
 drm/i915/skl WaDisableSbeCacheDispatchPortSharing
 drm/i915:skl: Add WaEnableGapsTsvCreditFix
 drm/i915/skl: Restrict the ring frequency table programming to SKL
 drm/i915/skl: Ring frequency table programming changes
 drm/i915/skl: Don't warn if reading back DPLL0 is disabled
 drm/i915: Move WaBarrierPerformanceFixDisable:skl to skl code from chv code
 drm/i915/skl: Don't try to store the wrong central frequency
 drm/i915/skl: Remove unnecessary () used with abs_diff()
 drm/i915/skl: Remove unnecessary () used with div_u64()
 drm/i915/skl: Factor out computing the DPLL paramaters from the dividers
 drm/i915/skl: Use a more idomatic early return
 drm/i915/skl: Propagate the error if we fail to find a suitable DPLL divider
 drm/i915/skl: Display the WRPLL frequency we couldn't accomodate when failing
 drm/i915/skl: Make sure to break when not finding suitable PLL dividers

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

Re: [Intel-gfx] [PATCH] drm/core: Do not call drm_framebuffer_remove internally during teardown.

[Daniel Vetter]

On Wed, Sep 9, 2015 at 1:51 PM, Ville Syrjälä
 wrote:
> On Wed, Sep 09, 2015 at 01:46:21PM +0200, Maarten Lankhorst wrote:
>> This may cause issues because encoders are already destroyed so removing
>> active primaries may use freed memory. Instead free the fb directly,
>> ignoring refcount.
>
> So what about fixing the cause, not the symptom? That is remove
> framebuffers before nuking crtc/encoders/etc.

Also by that point we shouldn't have any framebuffers left (the
WARN_ON is for that), so not sure what's the point of this patch.
-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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] Add a link training test

[Thomas Wood]

On 8 September 2015 at 13:28, Ander Conselvan de Oliveira
 wrote:
> This adds a test that compiles the link training code from i915 into a
> separate executable and uses it to train a fake sink device. The test
> also uses device information from i915 to exercise the different code
> paths for different hardwdare generations.
>
> In order to get the code to compile a lot of stubbing was necessary. It
> was also easier to copy a few functions from the drm_dp_helpers instead
> of getting the whole thing to compile as part of the test.
> ---
>  link-training-test/Makefile |  40 +++
>  link-training-test/drm_dp_helper.c  | 115 +
>  link-training-test/intel_drv.h  | 148 
>  link-training-test/link_training_test.c | 414 
> 
>  4 files changed, 717 insertions(+)
>  create mode 100644 link-training-test/Makefile
>  create mode 100644 link-training-test/drm_dp_helper.c
>  create mode 100644 link-training-test/intel_drv.h
>  create mode 100644 link-training-test/link_training_test.c
>
> diff --git a/link-training-test/Makefile b/link-training-test/Makefile

If this is meant to be part of the test suite, then it needs to be in
the tests directory and use the igt test infrastructure. Otherwise it
should be placed in tools or tools/link-training-test.


> new file mode 100644
> index 000..07a9914
> --- /dev/null
> +++ b/link-training-test/Makefile
> @@ -0,0 +1,40 @@
> +KERNEL_SRC_DIR=/home/aconselv/linux

It may be necassary to make the building of this test optional in
configure and provide a way of specifying the kernel source directory.


> +
> +# Files copied from i915 source tree
> +COPIED_SOURCES = \
> +   intel_dp_link_training.c \
> +   intel_dev_info.c \
> +   intel_dev_info.h \
> +   i915_reg.h
> +
> +INTEL_DP_LINK_TRAINING_C = 
> $(KERNEL_SRC_DIR)/drivers/gpu/drm/i915/intel_dp_link_training.c
> +
> +INCLUDEDIR = \
> +   -I$(KERNEL_SRC_DIR)/include/drm \
> +   -I$(KERNEL_SRC_DIR)/ \
> +   -I.
> +
> +DEFINES = \
> +   -D__KERNEL__
> +
> +HEADER_FILES = \
> +   intel_drv.h
> +
> +SOURCE_FILES = \
> +   intel_dp_link_training.c \
> +   link_training_test.c \
> +   drm_dp_helper.c
> +
> +all: link_training_test
> +
> +#intel_dp_link_training.c: $(INTEL_DP_LINK_TRAINING_C)
> +#  cp $(INTEL_DP_LINK_TRAINING_C) .
> +
> +$(COPIED_SOURCES): %: $(KERNEL_SRC_DIR)/drivers/gpu/drm/i915/%
> +   cp $< $@
> +
> +link_training_test: $(COPIED_SOURCES) $(SOURCE_FILES) $(HEADER_FILES)
> +   gcc -g3 -O0 -std=gnu99 -o link_training_test $(SOURCE_FILES) 
> $(INCLUDEDIR) $(DEFINES)
> +
> +clean:
> +   rm link_training_test $(COPIED_SOURCES)
> diff --git a/link-training-test/drm_dp_helper.c 
> b/link-training-test/drm_dp_helper.c
> new file mode 100644
> index 000..a8db7f9
> --- /dev/null
> +++ b/link-training-test/drm_dp_helper.c
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright © 2009 Keith Packard
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and 
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that 
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission.  The copyright holders make no representations
> + * about the suitability of this software for any purpose.  It is provided 
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF 
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + */
> +
> +#include "intel_drv.h"
> +
> +/* TODO: Get rid of this copy of drm_dp_helper functions. */
> +
> +static u8 dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r)
> +{
> +return link_status[r - DP_LANE0_1_STATUS];
> +}
> +
> +static u8 dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
> + int lane)
> +{
> +int i = DP_LANE0_1_STATUS + (lane >> 1);
> +int s = (lane & 1) * 4;
> +u8 l = dp_link_status(link_status, i);
> +return (l >> s) & 0xf;
> +}
> +
> +bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> +  int lane_count)
> +{
> +u8 lane_align;
> +u8 lane_status;
> +int lane;
> +
> +

Re: [Intel-gfx] [RFC] drm/i915: Handle E2BIG error in i915_gem_fault

[Chris Wilson]

On Wed, Sep 09, 2015 at 11:29:52AM +0100, Michel Thierry wrote:
> i915_gem_object_bind_to_vm returns -E2BIG when the user tries to bind an
> object larger than the aperture, but i915_gem_fault does not handle this
> return code:
> 
> [501906.530985] gem_mmap_gtt: starting subtest big-bo-tiledX
> [501906.541992] gem_mmap_gtt (22362): drop_caches: 3
> [501906.610774] WARNING: CPU: 2 PID: 22362 at
> drivers/gpu/drm/i915/i915_gem.c:1880 i915_gem_fault+0x24f/0x470 [i915]()
> [501906.623568] unhandled error in i915_gem_fault: -7
> [501906.825115] Call Trace:
> [501906.830322]  [] dump_stack+0x45/0x57
> [501906.838589]  [] warn_slowpath_common+0x8a/0xc0
> [501906.847846]  [] warn_slowpath_fmt+0x46/0x50
> [501906.856776]  [] i915_gem_fault+0x24f/0x470 [i915]
> [501906.866276]  [] __do_fault+0x3d/0xa0
> [501906.874464]  [] ? pte_alloc_one+0x30/0x50
> [501906.883169]  [] handle_mm_fault+0xe27/0x1810
> [501906.892202]  [] ? security_mmap_file+0xca/0xe0
> [501906.900389]  [] ? do_vfs_ioctl+0x2cd/0x4b0
> [501906.908143]  [] __do_page_fault+0x19a/0x430
> [501906.916024]  [] do_page_fault+0x22/0x30
> [501906.923532]  [] page_fault+0x28/0x30
> 
> RFC about the error code that should be returned by i915_gem_fault.

There are two fixes here, change E2BIG to ENOSPC. The differentiate is
painful to all consumers (and missing in userspace).

The second is that gem_fault was supposed to be fixed to handle it and
sigbus is the legimate error for that case (not enomem/sigsegv).
-Chris

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

Re: [Intel-gfx] [PATCH i-g-t] intel_reg: ensure "intel_reg help" always works

[Jani Nikula]

On Mon, 07 Sep 2015, Thomas Wood  wrote:
> Signed-off-by: Thomas Wood 

I'm lagging behind with my mails, and I see you already pushed
this... but care to explain the scenario where 'intel_reg help' does not
work? Should be part of the commit message...

BR,
Jani.

> ---
>  tools/intel_reg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/intel_reg.c b/tools/intel_reg.c
> index 95760db..2b3c686 100644
> --- a/tools/intel_reg.c
> +++ b/tools/intel_reg.c
> @@ -865,7 +865,7 @@ int main(int argc, char *argv[])
>   argc -= optind;
>   argv += optind;
>  
> - if (help)
> + if (help || (argc > 0 && strcmp(argv[0], "help") == 0))
>   return intel_reg_help(, argc, argv);
>  
>   if (argc == 0) {
> -- 
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Only update the current userptr worker

[Chris Wilson]

On Wed, Sep 09, 2015 at 11:39:01AM +0100, Tvrtko Ursulin wrote:
> 
> On 08/10/2015 09:51 AM, Chris Wilson wrote:
> >The userptr worker allows for a slight race condition where upon there
> >may two or more threads calling get_user_pages for the same object. When
> >we have the array of pages, then we serialise the update of the object.
> >However, the worker should only overwrite the obj->userptr.work pointer
> >if and only if it is the active one. Currently we clear it for a
> >secondary worker with the effect that we may rarely force a second
> >lookup.
> 
> v2 changelog?
> 
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/i915_gem_userptr.c | 32 
> > 
> >  1 file changed, 16 insertions(+), 16 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
> >b/drivers/gpu/drm/i915/i915_gem_userptr.c
> >index d11901d590ac..800a5394aa1e 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> >@@ -571,25 +571,25 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
> >*_work)
> > struct get_pages_work *work = container_of(_work, typeof(*work), work);
> > struct drm_i915_gem_object *obj = work->obj;
> > struct drm_device *dev = obj->base.dev;
> >-const int num_pages = obj->base.size >> PAGE_SHIFT;
> >+const int npages = obj->base.size >> PAGE_SHIFT;
> > struct page **pvec;
> > int pinned, ret;
> >
> > ret = -ENOMEM;
> > pinned = 0;
> >
> >-pvec = kmalloc(num_pages*sizeof(struct page *),
> >+pvec = kmalloc(npages*sizeof(struct page *),
> >GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
> > if (pvec == NULL)
> >-pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
> >+pvec = drm_malloc_ab(npages, sizeof(struct page *));
> > if (pvec != NULL) {
> > struct mm_struct *mm = obj->userptr.mm->mm;
> >
> > down_read(>mmap_sem);
> >-while (pinned < num_pages) {
> >+while (pinned < npages) {
> > ret = get_user_pages(work->task, mm,
> >  obj->userptr.ptr + pinned * 
> > PAGE_SIZE,
> >- num_pages - pinned,
> >+ npages - pinned,
> 
> If you hadn't done this renaming you could have gotten away without
> a v2 changelog request... :)

v2: rebase for some recent changes, rename to fix in 80 cols.

> >  !obj->userptr.read_only, 0,
> >  pvec + pinned, NULL);
> > if (ret < 0)
> >@@ -601,20 +601,20 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
> >*_work)
> > }
> >
> > mutex_lock(>struct_mutex);
> >-if (obj->userptr.work != >work) {
> >-ret = 0;
> >-} else if (pinned == num_pages) {
> >-ret = __i915_gem_userptr_set_pages(obj, pvec, num_pages);
> >-if (ret == 0) {
> >-list_add_tail(>global_list, 
> >_i915(dev)->mm.unbound_list);
> >-obj->get_page.sg = obj->pages->sgl;
> >-obj->get_page.last = 0;
> >-
> >-pinned = 0;
> >+if (obj->userptr.work == >work) {
> >+if (pinned == npages) {
> >+ret = __i915_gem_userptr_set_pages(obj, pvec, npages);
> >+if (ret == 0) {
> >+list_add_tail(>global_list,
> >+  _i915(dev)->mm.unbound_list);
> >+obj->get_page.sg = obj->pages->sgl;
> >+obj->get_page.last = 0;
> 
> Wouldn't obj->get_page init fit better into
> __i915_gem_userptr_set_pages? Although that code is not from this
> patch. How come it is OK not to initialize them in the non-worker
> case?

It's done for us, the worker is the special case. I wanted to write the
set_pages initialiser differently so I could avoid this code, but I did
not prevail.
-Chris

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

[Intel-gfx] [RFC] drm/i915: Handle E2BIG error in i915_gem_fault

[Michel Thierry]

i915_gem_object_bind_to_vm returns -E2BIG when the user tries to bind an
object larger than the aperture, but i915_gem_fault does not handle this
return code:

[501906.530985] gem_mmap_gtt: starting subtest big-bo-tiledX
[501906.541992] gem_mmap_gtt (22362): drop_caches: 3
[501906.610774] WARNING: CPU: 2 PID: 22362 at
drivers/gpu/drm/i915/i915_gem.c:1880 i915_gem_fault+0x24f/0x470 [i915]()
[501906.623568] unhandled error in i915_gem_fault: -7
[501906.825115] Call Trace:
[501906.830322]  [] dump_stack+0x45/0x57
[501906.838589]  [] warn_slowpath_common+0x8a/0xc0
[501906.847846]  [] warn_slowpath_fmt+0x46/0x50
[501906.856776]  [] i915_gem_fault+0x24f/0x470 [i915]
[501906.866276]  [] __do_fault+0x3d/0xa0
[501906.874464]  [] ? pte_alloc_one+0x30/0x50
[501906.883169]  [] handle_mm_fault+0xe27/0x1810
[501906.892202]  [] ? security_mmap_file+0xca/0xe0
[501906.900389]  [] ? do_vfs_ioctl+0x2cd/0x4b0
[501906.908143]  [] __do_page_fault+0x19a/0x430
[501906.916024]  [] do_page_fault+0x22/0x30
[501906.923532]  [] page_fault+0x28/0x30

RFC about the error code that should be returned by i915_gem_fault.

Testcase: igt/gem_mmap_gtt/big-bo-tiledXY
Reported-by: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 352ccd5..3e00f72 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1869,6 +1869,7 @@ out:
 */
ret = VM_FAULT_NOPAGE;
break;
+   case -E2BIG:
case -ENOMEM:
ret = VM_FAULT_OOM;
break;
-- 
2.5.1

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

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Add NV12 to primary plane programming.

[Ville Syrjälä]

On Wed, Sep 09, 2015 at 02:30:58AM +0300, Konduru, Chandra wrote:
> > > > > + if (fb->pixel_format == DRM_FORMAT_NV12) {
> > > > > + int height_in_mem = 
> > > > > (fb->offsets[1]/fb->pitches[0]);
> > > > > + /*
> > > > > +  * If UV starts from middle of a page, then UV 
> > > > > start
> > > > should
> > > > > +  * be programmed to beginning of that page. And 
> > > > > offset
> > > > into that
> > > > > +  * page to be programmed into y-offset
> > > > > +  */
> > > > > + tile_row_adjustment = height_in_mem % 
> > > > > tile_height;
> > > > > + aux_dist = fb->pitches[0] * (height_in_mem -
> > > > tile_row_adjustment);
> > > > > + aux_x_offset = DIV_ROUND_UP(x, 2);
> > > > > + aux_y_offset = DIV_ROUND_UP(y, 2) +
> > > > tile_row_adjustment;
> > > > > + /* For tile-Yf, uv-subplane tile width is 2x of 
> > > > > Y-subplane
> > > > */
> > > > > + aux_stride = fb->modifier[0] ==
> > > > I915_FORMAT_MOD_Yf_TILED ?
> > > > > + stride / 2 : stride;
> > > >
> > > > The 2x part was rather well hidden in the spec. How do we deal with
> > > > cases when the Y stride is an odd number of tiles?
> > >
> > > It should be a round up division to take care of that scenario.
> > 
> > That would stil lresult in a corrupted picture I think. So I was
> > thinking that we should just refuse to create NCV12 framebuffers with a
> > poorly aligned stride.
> > 
> I added a check in intel_framebuffer_init() which should catch them:
> if (mode_cmd->pitches[0] != mode_cmd->pitches[1]) {
> DRM_DEBUG("y and uv subplanes have different pitches\n");
> return -EINVAL;
> }

That won't catch the case I'm worried about. We would also need to make
sure pitches[1] is aligned to the UV tile width.

-- 
Ville Syrjälä
Intel OTC
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [Intel-gfx] [PATCH] drm/core: Do not call drm_framebuffer_remove internally during teardown.

[Ville Syrjälä]

On Wed, Sep 09, 2015 at 01:46:21PM +0200, Maarten Lankhorst wrote:
> This may cause issues because encoders are already destroyed so removing
> active primaries may use freed memory. Instead free the fb directly,
> ignoring refcount.

So what about fixing the cause, not the symptom? That is remove
framebuffers before nuking crtc/encoders/etc.

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 474f328535a1..9b9c4b41422a 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5742,7 +5742,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>*/
>   WARN_ON(!list_empty(>mode_config.fb_list));
>   list_for_each_entry_safe(fb, fbt, >mode_config.fb_list, head) {
> - drm_framebuffer_remove(fb);
> + drm_framebuffer_free(>refcount);
>   }
>  
>   list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
> -- 
> 2.1.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 06/11] drm: Define a drm_invalid_op ioctl implementation

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter  wrote:
> And use it in radeon to replace all the ioctls no longer valid in kms
> mode. I plan to also use this later on when nuking the ums support for
> i915.
>
> Note that setting the function pointer in the ioctl table to NULL
> would amount to the same, but that results in some debug output from
> the drm_ioctl() function. I've figured it's cleaner to have a
> special-purpose function.
>
> Cc: Alex Deucher 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_ioctl.c |  7 +++
>  drivers/gpu/drm/radeon/radeon_kms.c | 94 
> +++--
>  include/drm/drmP.h  |  2 +
>  3 files changed, 36 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 4d7f2677b2ea..f0b4f581f6ce 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -415,6 +415,13 @@ int drm_noop(struct drm_device *dev, void *data,
>  }
>  EXPORT_SYMBOL(drm_noop);
>
> +int drm_invalid_op(struct drm_device *dev, void *data,
> +  struct drm_file *file_priv)
> +{
> +   return -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_invalid_op);
> +

We could just store ERR_PTR(-EINVAL) in the ioctl-table and make the
ioctl-handler handle this. Anyway:

Reviewed-by: David Herrmann 

Thanks
David

>  /**
>   * Copy and IOCTL return string to user space
>   */
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 4a119c255ba9..03d285b30c83 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -844,74 +844,34 @@ int radeon_get_vblank_timestamp_kms(struct drm_device 
> *dev, int crtc,
>  drmcrtc, 
> >hwmode);
>  }
>
> -#define KMS_INVALID_IOCTL(name)  
>   \
> -static int name(struct drm_device *dev, void *data, struct drm_file\
> -   *file_priv) \
> -{  \
> -   DRM_ERROR("invalid ioctl with kms %s\n", __func__); \
> -   return -EINVAL; \
> -}
> -
> -/*
> - * All these ioctls are invalid in kms world.
> - */
> -KMS_INVALID_IOCTL(radeon_cp_init_kms)
> -KMS_INVALID_IOCTL(radeon_cp_start_kms)
> -KMS_INVALID_IOCTL(radeon_cp_stop_kms)
> -KMS_INVALID_IOCTL(radeon_cp_reset_kms)
> -KMS_INVALID_IOCTL(radeon_cp_idle_kms)
> -KMS_INVALID_IOCTL(radeon_cp_resume_kms)
> -KMS_INVALID_IOCTL(radeon_engine_reset_kms)
> -KMS_INVALID_IOCTL(radeon_fullscreen_kms)
> -KMS_INVALID_IOCTL(radeon_cp_swap_kms)
> -KMS_INVALID_IOCTL(radeon_cp_clear_kms)
> -KMS_INVALID_IOCTL(radeon_cp_vertex_kms)
> -KMS_INVALID_IOCTL(radeon_cp_indices_kms)
> -KMS_INVALID_IOCTL(radeon_cp_texture_kms)
> -KMS_INVALID_IOCTL(radeon_cp_stipple_kms)
> -KMS_INVALID_IOCTL(radeon_cp_indirect_kms)
> -KMS_INVALID_IOCTL(radeon_cp_vertex2_kms)
> -KMS_INVALID_IOCTL(radeon_cp_cmdbuf_kms)
> -KMS_INVALID_IOCTL(radeon_cp_getparam_kms)
> -KMS_INVALID_IOCTL(radeon_cp_flip_kms)
> -KMS_INVALID_IOCTL(radeon_mem_alloc_kms)
> -KMS_INVALID_IOCTL(radeon_mem_free_kms)
> -KMS_INVALID_IOCTL(radeon_mem_init_heap_kms)
> -KMS_INVALID_IOCTL(radeon_irq_emit_kms)
> -KMS_INVALID_IOCTL(radeon_irq_wait_kms)
> -KMS_INVALID_IOCTL(radeon_cp_setparam_kms)
> -KMS_INVALID_IOCTL(radeon_surface_alloc_kms)
> -KMS_INVALID_IOCTL(radeon_surface_free_kms)
> -
> -
>  const struct drm_ioctl_desc radeon_ioctls_kms[] = {
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_INIT, radeon_cp_init_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_START, radeon_cp_start_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_STOP, radeon_cp_stop_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_RESET, radeon_cp_reset_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_IDLE, radeon_cp_idle_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_CP_RESUME, radeon_cp_resume_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_RESET, radeon_engine_reset_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_FULLSCREEN, radeon_fullscreen_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_SWAP, radeon_cp_swap_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_CLEAR, radeon_cp_clear_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_VERTEX, radeon_cp_vertex_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_INDICES, radeon_cp_indices_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_TEXTURE, radeon_cp_texture_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_STIPPLE, radeon_cp_stipple_kms, DRM_AUTH),
> -   DRM_IOCTL_DEF_DRV(RADEON_INDIRECT, radeon_cp_indirect_kms, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Only update the current userptr worker

[Tvrtko Ursulin]

On 08/10/2015 09:51 AM, Chris Wilson wrote:

The userptr worker allows for a slight race condition where upon there
may two or more threads calling get_user_pages for the same object. When
we have the array of pages, then we serialise the update of the object.
However, the worker should only overwrite the obj->userptr.work pointer
if and only if it is the active one. Currently we clear it for a
secondary worker with the effect that we may rarely force a second
lookup.


v2 changelog?


Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem_userptr.c | 32 
  1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index d11901d590ac..800a5394aa1e 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -571,25 +571,25 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
struct get_pages_work *work = container_of(_work, typeof(*work), work);
struct drm_i915_gem_object *obj = work->obj;
struct drm_device *dev = obj->base.dev;
-   const int num_pages = obj->base.size >> PAGE_SHIFT;
+   const int npages = obj->base.size >> PAGE_SHIFT;
struct page **pvec;
int pinned, ret;

ret = -ENOMEM;
pinned = 0;

-   pvec = kmalloc(num_pages*sizeof(struct page *),
+   pvec = kmalloc(npages*sizeof(struct page *),
   GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
if (pvec == NULL)
-   pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
+   pvec = drm_malloc_ab(npages, sizeof(struct page *));
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;

down_read(>mmap_sem);
-   while (pinned < num_pages) {
+   while (pinned < npages) {
ret = get_user_pages(work->task, mm,
 obj->userptr.ptr + pinned * 
PAGE_SIZE,
-num_pages - pinned,
+npages - pinned,


If you hadn't done this renaming you could have gotten away without a v2 
changelog request... :)



 !obj->userptr.read_only, 0,
 pvec + pinned, NULL);
if (ret < 0)
@@ -601,20 +601,20 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
}

mutex_lock(>struct_mutex);
-   if (obj->userptr.work != >work) {
-   ret = 0;
-   } else if (pinned == num_pages) {
-   ret = __i915_gem_userptr_set_pages(obj, pvec, num_pages);
-   if (ret == 0) {
-   list_add_tail(>global_list, 
_i915(dev)->mm.unbound_list);
-   obj->get_page.sg = obj->pages->sgl;
-   obj->get_page.last = 0;
-
-   pinned = 0;
+   if (obj->userptr.work == >work) {
+   if (pinned == npages) {
+   ret = __i915_gem_userptr_set_pages(obj, pvec, npages);
+   if (ret == 0) {
+   list_add_tail(>global_list,
+ _i915(dev)->mm.unbound_list);
+   obj->get_page.sg = obj->pages->sgl;
+   obj->get_page.last = 0;


Wouldn't obj->get_page init fit better into 
__i915_gem_userptr_set_pages? Although that code is not from this patch. 
How come it is OK not to initialize them in the non-worker case?


With the v2 changelog, or dropped rename:

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

[Ville Syrjälä]

On Wed, Sep 09, 2015 at 02:51:58AM +0300, Konduru, Chandra wrote:
> > > > > +static void skl_wa_clkgate(struct drm_i915_private *dev_priv,
> > > > > + int pipe, int enable)
> > > > > +{
> > > > > + if (pipe == PIPE_A || pipe == PIPE_B) {
> > > > > + if (enable)
> > > > > + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > > > > + DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> > > > > + else
> > > > > + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > > > > + I915_READ(CLKGATE_DIS_PSL(pipe) &
> > > > > + ~(DUPS1_GATING_DIS|DUPS2_GATING_DIS)));
> > > > > + }
> > > > > +}
> > > > > +
> > > > >  static void haswell_crtc_enable(struct drm_crtc *crtc)
> > > > >  {
> > > > >   struct drm_device *dev = crtc->dev;
> > > > > @@ -5094,6 +5119,9 @@ static void haswell_crtc_enable(struct drm_crtc
> > > > *crtc)
> > > > >   intel_wait_for_vblank(dev, hsw_workaround_pipe);
> > > > >   intel_wait_for_vblank(dev, hsw_workaround_pipe);
> > > > >   }
> > > > > +
> > > > > + /* workaround for NV12 */
> > > > > + skl_wa_clkgate(dev_priv, pipe, 1);
> > > >
> > > > I wonder what's the cost of having this
> > > > a) always enabled
> > > > b) enabled when the pipe is enabled
> > > > c) enabled only when NV12 is used
> > > > ?
> > >
> > > Initially optimized to enable only when nv12 is used,
> > > but there are some corner cases when planes switch to and
> > > from nv12 to non-nv12 and SV recommendation is to enable
> > > always; and SV evaluated cost, and it isn't a big concern.
> > 
> > So, based on that we could just stuff it into init_clock_gating and
> > forget about it.
> 
> Couldn't include into init_clock_gating because this requires
> a pipe based check.

init_clock_gating()
{
...
enable for pipe A
enable for pipe B
...
}

or

for_each_pipe(pipe)
if (pipe != C)
enable w/a


> 
> By the way, so far 4 patches got RB tags.
> In the respun series 
> (http://lists.freedesktop.org/archives/intel-gfx/2015-September/075235.html
> addressed your feedback), those 4 tags goes to 1, 3, 5 and 8 of 15.
> Can you check updated patches and issue R-B tags for remaining ones?

I think your trigger finger is a bit overly sensitive :) We still had
open issues in this series so posting another one makes things somewhat
messy.

-- 
Ville Syrjälä
Intel OTC
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[Intel-gfx] [PATCH] drm/core: Do not call drm_framebuffer_remove internally during teardown.

[Maarten Lankhorst]

This may cause issues because encoders are already destroyed so removing
active primaries may use freed memory. Instead free the fb directly,
ignoring refcount.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 474f328535a1..9b9c4b41422a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5742,7 +5742,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
 */
WARN_ON(!list_empty(>mode_config.fb_list));
list_for_each_entry_safe(fb, fbt, >mode_config.fb_list, head) {
-   drm_framebuffer_remove(fb);
+   drm_framebuffer_free(>refcount);
}
 
list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH v4 4/5] drm: Add decoding of i915 ioctls

[Dmitry V. Levin]

On Tue, Sep 08, 2015 at 04:30:52AM +0300, Dmitry V. Levin wrote:
> On Tue, Sep 08, 2015 at 04:18:11AM +0300, Dmitry V. Levin wrote:
> [...]
> > So the whole function should look smth like this:
> > 
> > static int i915_getparam(struct tcb *tcp, const unsigned int code, long arg)
> > {
> > struct drm_i915_getparam param;
> > 
> > if (entering(tcp)) {
> > if (umove_or_printaddr(tcp, arg, ))
> > return RVAL_DECODED | 1;
> > tprints(", {param=");
> 
> or rather
>   tprints(", ");
>   if (umove_or_printaddr(tcp, arg, ))
>   return RVAL_DECODED | 1;
>   tprints("{param=");

or rather

static int
i915_getparam(struct tcb *tcp, const unsigned int code, const long arg)
{
struct drm_i915_getparam param;
int value;

if (entering(tcp)) {
tprints(", ");
if (umove_or_printaddr(tcp, arg, ))
return RVAL_DECODED | 1;
tprints("{param=");
printxval(drm_i915_getparams, param.param, "I915_PARAM_???");
return 0;
}

if (!umove(tcp, arg, )) {
tprints(", value=");
if (!umove_or_printaddr(tcp, (long) param.value, )) {
switch (param.param) {
case I915_PARAM_CHIPSET_ID:
tprintf("[%#04x]", value);
break;
default:
tprintf("[%d]", value);
}
}
}
tprints("}");
return 1;
}

Note that those structure members that are set by the kernel on exiting
syscall shouldn't normally be printed in case of syserror(tcp).

In case of i915_getparam, no extra check is needed because param.value is
an address supplied by userspace and umove_or_printaddr already performs
all necessary checks, but in other IOWR parsers you might want to use
if (!syserror(tcp) && !umove(tcp, arg, )) {
instead.


-- 
ldv


pgp9B2ipYt45y.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Split alloc from init for lrc

[Daniel, Thomas]

This needs a rebase as a new GuC TLB invalidation call has been added when the 
context objects are pinned.  Your patch misses this for the default context.  
In fact I reckon there's a case to consolidate the two (default / non-default) 
object pinning sequence into a single function to avoid further duplication or 
missing bits in future.

Also, as you're rebasing, see my nit-picks below.

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Nick Hoath
> Sent: Friday, September 4, 2015 2:49 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Daniel Vetter
> Subject: [Intel-gfx] [PATCH] drm/i915: Split alloc from init for lrc
> 
> Extend init/init_hw split to context init.
>- Move context initialisation in to i915_gem_init_hw
>- Move one off initialisation for render ring to
> i915_gem_validate_context
>- Move default context initialisation to logical_ring_init
> 
> Rename intel_lr_context_deferred_create to
> intel_lr_context_deferred_alloc, to reflect reduced functionality &
> alloc/init split.
> 
> This patch is intended to split out the allocation of resources &
> initialisation to allow easier reuse of code for resume/gpu reset.
> 
> v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
> Left ->init_context int intel_lr_context_deferred_alloc
> (Daniel Vetter)
> Remove unnecessary init flag & ring type test. (Daniel Vetter)
> Improve commit message (Daniel Vetter)
> v3: On init/reinit, set the hw next sequence number to the sw next
> sequence number. This is set to 1 at driver load time. This prevents
> the seqno being reset on reinit (Chris Wilson)
> v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
> on reset.
> This makes it obvious which bbs are which after a reset. (David Gordon
> & John Harrison)
> Rebase.
> 
> Issue: VIZ-4798
> Signed-off-by: Nick Hoath 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> Cc: John Harrison 
> Cc: David Gordon 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|   1 -
>  drivers/gpu/drm/i915/i915_gem.c|  24 +++--
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   3 +-
>  drivers/gpu/drm/i915/intel_lrc.c   | 155 
> ++---
>  drivers/gpu/drm/i915/intel_lrc.h   |   4 +-
>  5 files changed, 93 insertions(+), 94 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1287007..ded7158 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -888,7 +888,6 @@ struct intel_context {
>   } legacy_hw_ctx;
> 
>   /* Execlists */
> - bool rcs_initialized;
>   struct {
>   struct drm_i915_gem_object *state;
>   struct intel_ringbuffer *ringbuf;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 41263cd..c8125a5 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4613,14 +4613,8 @@ int i915_gem_init_rings(struct drm_device *dev)
>   goto cleanup_vebox_ring;
>   }
> 
> - ret = i915_gem_set_seqno(dev, ((u32)~0 - 0x1000));
> - if (ret)
> - goto cleanup_bsd2_ring;
> -
>   return 0;
> 
> -cleanup_bsd2_ring:
> - intel_cleanup_ring_buffer(_priv->ring[VCS2]);
>  cleanup_vebox_ring:
>   intel_cleanup_ring_buffer(_priv->ring[VECS]);
>  cleanup_blt_ring:
> @@ -4639,6 +4633,7 @@ i915_gem_init_hw(struct drm_device *dev)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_engine_cs *ring;
>   int ret, i, j;
> + struct drm_i915_gem_request *req;
Please leave req in the loop scope below to avoid unnecessary code churn.

> 
>   if (INTEL_INFO(dev)->gen < 6 && !intel_enable_gtt())
>   return -EIO;
> @@ -4706,9 +4701,16 @@ i915_gem_init_hw(struct drm_device *dev)
>   goto out;
>   }
> 
> + /*
> +  * Increment the next seqno by 0x100 so we have a visible break
> +  * on re-initialisation
> +  */
> + ret = i915_gem_set_seqno(dev, dev_priv->next_seqno+0x100);
> + if (ret)
> + goto out;
> +
>   /* Now it is safe to go back round and do everything else: */
>   for_each_ring(ring, dev_priv, i) {
> - struct drm_i915_gem_request *req;
> 
>   WARN_ON(!ring->default_context);
> 
> @@ -4907,6 +4909,14 @@ i915_gem_load(struct drm_device *dev)
>   dev_priv->num_fence_regs =
>   I915_READ(vgtif_reg(avail_rs.fence_num));
> 
> + /*
> +  * Set initial sequence number for requests.
> +  * Using this number allows the wraparound to happen early,
> +  * catching any obvious problems.
> +  */
> + dev_priv->next_seqno = ((u32)~0 - 

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_ctx_param_basic.c: fix non-root-set-no-zeromap subtest

[Thomas Wood]

On 9 September 2015 at 09:46,   wrote:
> From: Daniele Ceraolo Spurio 
>
> The test expects an ioctl failure when it tries to set
> CONTEXT_PARAM_NO_ZEROMAP from a non-root process. However, there is no
> requirement in the kernel for the user to be root to set this parameter,
> so the test is failing (it never passed as far as I'm aware of).
> Fix the test by making it expect a successful ioctl completion.

David, is this what you would expect?


>
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  tests/gem_ctx_param_basic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/gem_ctx_param_basic.c b/tests/gem_ctx_param_basic.c
> index ac5f038..4741821 100644
> --- a/tests/gem_ctx_param_basic.c
> +++ b/tests/gem_ctx_param_basic.c
> @@ -127,7 +127,7 @@ igt_main
> ctx_param.context = ctx;
> TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_GETPARAM);
> ctx_param.value--;
> -   TEST_FAIL(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM, 
> EPERM);
> +   TEST_SUCCESS(LOCAL_IOCTL_I915_GEM_CONTEXT_SETPARAM);
> }
>
> igt_waitchildren();
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/7] igt: adding parameter to drm_open_any and drm_open_any_master to allow specification of non-intel GPUs

[Thomas Wood]

On 14 August 2015 at 16:22, Micah Fedke  wrote:
> Changes since last version of patch:
>
> Now using the core_* tests as demonstrations rather than drm_read.

Apologies for not getting to this sooner, but it no longer applies to
master. Can you rebase the series and send it again?


>
> Micah Fedke (7):
>   lib: adding drm_open_driver() interface
>   convert drm_open_any*() calls to drm_open_driver*(DRIVER_INTEL) calls
> with cocci
>   lib: remove support for deprecated drm_open_any*() calls
>   tests: update core_get_client_auth to run on any platform
>   tests: update core_getversion to run on any platform
>   tests: update core_getclient to run on any platform
>   tests: update core_getstats to run on any platform
>
>  benchmarks/gem_userptr_benchmark.c   |  2 +-
>  benchmarks/intel_upload_blit_large.c |  2 +-
>  benchmarks/intel_upload_blit_large_gtt.c |  2 +-
>  benchmarks/intel_upload_blit_large_map.c |  2 +-
>  benchmarks/intel_upload_blit_small.c |  2 +-
>  debugger/eudb.c  |  2 +-
>  lib/drmtest.c| 97 
> 
>  lib/drmtest.h| 12 ++--
>  lib/igt_gt.c |  2 +-
>  lib/igt_kms.c|  2 +-
>  tests/core_get_client_auth.c |  6 +-
>  tests/core_getclient.c   |  2 +-
>  tests/core_getstats.c|  2 +-
>  tests/core_getversion.c  |  2 +-
>  tests/drm_import_export.c|  4 +-
>  tests/drm_read.c |  2 +-
>  tests/drm_vma_limiter.c  |  2 +-
>  tests/drm_vma_limiter_cached.c   |  2 +-
>  tests/drm_vma_limiter_cpu.c  |  2 +-
>  tests/drm_vma_limiter_gtt.c  |  2 +-
>  tests/drv_getparams.c|  2 +-
>  tests/drv_hangman.c  |  4 +-
>  tests/drv_suspend.c  |  2 +-
>  tests/eviction_common.c  |  2 +-
>  tests/gem_alive.c|  2 +-
>  tests/gem_bad_address.c  |  2 +-
>  tests/gem_bad_batch.c|  2 +-
>  tests/gem_bad_blit.c |  2 +-
>  tests/gem_bad_length.c   |  2 +-
>  tests/gem_bad_reloc.c|  2 +-
>  tests/gem_basic.c|  2 +-
>  tests/gem_caching.c  |  2 +-
>  tests/gem_concurrent_blit.c  |  4 +-
>  tests/gem_cpu_reloc.c|  2 +-
>  tests/gem_cs_prefetch.c  |  2 +-
>  tests/gem_cs_tlb.c   |  2 +-
>  tests/gem_ctx_bad_destroy.c  |  2 +-
>  tests/gem_ctx_bad_exec.c |  2 +-
>  tests/gem_ctx_basic.c|  4 +-
>  tests/gem_ctx_create.c   |  2 +-
>  tests/gem_ctx_exec.c |  2 +-
>  tests/gem_ctx_param_basic.c  |  2 +-
>  tests/gem_ctx_thrash.c   |  4 +-
>  tests/gem_double_irq_loop.c  |  2 +-
>  tests/gem_dummy_reloc_loop.c |  4 +-
>  tests/gem_evict_alignment.c  |  2 +-
>  tests/gem_evict_everything.c |  2 +-
>  tests/gem_exec_bad_domains.c |  2 +-
>  tests/gem_exec_big.c |  2 +-
>  tests/gem_exec_blt.c |  2 +-
>  tests/gem_exec_faulting_reloc.c  |  2 +-
>  tests/gem_exec_lut_handle.c  |  2 +-
>  tests/gem_exec_nop.c |  2 +-
>  tests/gem_exec_params.c  |  2 +-
>  tests/gem_exec_parse.c   |  2 +-
>  tests/gem_fd_exhaustion.c|  2 +-
>  tests/gem_fence_thrash.c |  2 +-
>  tests/gem_fence_upload.c |  8 +--
>  tests/gem_fenced_exec_thrash.c   |  2 +-
>  tests/gem_flink.c|  6 +-
>  tests/gem_flink_race.c   |  6 +-
>  tests/gem_gpgpu_fill.c   |  2 +-
>  tests/gem_gtt_cpu_tlb.c  |  2 +-
>  tests/gem_gtt_hog.c  |  4 +-
>  tests/gem_gtt_speed.c|  2 +-
>  tests/gem_hang.c |  2 +-
>  tests/gem_hangcheck_forcewake.c  |  2 +-
>  tests/gem_largeobject.c  |  2 +-
>  tests/gem_linear_blits.c |  2 +-
>  tests/gem_lut_handle.c   |  2 +-
>  tests/gem_madvise.c  |  8 +--
>  tests/gem_media_fill.c   |  2 +-
>  tests/gem_mmap.c |  2 +-
>  tests/gem_mmap_gtt.c |  4 +-
>  tests/gem_mmap_offset_exhaustion.c   |  2 +-
>  tests/gem_mmap_wc.c  |  2 +-
>  tests/gem_multi_bsd_sync_loop.c  |  4 +-
>  tests/gem_non_secure_batch.c |  2 +-
>  tests/gem_partial_pwrite_pread.c |  2 +-
>  tests/gem_persistent_relocs.c|  2 +-
>  tests/gem_pin.c  

Re: [Intel-gfx] [PATCH 3/3] drm: Make drm_av_sync_delay() 'mode' argument const

[Alex Deucher]

On Mon, Sep 7, 2015 at 11:22 AM,   wrote:
> From: Ville Syrjälä 
>
> drm_av_sync_delay() doesn't change the passed in mode, so make it const.
>
> Signed-off-by: Ville Syrjälä 

For the series:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_edid.c | 2 +-
>  include/drm/drm_edid.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e32218f..d895556 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3361,7 +3361,7 @@ EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
>   * the sink doesn't support audio or video.
>   */
>  int drm_av_sync_delay(struct drm_connector *connector,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
>  {
> int i = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> int a, v;
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 31528d9..2af9769 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -326,7 +326,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid);
>  int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
>  int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
>  int drm_av_sync_delay(struct drm_connector *connector,
> - struct drm_display_mode *mode);
> + const struct drm_display_mode *mode);
>  struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
>  int drm_load_edid_firmware(struct drm_connector *connector);
>
> --
> 2.4.6
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm: Make drm_av_sync_delay() 'mode' argument const

[Daniel Vetter]

On Wed, Sep 09, 2015 at 08:45:14AM -0400, Alex Deucher wrote:
> On Mon, Sep 7, 2015 at 11:22 AM,   wrote:
> > From: Ville Syrjälä 
> >
> > drm_av_sync_delay() doesn't change the passed in mode, so make it const.
> >
> > Signed-off-by: Ville Syrjälä 
> 
> For the series:
> Reviewed-by: Alex Deucher 

Applied to drm-misc, thanks for patches
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 2 +-
> >  include/drm/drm_edid.h | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index e32218f..d895556 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3361,7 +3361,7 @@ EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
> >   * the sink doesn't support audio or video.
> >   */
> >  int drm_av_sync_delay(struct drm_connector *connector,
> > - struct drm_display_mode *mode)
> > + const struct drm_display_mode *mode)
> >  {
> > int i = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> > int a, v;
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 31528d9..2af9769 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -326,7 +326,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> > struct edid *edid);
> >  int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
> >  int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
> >  int drm_av_sync_delay(struct drm_connector *connector,
> > - struct drm_display_mode *mode);
> > + const struct drm_display_mode *mode);
> >  struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
> >  int drm_load_edid_firmware(struct drm_connector *connector);
> >
> > --
> > 2.4.6
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/3] tools/intel_reg: Use pci device from config on write

[Thomas Wood]

On 28 August 2015 at 16:16, Jani Nikula  wrote:
> On Fri, 28 Aug 2015, Mika Kuoppala  wrote:
>> Use the pre configured pci device from config also
>> in write path.
>>
>> Cc: Jani Nikula 
>> Signed-off-by: Mika Kuoppala 
>> ---
>>  tools/intel_reg.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/intel_reg.c b/tools/intel_reg.c
>> index 190aa5b..2b60a83 100644
>> --- a/tools/intel_reg.c
>> +++ b/tools/intel_reg.c
>> @@ -439,7 +439,7 @@ static int intel_reg_write(struct config *config, int 
>> argc, char *argv[])
>>   return EXIT_FAILURE;
>>   }
>>
>> - intel_register_access_init(intel_get_pci_device(), 0);
>> + intel_register_access_init(config->pci_dev, 0);
>
> Whoops, my bad.
>
> Reviewed-by: Jani Nikula 

Thanks, I've pushed this patch. The other two patches in this series
can be pushed once any of the review comments have been addressed.


>
>
>>
>>   for (i = 1; i < argc; i += 2) {
>>   struct reg reg;
>> --
>> 2.1.4
>>
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tools/Android.mk: Fix compile error in intel_reg.c

[Derek Morton]

The patch "tools: install the register definition files" caused
a build error on android as it added 'PKGDATADIR' which was not
defined in the Android build environment. This patch adds that
define to tools/Android.mk. It also copies the files it points
to so they are actually in the target file system.
---
 tools/Android.mk | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/Android.mk b/tools/Android.mk
index 0a196e4..aae7db5 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -34,11 +34,18 @@ define add_tool
   libdrm\
   libdrm_intel
 
+LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools
+LOCAL_CFLAGS += 
-DPKGDATADIR=\"/system/vendor/intel/validation/core/igt/tools\"
 include $(BUILD_EXECUTABLE)
 endef
 
 ##
 
+# Copy the register files
+$(shell mkdir -p 
$(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools/registers)
+$(shell cp $(LOCAL_PATH)/registers/* 
$(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools/registers)
+
+
 skip_tools_list := \
 intel_framebuffer_dump \
 intel_reg_dumper \
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH i-g-t] tools/Android.mk: Fix compile error in intel_reg.c

[Thomas Wood]

On 9 September 2015 at 14:30, Derek Morton  wrote:
> The patch "tools: install the register definition files" caused
> a build error on android as it added 'PKGDATADIR' which was not
> defined in the Android build environment. This patch adds that
> define to tools/Android.mk. It also copies the files it points
> to so they are actually in the target file system.

Missing Signed-off-by line.

> ---
>  tools/Android.mk | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/tools/Android.mk b/tools/Android.mk
> index 0a196e4..aae7db5 100644
> --- a/tools/Android.mk
> +++ b/tools/Android.mk
> @@ -34,11 +34,18 @@ define add_tool
>libdrm\
>libdrm_intel
>
> +LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools

Is this part of the same fix?


> +LOCAL_CFLAGS += 
> -DPKGDATADIR=\"/system/vendor/intel/validation/core/igt/tools\"

This should have /registers on the end. Might be worth having a local
variable to avoid specifying the path explicitly each time.


>  include $(BUILD_EXECUTABLE)
>  endef
>
>  ##
>
> +# Copy the register files
> +$(shell mkdir -p 
> $(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools/registers)
> +$(shell cp $(LOCAL_PATH)/registers/* 
> $(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools/registers)
> +
> +
>  skip_tools_list := \
>  intel_framebuffer_dump \
>  intel_reg_dumper \
> --
> 1.9.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Michał Winiarski]

Softpin allows userspace to take greater control of GPU virtual address
space and eliminates the need of relocations. It can also be used to
mirror addresses between GPU and CPU (shared virtual memory).
Calls to drm_intel_bo_emit_reloc are still required to build the list of
drm_i915_gem_exec_objects at exec time, but no entries in relocs are
created. Self-relocs don't make any sense for softpinned objects and can
indicate a programming errors, thus are forbidden. Softpinned objects
are marked by asterisk in debug dumps.

Cc: Thomas Daniel 
Cc: Kristian Høgsberg 
Cc: Zou Nanhai 
Cc: Michel Thierry 
Cc: Ben Widawsky 
Cc: Chris Wilson 
Signed-off-by: Michał Winiarski 
---
 include/drm/i915_drm.h|   4 +-
 intel/intel_bufmgr.c  |   9 +++
 intel/intel_bufmgr.h  |   1 +
 intel/intel_bufmgr_gem.c  | 176 --
 intel/intel_bufmgr_priv.h |   7 ++
 5 files changed, 173 insertions(+), 24 deletions(-)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..2b99fc6 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_REVISION  32
 #define I915_PARAM_SUBSLICE_TOTAL   33
 #define I915_PARAM_EU_TOTAL 34
+#define I915_PARAM_HAS_EXEC_SOFTPIN 37
 
 typedef struct drm_i915_getparam {
int param;
@@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
 #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
 #define EXEC_OBJECT_NEEDS_GTT  (1<<1)
 #define EXEC_OBJECT_WRITE  (1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_PINNED (1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
__u64 flags;
 
__u64 rsvd1;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 14ea9f9..bd92335 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -261,6 +261,15 @@ drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t * 
tiling_mode,
 }
 
 int
+drm_intel_bo_set_softpin_offset(drm_intel_bo *bo, uint64_t offset)
+{
+   if (bo->bufmgr->bo_set_softpin_offset)
+   return bo->bufmgr->bo_set_softpin_offset(bo, offset);
+
+   return -ENODEV;
+}
+
+int
 drm_intel_bo_disable_reuse(drm_intel_bo *bo)
 {
if (bo->bufmgr->bo_disable_reuse)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 95eecb8..62ea4a0 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -164,6 +164,7 @@ int drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t * 
tiling_mode,
 int drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name);
 int drm_intel_bo_busy(drm_intel_bo *bo);
 int drm_intel_bo_madvise(drm_intel_bo *bo, int madv);
+int drm_intel_bo_set_softpin_offset(drm_intel_bo *bo, uint64_t offset);
 
 int drm_intel_bo_disable_reuse(drm_intel_bo *bo);
 int drm_intel_bo_is_reusable(drm_intel_bo *bo);
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2723e21..615741c 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -184,6 +184,13 @@ struct _drm_intel_bo_gem {
drm_intel_reloc_target *reloc_target_info;
/** Number of entries in relocs */
int reloc_count;
+   /** Array of BOs that are referenced by this buffer and will be 
softpinned */
+   drm_intel_bo **softpin_target;
+   /** Number softpinned BOs that are referenced by this buffer */
+   int softpin_target_count;
+   /** Maximum amount of softpinned BOs that are referenced by this buffer 
*/
+   int softpin_target_size;
+
/** Mapped address for the buffer, saved across map/unmap cycles */
void *mem_virtual;
/** GTT virtual address for the buffer, saved across map/unmap cycles */
@@ -237,6 +244,11 @@ struct _drm_intel_bo_gem {
bool is_userptr;
 
/**
+* Whether this buffer is softpinned at offset specified by the user
+*/
+   bool is_softpin;
+
+   /**
 * Size in bytes of this buffer and its relocation descendents.
 *
 * Used to avoid costly tree walking in
@@ -384,8 +396,9 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem 
*bufmgr_gem)
drm_intel_bo *bo = bufmgr_gem->exec_bos[i];
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
 
-   if (bo_gem->relocs == NULL) {
-   DBG("%2d: %d (%s)\n", i, bo_gem->gem_handle,
+   if (bo_gem->relocs == NULL && bo_gem->softpin_target == NULL) {
+   DBG("%2d: %d %s(%s)\n", i, bo_gem->gem_handle,
+   bo_gem->is_softpin ? "*" : "",
bo_gem->name);
continue;
}
@@ -395,16 +408,33 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem 
*bufmgr_gem)

[Intel-gfx] [RFC libdrm] intel: Softpin support

[Michał Winiarski]

The goal of this series is to start a discussion whether the interface and
implementation of softpin support proposed for libdrm is acceptable by all
interested parties.
The i915 patches are added so that it's easy to apply the series on latest
drm-intel-nightly and libdrm master and start using softpin.

Michał Winiarski (1):
  drm/i915/gtt: Allow adventurous users to select enable_ppgtt=3
is not strictly necessary for softpin itself, but it is needed for SVM usecase.

Chris Wilson (1):
  drm/i915: Add soft-pinning API for execbuffer
is just v5 from Thomas Daniel rebased on top of current nightly.

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

[Intel-gfx] [PATCH 1/2] drm/i915/gtt: Allow adventurous users to select enable_ppgtt=3

[Michał Winiarski]

While support for 48b ppgtt is here, parameter enabling it is not known
to the sanitize function. Let's update it to allow selecting
full_48bit_ppgtt using module parameter.

Cc: Michel Thierry 
Cc: Mika Kuoppala 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8786281..f598d63 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -104,9 +104,11 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
 {
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
+   bool has_full_48bit_ppgtt;
 
has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
+   has_full_48bit_ppgtt = INTEL_INFO(dev)->gen >= 9 || IS_BROADWELL(dev);
 
if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
@@ -125,6 +127,9 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
if (enable_ppgtt == 2 && has_full_ppgtt)
return 2;
 
+   if (enable_ppgtt == 3 && has_full_48bit_ppgtt)
+   return 3;
+
 #ifdef CONFIG_INTEL_IOMMU
/* Disable ppgtt on SNB if VT-d is on. */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) {
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Add soft-pinning API for execbuffer

[Chris Wilson]

On Wed, Sep 09, 2015 at 04:07:09PM +0200, Michał Winiarski wrote:
> From: Chris Wilson 
> 
> Userspace can pass in an offset that it presumes the object is located
> at. The kernel will then do its utmost to fit the object into that
> location. The assumption is that userspace is handling its own object
> locations (for example along with full-ppgtt) and that the kernel will
> rarely have to make space for the user's requests.
> 
> v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by 
> Chris
> Wilson.  Fixed incorrect error paths causing crash found by Michal Winiarski.
> (Not published externally)
> 
> v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed eviction
> to allow eviction of soft-pinned objects when another soft-pinned object used
> by a subsequent execbuffer overlaps reported by Michal Winiarski.
> (Not published externally)
> 
> v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
> pinned first after an address conflict happens to avoid repeated conflicts in
> rare cases (Suggested by Chris Wilson).  Expanded comment on
> drm_i915_gem_exec_object2.offset to cover this new API.
> 
> v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability
> (Kristian). Added check for multiple pinnings on eviction (Akash). Made sure
> buffers are not considered misplaced without the user specifying
> EXEC_OBJECT_SUPPORTS_48BBADDRESS.  User must assume responsibility for any
> addressing workarounds.  Updated object2.offset field comment again to clarify
> NO_RELOC case (Chris).  checkpatch cleanup.
> 
> v6: Rebase on top of current nightly. Dropped any references to
> EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in upstream
> yet, and are not a dependency.
> 
> Cc: Chris Wilson 
> Cc: Akash Goel 
> Cc: Vinay Belgaumkar 
> Cc: Michal Winiarski 
> Cc: Zou Nanhai 
> Cc: Kristian Høgsberg 
> Signed-off-by: Chris Wilson 
> Signed-off-by: Thomas Daniel 
> Signed-off-by: Michał Winiarski 

Again, the precursors are not included in this series or upstream, so
NAK.
-Chris

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

Re: [Intel-gfx] [PATCH 01/11] drm: Remove __OS_HAS_AGP

[Ville Syrjälä]

On Tue, Sep 08, 2015 at 01:56:21PM +0200, Daniel Vetter wrote:
> We already express the drm/agp depencies correctly in Kconfig, so we
> can rip this remnant from the shared drm core days.
> 
> Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
> if ttm would provide dummy functions. I'm not going to volunteer for
> that though.
> 
> v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/Makefile |  3 ++-
>  drivers/gpu/drm/drm_agpsupport.c |  4 ++--
>  drivers/gpu/drm/drm_bufs.c   |  6 +++---
>  drivers/gpu/drm/drm_ioc32.c  |  6 +++---
>  drivers/gpu/drm/drm_ioctl.c  |  2 +-
>  drivers/gpu/drm/drm_memory.c |  6 +++---
>  drivers/gpu/drm/drm_vm.c |  8 
>  drivers/gpu/drm/mga/mga_dma.c|  4 ++--
>  drivers/gpu/drm/nouveau/nouveau_bo.c |  8 
>  drivers/gpu/drm/r128/r128_cce.c  | 12 ++--
>  drivers/gpu/drm/radeon/r600_cp.c | 14 +++---
>  drivers/gpu/drm/radeon/radeon_agp.c  |  8 
>  drivers/gpu/drm/radeon/radeon_cp.c   | 16 
>  drivers/gpu/drm/radeon/radeon_ttm.c  | 10 +-
>  include/drm/drm_agpsupport.h |  6 +++---
>  15 files changed, 57 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 45e7719846b1..f458d6e33655 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -6,7 +6,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
>   drm_context.o drm_dma.o \
>   drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>   drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> - drm_agpsupport.o drm_scatter.o drm_pci.o \
> + drm_scatter.o drm_pci.o \
>   drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
>   drm_crtc.o drm_modes.o drm_edid.o \
>   drm_info.o drm_debugfs.o drm_encoder_slave.o \
> @@ -19,6 +19,7 @@ drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>  drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
> +drm-$(CONFIG_AGP) += drm_agpsupport.o
>  
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index 4b2b4aa5033b..4dc85ec7aca1 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -36,7 +36,7 @@
>  #include 
>  #include "drm_legacy.h"
>  
> -#if __OS_HAS_AGP
> +#if IS_ENABLED(CONFIG_AGP)

Since you make drm_agpsupport.o build depend on CONFIG_AGP, I suppose
you could drop the #if entirely from drm_agpsupport.c?

>  
>  #include 
>  
> @@ -503,4 +503,4 @@ drm_agp_bind_pages(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_agp_bind_pages);
>  
> -#endif /* __OS_HAS_AGP */
> +#endif /* CONFIG_AGP */

> diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
> index 055dc058d147..3d0833c63af2 100644
> --- a/include/drm/drm_agpsupport.h
> +++ b/include/drm/drm_agpsupport.h

Not removing the __OS_HAS_AGP define itself?

> @@ -28,7 +28,7 @@ struct drm_agp_head {
>   unsigned long page_mask;
>  };
>  
> -#if __OS_HAS_AGP
> +#ifdef CONFIG_AGP

Should use IS_ENABLED(CONFIG_AGP) as well.

Otherwise the patch looks good to me, so with that fixed
Reviewed-by: Ville Syrjälä 

>  
>  void drm_free_agp(struct agp_memory * handle, int pages);
>  int drm_bind_agp(struct agp_memory * handle, unsigned int start);
> @@ -66,7 +66,7 @@ int drm_agp_bind(struct drm_device *dev, struct 
> drm_agp_binding *request);
>  int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
>  
> -#else /* __OS_HAS_AGP */
> +#else /* CONFIG_AGP */
>  
>  static inline void drm_free_agp(struct agp_memory * handle, int pages)
>  {
> @@ -194,6 +194,6 @@ static inline int drm_agp_bind_ioctl(struct drm_device 
> *dev, void *data,
>   return -ENODEV;
>  }
>  
> -#endif /* __OS_HAS_AGP */
> +#endif /* CONFIG_AGP */
>  
>  #endif /* _DRM_AGPSUPPORT_H_ */
> -- 
> 2.5.1

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

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Remove setparam ioctl

[Ville Syrjälä]

On Tue, Sep 08, 2015 at 01:56:24PM +0200, Daniel Vetter wrote:
> This was only used for the ums+gem combo, so ripe for removal now that
> we only have kms code left.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 31 +--
>  1 file changed, 1 insertion(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index e267bc21b453..b1bcb7e8540a 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -184,35 +184,6 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   return 0;
>  }
>  
> -static int i915_setparam(struct drm_device *dev, void *data,
> -  struct drm_file *file_priv)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - drm_i915_setparam_t *param = data;
> -
> - switch (param->param) {
> - case I915_SETPARAM_USE_MI_BATCHBUFFER_START:
> - case I915_SETPARAM_TEX_LRU_LOG_GRANULARITY:
> - case I915_SETPARAM_ALLOW_BATCHBUFFER:
> - /* Reject all old ums/dri params. */
> - return -ENODEV;
> -
> - case I915_SETPARAM_NUM_USED_FENCES:
> - if (param->value > dev_priv->num_fence_regs ||
> - param->value < 0)
> - return -EINVAL;
> - /* Userspace can use first N regs */
> - dev_priv->fence_reg_start = param->value;

fence_reg_start can now be killed, no?

> - break;
> - default:
> - DRM_DEBUG_DRIVER("unknown parameter %d\n",
> - param->param);
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
>  static int i915_get_bridge_dev(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -1254,7 +1225,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, drm_noop, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, drm_noop, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> + DRM_IOCTL_DEF_DRV(I915_SETPARAM, drm_noop, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -- 
> 2.5.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH] drm/core: Do not call drm_framebuffer_remove internally during teardown.

[Maarten Lankhorst]

Op 09-09-15 om 13:59 schreef Daniel Vetter:
> On Wed, Sep 9, 2015 at 1:51 PM, Ville Syrjälä
>  wrote:
>> On Wed, Sep 09, 2015 at 01:46:21PM +0200, Maarten Lankhorst wrote:
>>> This may cause issues because encoders are already destroyed so removing
>>> active primaries may use freed memory. Instead free the fb directly,
>>> ignoring refcount.
>> So what about fixing the cause, not the symptom? That is remove
>> framebuffers before nuking crtc/encoders/etc.
> Also by that point we shouldn't have any framebuffers left (the
> WARN_ON is for that), so not sure what's the point of this patch.
> -Daniel
Yes, but the current way would crash on atomic because encoders are already 
done. This removes a caller of drm_framebuffer_remove and uses the correct 
destroy function regardless even when refcounts are leaked. :)

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

Re: [Intel-gfx] [PATCH i-g-t] intel_reg: ensure "intel_reg help" always works

[Thomas Wood]

On 9 September 2015 at 13:20, Jani Nikula  wrote:
> On Mon, 07 Sep 2015, Thomas Wood  wrote:
>> Signed-off-by: Thomas Wood 
>
> I'm lagging behind with my mails, and I see you already pushed
> this... but care to explain the scenario where 'intel_reg help' does not
> work? Should be part of the commit message...

The "help" variable is only set by the --help option, so if the user
specified "help" as a command, some initialisation takes place that
would cause an assert on (for example) platforms without an Intel GPU.
There are a few other commands that could work on systems without an
Intel GPU such as decoding register values, but this will need a bit
more work to implement.



>
> BR,
> Jani.
>
>> ---
>>  tools/intel_reg.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/intel_reg.c b/tools/intel_reg.c
>> index 95760db..2b3c686 100644
>> --- a/tools/intel_reg.c
>> +++ b/tools/intel_reg.c
>> @@ -865,7 +865,7 @@ int main(int argc, char *argv[])
>>   argc -= optind;
>>   argv += optind;
>>
>> - if (help)
>> + if (help || (argc > 0 && strcmp(argv[0], "help") == 0))
>>   return intel_reg_help(, argc, argv);
>>
>>   if (argc == 0) {
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: Fix userptr deadlock with aliased GTT mmappings

[Tvrtko Ursulin]

Hi,

On 08/10/2015 09:51 AM, Chris Wilson wrote:
> Michał Winiarski found a really evil way to trigger a struct_mutex
> deadlock with userptr. He found that if he allocated a userptr bo and
> then GTT mmaped another bo, or even itself, at the same address as the
> userptr using MAP_FIXED, he could then cause a deadlock any time we then
> had to invalidate the GTT mmappings (so at will). Tvrtko then found by
> repeatedly allocating GTT mmappings he could alias with an old userptr
> mmap and also trigger the deadlock.
> 
> To counter act the deadlock, we make the observation that we only need
> to take the struct_mutex if the object has any pages to revoke, and that
> before userspace can alias with the userptr address space, it must have
> invalidated the userptr->pages. Thus if we can check for those pages
> outside of the struct_mutex, we can avoid the deadlock. To do so we
> introduce a separate flag for userptr objects that we can inspect from
> the mmu-notifier underneath its spinlock.
> 
> The patch makes one eye-catching change. That is the removal serial=0
> after detecting a to-be-freed object inside the invalidate walker. I
> felt setting serial=0 was a questionable pessimisation: it denies us the
> chance to reuse the current iterator for the next loop (before it is
> freed) and being explicit makes the reader question the validity of the
> locking (since the object-free race could occur elsewhere). The
> serialisation of the iterator is through the spinlock, if the object is
> freed before the next loop then the notifier.serial will be incremented
> and we start the walk from the beginning as we detect the invalid cache.
> 
> To try and tame the error paths and interactions with the userptr->active
> flag, we have to do a fair amount of rearranging of get_pages_userptr().
> 
> v2: Grammar fixes
> v3: Reorder set-active so that it is only set when obj->pages is set
> (and so needs cancellation). Only the order of setting obj->pages and
> the active-flag is crucial. Calling gup after invalidate-range begin
> means the userptr sees the new set of backing storage (and so will not
> need to invalidate its new pages), but we have to be careful not to set
> the active-flag prior to successfully establishing obj->pages.
> v4: Take the active->flag early so we know in the mmu-notifier when we
> have to cancel a pending gup-worker.
> 
> Reported-by: Michał Winiarski 
> Testcase: igt/gem_userptr_blits/map-fixed*
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 
> Cc: Tvrtko Ursulin 
> Cc: sta...@vger.kernel.org
> ---
>   drivers/gpu/drm/i915/i915_gem_userptr.c | 111 
> ++--
>   1 file changed, 78 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 800a5394aa1e..e21f885db87b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -59,6 +59,7 @@ struct i915_mmu_object {
>   struct interval_tree_node it;
>   struct list_head link;
>   struct drm_i915_gem_object *obj;
> + bool active;
>   bool is_linear;
>   };
>   
> @@ -114,7 +115,8 @@ restart:
>   
>   obj = mo->obj;
>   
> - if (!kref_get_unless_zero(>base.refcount))
> + if (!mo->active ||
> + !kref_get_unless_zero(>base.refcount))
>   continue;
>   
>   spin_unlock(>lock);
> @@ -151,7 +153,8 @@ static void 
> i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
>   else
>   it = interval_tree_iter_first(>objects, start, end);
>   if (it != NULL) {
> - obj = container_of(it, struct i915_mmu_object, it)->obj;
> + struct i915_mmu_object *mo =
> + container_of(it, struct i915_mmu_object, it);
>   
>   /* The mmu_object is released late when destroying the
>* GEM object so it is entirely possible to gain a
> @@ -160,11 +163,9 @@ static void 
> i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
>* the struct_mutex - and consequently use it after it
>* is freed and then double free it.
>*/
> - if (!kref_get_unless_zero(>base.refcount)) {
> - spin_unlock(>lock);
> - serial = 0;
> - continue;
> - }
> + if (mo->active &&
> + kref_get_unless_zero(>obj->base.refcount))
> + obj = mo->obj;
>   
>   serial = mn->serial;
>   }
> @@ -566,6 +567,30 @@ __i915_gem_userptr_set_pages(struct drm_i915_gem_object 
> 

[Intel-gfx] [PATCH v6 2/2] drm/i915: Add soft-pinning API for execbuffer

[Michał Winiarski]

From: Chris Wilson 

Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.

v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris
Wilson.  Fixed incorrect error paths causing crash found by Michal Winiarski.
(Not published externally)

v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed eviction
to allow eviction of soft-pinned objects when another soft-pinned object used
by a subsequent execbuffer overlaps reported by Michal Winiarski.
(Not published externally)

v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
pinned first after an address conflict happens to avoid repeated conflicts in
rare cases (Suggested by Chris Wilson).  Expanded comment on
drm_i915_gem_exec_object2.offset to cover this new API.

v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability
(Kristian). Added check for multiple pinnings on eviction (Akash). Made sure
buffers are not considered misplaced without the user specifying
EXEC_OBJECT_SUPPORTS_48BBADDRESS.  User must assume responsibility for any
addressing workarounds.  Updated object2.offset field comment again to clarify
NO_RELOC case (Chris).  checkpatch cleanup.

v6: Rebase on top of current nightly. Dropped any references to
EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in upstream
yet, and are not a dependency.

Cc: Chris Wilson 
Cc: Akash Goel 
Cc: Vinay Belgaumkar 
Cc: Michal Winiarski 
Cc: Zou Nanhai 
Cc: Kristian Høgsberg 
Signed-off-by: Chris Wilson 
Signed-off-by: Thomas Daniel 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_dma.c|  3 ++
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/i915_gem.c| 52 ++
 drivers/gpu/drm/i915/i915_gem_evict.c  | 39 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 16 +++--
 include/uapi/drm/i915_drm.h| 10 +-
 6 files changed, 106 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 066a0ef..bd619af 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -170,6 +170,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_RESOURCE_STREAMER:
value = HAS_RESOURCE_STREAMER(dev);
break;
+   case I915_PARAM_HAS_EXEC_SOFTPIN:
+   value = 1;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2ef83c5..8eb01e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2815,6 +2815,7 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
 #define PIN_OFFSET_BIAS(1<<3)
 #define PIN_USER   (1<<4)
 #define PIN_UPDATE (1<<5)
+#define PIN_OFFSET_FIXED   (1<<6)
 #define PIN_OFFSET_MASK (~4095)
 int __must_check
 i915_gem_object_pin(struct drm_i915_gem_object *obj,
@@ -3157,6 +3158,8 @@ int __must_check i915_gem_evict_something(struct 
drm_device *dev,
  unsigned long start,
  unsigned long end,
  unsigned flags);
+int __must_check
+i915_gem_evict_for_vma(struct i915_vma *target);
 int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
 int i915_gem_evict_everything(struct drm_device *dev);
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 41263cd..bb2ff81 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3437,22 +3437,42 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
*obj,
if (IS_ERR(vma))
goto err_unpin;
 
+   if (flags & PIN_OFFSET_FIXED) {
+   uint64_t offset = flags & PIN_OFFSET_MASK;
+
+   if (offset & (alignment - 1)) {
+   ret = -EINVAL;
+   goto err_free_vma;
+   }
+   vma->node.start = offset;
+   vma->node.size = size;
+   vma->node.color = obj->cache_level;
+   ret = drm_mm_reserve_node(>mm, >node);
+   if (ret) {
+   ret = i915_gem_evict_for_vma(vma);
+   if (ret == 0)
+  

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Daniel Vetter]

On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:
> 
> On 09/09/2015 04:04 PM, Daniel Vetter wrote:
> >On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
> >>
> >>Hi,
> >>
> >>On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
> >>>Previously RMFB and fd close chose to disable any plane that had
> >>>an active framebuffer from this file. If it was a primary plane the
> >>>crtc was disabled. However the fbdev code or any system compositor
> >>>should restore the planes anyway so there's no need to do it twice.
> >>>
> >>>The old fb_id is zero'd, so there's no danger of being able to
> >>>restore the fb from fb_id.
> >>
> >>What does this mean, say if the compositor dies last frame will remain on
> >>the screen?
> >
> >Yes, and the commit message should mention that. It should also mention
> >that other applications can't get at the data since we clear fb id still,
> >so no information leak there.
> 
> Perhaps I replied to the wrong patch from the series.
> 
> Why is all this needed anyway? It sound pretty undesirable from the security
> point of view to me. If it is exploitable to leave something sensitive on
> screen that's not good.

fd close is a super-painful context to do a full-blown modeset. It's
userspace but we can't restart anything because no one ever checks the
return value of close(). We could fix it by pushing this to a work item,
but given that the rule itself seems dubious it's easier to adjust the abi
imo. Framebuffers are somewhat global, so not deleting them makes imo
sense.

The big change is patch 2, which will make them survive for real.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix CSR MMIO address check

[Daniel Vetter]

On Wed, Sep 09, 2015 at 04:52:09PM +0200, Takashi Iwai wrote:
> Fix a wrong logical AND (&&) used for the range check of CSR MMIO.
> 
> Spotted nicely by gcc -Wlogical-op flag:
>   drivers/gpu/drm/i915/intel_csr.c: In function ‘finish_csr_load’:
>   drivers/gpu/drm/i915/intel_csr.c:353:41: warning: logical ‘and’ of mutually 
> exclusive tests is always false [-Wlogical-op]
> 
> Fixes: eb805623d8b1 ('drm/i915/skl: Add support to load SKL CSR firmware.')
> Cc:  # v4.2
> Signed-off-by: Takashi Iwai 

Oops. Reviewed-by: Daniel Vetter  and for Jani.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_csr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index ba1ae031e6fd..d0f1b8d833cd 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -350,7 +350,7 @@ static void finish_csr_load(const struct firmware *fw, 
> void *context)
>   }
>   csr->mmio_count = dmc_header->mmio_count;
>   for (i = 0; i < dmc_header->mmio_count; i++) {
> - if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE &&
> + if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE ||
>   dmc_header->mmioaddr[i] > CSR_MMIO_END_RANGE) {
>   DRM_ERROR(" Firmware has wrong mmio address 0x%x\n",
>   dmc_header->mmioaddr[i]);
> -- 
> 2.5.1
> 

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

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Use a task to cancel the userptr on invalidate_range

[Chris Wilson]

On Wed, Sep 09, 2015 at 04:20:08PM +0100, Tvrtko Ursulin wrote:
> 
> On 09/09/2015 04:08 PM, Chris Wilson wrote:
> >On Wed, Sep 09, 2015 at 03:45:40PM +0100, Tvrtko Ursulin wrote:
> >>On 08/10/2015 09:51 AM, Chris Wilson wrote:
> >>>Whilst discussing possible ways to trigger an invalidate_range on a
> >>>userptr with an aliased GGTT mmapping (and so cause a struct_mutex
> >>>deadlock), the conclusion is that we can, and we must, prevent any
> >>>possible deadlock by avoiding taking the mutex at all during
> >>>invalidate_range. This has numerous advantages all of which stem from
> >>>avoid the sleeping function from inside the unknown context. In
> >>>particular, it simplifies the invalidate_range because we no longer
> >>>have to juggle the spinlock/mutex and can just hold the spinlock
> >>>for the entire walk. To compensate, we have to make get_pages a bit more
> >>>complicated in order to serialise with a pending cancel_userptr worker.
> >>>As we hold the struct_mutex, we have no choice but to return EAGAIN and
> >>>hope that the worker is then flushed before we retry after reacquiring
> >>>the struct_mutex.
> >>>
> >>>The important caveat is that the invalidate_range itself is no longer
> >>>synchronous. There exists a small but definite period in time in which
> >>>the old PTE's page remain accessible via the GPU. Note however that the
> >>>physical pages themselves are not invalidated by the mmu_notifier, just
> >>>the CPU view of the address space. The impact should be limited to a
> >>>delay in pages being flushed, rather than a possibility of writing to
> >>>the wrong pages. The only race condition that this worsens is remapping
> >>>an userptr active on the GPU where fresh work may still reference the
> >>>old pages due to struct_mutex contention. Given that userspace is racing
> >>>with the GPU, it is fair to say that the results are undefined.
> >>>
> >>>v2: Only queue (and importantly only take one refcnt) the worker once.
> >>
> >>This one I looked at at the time of previous posting and it looked
> >>fine, minus one wrong line of thinking of mine. On a brief look it
> >>still looks good, so:
> >>
> >>Reviewed-by: Tvrtko Ursulin 
> >>
> >>I assume Michał has run all these through the relevant test cases?
> >>
> >>Slightly related, I now worry about the WARN_ONs in
> >>__cancel_userptr__worker since they look to be triggerable by
> >>malicious userspace which is not good.
> >
> >They could always be I thought, if you could somehow pin the userptr
> >into a hardware register and then unmap the vma. That is a scary thought
> >and one I would like a WARN for. That should be the only way, and I shudder
> >at the prospect of working out who to send the SIGBUS to.
> 
> Is it not enough to submit work to the GPU and while it is running
> engineer a lot of signals and munmap?

No, we block signals inside the worker, which should reduce it down to
EINVAL/EBUSY or EIO from unbind (and a subsequent WARN from put).
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Daniel Vetter]

On Wed, Sep 09, 2015 at 04:47:08PM +0100, Tvrtko Ursulin wrote:
> 
> On 09/09/2015 04:29 PM, Daniel Vetter wrote:
> >On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 09/09/2015 04:04 PM, Daniel Vetter wrote:
> >>>On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
> >Previously RMFB and fd close chose to disable any plane that had
> >an active framebuffer from this file. If it was a primary plane the
> >crtc was disabled. However the fbdev code or any system compositor
> >should restore the planes anyway so there's no need to do it twice.
> >
> >The old fb_id is zero'd, so there's no danger of being able to
> >restore the fb from fb_id.
> 
> What does this mean, say if the compositor dies last frame will remain on
> the screen?
> >>>
> >>>Yes, and the commit message should mention that. It should also mention
> >>>that other applications can't get at the data since we clear fb id still,
> >>>so no information leak there.
> >>
> >>Perhaps I replied to the wrong patch from the series.
> >>
> >>Why is all this needed anyway? It sound pretty undesirable from the security
> >>point of view to me. If it is exploitable to leave something sensitive on
> >>screen that's not good.
> >
> >fd close is a super-painful context to do a full-blown modeset. It's
> >userspace but we can't restart anything because no one ever checks the
> >return value of close(). We could fix it by pushing this to a work item,
> >but given that the rule itself seems dubious it's easier to adjust the abi
> >imo. Framebuffers are somewhat global, so not deleting them makes imo
> >sense.
> >
> >The big change is patch 2, which will make them survive for real.
> 
> I don't follow this closely but it still sounds wrong. If modeset is a
> concern then disable the planes and/or clear them?

This is generic core code, you can't disable/clear planes in a generic way
without doing a full modeset.

> It really doesn't feel preservation of fb content is a good thing to do. If
> the higher goal is to enable some smooth transitions clients should engineer
> that themselves.
> 
> In any case leaving content on screen sounds really bad to me.
> 
> Reminds me of screen locker bugs which sometimes did not clear the screen
> when displaying the unlock dialog. That was pretty common for a long period
> in KDE. And this sounds like it could be attackable in a similar way.

Afaik that's just userspace coordination fail - system deamons go into
suspend without telling and waiting for the screenlocker to lock the
screen. Hilarious, but not really something we can fix in the kernel.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Tvrtko Ursulin]

On 09/09/2015 04:56 PM, Daniel Vetter wrote:

On Wed, Sep 09, 2015 at 04:47:08PM +0100, Tvrtko Ursulin wrote:


On 09/09/2015 04:29 PM, Daniel Vetter wrote:

On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:


On 09/09/2015 04:04 PM, Daniel Vetter wrote:

On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:


Hi,

On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:

Previously RMFB and fd close chose to disable any plane that had
an active framebuffer from this file. If it was a primary plane the
crtc was disabled. However the fbdev code or any system compositor
should restore the planes anyway so there's no need to do it twice.

The old fb_id is zero'd, so there's no danger of being able to
restore the fb from fb_id.


What does this mean, say if the compositor dies last frame will remain on
the screen?


Yes, and the commit message should mention that. It should also mention
that other applications can't get at the data since we clear fb id still,
so no information leak there.


Perhaps I replied to the wrong patch from the series.

Why is all this needed anyway? It sound pretty undesirable from the security
point of view to me. If it is exploitable to leave something sensitive on
screen that's not good.


fd close is a super-painful context to do a full-blown modeset. It's
userspace but we can't restart anything because no one ever checks the
return value of close(). We could fix it by pushing this to a work item,
but given that the rule itself seems dubious it's easier to adjust the abi
imo. Framebuffers are somewhat global, so not deleting them makes imo
sense.

The big change is patch 2, which will make them survive for real.


I don't follow this closely but it still sounds wrong. If modeset is a
concern then disable the planes and/or clear them?


This is generic core code, you can't disable/clear planes in a generic way
without doing a full modeset.


It really doesn't feel preservation of fb content is a good thing to do. If
the higher goal is to enable some smooth transitions clients should engineer
that themselves.

In any case leaving content on screen sounds really bad to me.

Reminds me of screen locker bugs which sometimes did not clear the screen
when displaying the unlock dialog. That was pretty common for a long period
in KDE. And this sounds like it could be attackable in a similar way.


Afaik that's just userspace coordination fail - system deamons go into
suspend without telling and waiting for the screenlocker to lock the
screen. Hilarious, but not really something we can fix in the kernel.


It was just an example of a class of vulnerabilities which would be 
possible with these changes. If they, as you said, will preserve the 
last frame on screen when the compositor crashes.


For me this is serious enough not to go this route.

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

[Intel-gfx] [PATCH 2/2] drm/core: Preserve the fb id on close.

[Maarten Lankhorst]

Keep the fb_id, which means that any application exiting without
unsetting the framebuffer from all planes will preserve its contents.

This is similar to preserving the initial framebuffer, except all
planes are preserved.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_crtc.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 626b0a57efbf..9d55c0c6aa95 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3320,9 +3320,6 @@ int drm_mode_rmfb(struct drm_device *dev,
if (!found)
goto fail_lookup;
 
-   /* Mark fb as reaped, we still have a ref from fpriv->fbs. */
-   __drm_framebuffer_unregister(dev, fb);
-
list_del_init(>filp_head);
mutex_unlock(>mode_config.fb_lock);
mutex_unlock(_priv->fbs_lock);
@@ -3508,15 +3505,9 @@ void drm_fb_release(struct drm_file *priv)
 * at it any more.
 */
list_for_each_entry_safe(fb, tfb, >fbs, filp_head) {
-
-   mutex_lock(>mode_config.fb_lock);
-   /* Mark fb as reaped, we still have a ref from fpriv->fbs. */
-   __drm_framebuffer_unregister(dev, fb);
-   mutex_unlock(>mode_config.fb_lock);
-
list_del_init(>filp_head);
 
-   /* This will also drop the fpriv->fbs reference. */
+   /* This drops the fpriv->fbs reference. */
drm_framebuffer_unreference(fb);
}
 }
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH] drm/core: Do not call drm_framebuffer_remove internally during teardown.

[Daniel Vetter]

On Wed, Sep 09, 2015 at 04:33:33PM +0200, Maarten Lankhorst wrote:
> Op 09-09-15 om 13:59 schreef Daniel Vetter:
> > On Wed, Sep 9, 2015 at 1:51 PM, Ville Syrjälä
> >  wrote:
> >> On Wed, Sep 09, 2015 at 01:46:21PM +0200, Maarten Lankhorst wrote:
> >>> This may cause issues because encoders are already destroyed so removing
> >>> active primaries may use freed memory. Instead free the fb directly,
> >>> ignoring refcount.
> >> So what about fixing the cause, not the symptom? That is remove
> >> framebuffers before nuking crtc/encoders/etc.
> > Also by that point we shouldn't have any framebuffers left (the
> > WARN_ON is for that), so not sure what's the point of this patch.
> > -Daniel
> Yes, but the current way would crash on atomic because encoders are
> already done. This removes a caller of drm_framebuffer_remove and uses
> the correct destroy function regardless even when refcounts are leaked.
> :)

Makes some sense I guess ... applied to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Use a task to cancel the userptr on invalidate_range

[Tvrtko Ursulin]

On 08/10/2015 09:51 AM, Chris Wilson wrote:

Whilst discussing possible ways to trigger an invalidate_range on a
userptr with an aliased GGTT mmapping (and so cause a struct_mutex
deadlock), the conclusion is that we can, and we must, prevent any
possible deadlock by avoiding taking the mutex at all during
invalidate_range. This has numerous advantages all of which stem from
avoid the sleeping function from inside the unknown context. In
particular, it simplifies the invalidate_range because we no longer
have to juggle the spinlock/mutex and can just hold the spinlock
for the entire walk. To compensate, we have to make get_pages a bit more
complicated in order to serialise with a pending cancel_userptr worker.
As we hold the struct_mutex, we have no choice but to return EAGAIN and
hope that the worker is then flushed before we retry after reacquiring
the struct_mutex.

The important caveat is that the invalidate_range itself is no longer
synchronous. There exists a small but definite period in time in which
the old PTE's page remain accessible via the GPU. Note however that the
physical pages themselves are not invalidated by the mmu_notifier, just
the CPU view of the address space. The impact should be limited to a
delay in pages being flushed, rather than a possibility of writing to
the wrong pages. The only race condition that this worsens is remapping
an userptr active on the GPU where fresh work may still reference the
old pages due to struct_mutex contention. Given that userspace is racing
with the GPU, it is fair to say that the results are undefined.

v2: Only queue (and importantly only take one refcnt) the worker once.


This one I looked at at the time of previous posting and it looked fine, 
minus one wrong line of thinking of mine. On a brief look it still looks 
good, so:


Reviewed-by: Tvrtko Ursulin 

I assume Michał has run all these through the relevant test cases?

Slightly related, I now worry about the WARN_ONs in 
__cancel_userptr__worker since they look to be triggerable by malicious 
userspace which is not good.


Also my proposed error handling for the previous patch is slightly wrong 
because I misremebered what mo->active stands for.


Regards,

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

Re: [Intel-gfx] About GVT-g Interrupt in i915 Host

[Wang, Zhi A]

Hi Daniel:
Really appreciate the reply! :) I just read the code again. And we will 
prepare the PoC patch based on the new ideas! :)

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, September 09, 2015 4:40 AM
To: Wang, Zhi A
Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel
Subject: Re: [Intel-gfx] About GVT-g Interrupt in i915 Host

On Tue, Sep 08, 2015 at 04:03:02PM +, Wang, Zhi A wrote:
> BACKGROUND
> 
> Under Intel GVT-g environment, HW interrupts are shared among different VMs.
> 
> Because of the sharing, to enable or disable a HW interrupt becomes a bit
> complicated. Considered that a virtual machine may request to disable a
> interrupt which may be using by other virtual machines. The GEN IRQ register
> value has to be re-calculated before it gets updated to HW.
> 
> i.e. 
> 
> - Virtual machine(VM) A wants to *disable* a PIPE VBLANK interrupt.
> - Virtual machine B wants to *enable* a PIPE VBLANK interrupt.
> 
> The final result is to *enable* the HW VBLANK interrupt, so that we can:
> - Get VBLANK interrupt from HW for virtual machine B.
> 
> Meanwhile, we choose not to inject VBLANK interrupt into virtual machine A,
> which actually doesn't want VBLANK interrupt at this time.
> 
> Current Implementation - Interrupt Injection in GVT-g
> 
>  +---+ +--+
>  | Linux Guest   | | Linux Guest  |
>  | I915 (Guest Mode) *Upstreamed | | i915 (Guest Mode)|
>  +^--+ +^-+
>   | |
>  INJECT!  | | INJECT!
>   | |
> +-|-|+
> | ++  +---+  |
> | |i915 *  |  |  GVT-g|  |
> | |(Host Mode) |  +-+-+  |
> | +-^--+|Host Linux Kernel   |
> +---|---|^---+
> +---+|
>  INJECT! |  Interrupts
> +|---+
> |Hypervisor  |
> +|---+
> +|---+
> |   GPU Hardware |
> ++
> 
> Current implementation treats i915 host(DOM0) like a VM, all the interrupt
> register access will be trapped and emulated by GVT-g.
> 
> The most obvious advantange is minimum i915 host code change:
> 
> - add some hooks in I915_READ()/I915_WRITE() to trap host common register 
> access
> - add some hooks in i915 irq initilization path to trap host interrupt
> - add some hooks in i915_gem_gtt.c to trap host GTT mmio access.
> 
> But it brings some architectural conflict. so we purpose another approach.
> 
> EXPECTED ARCHITECTURE
> 
>  +---+ +--+
>  | Linux Guest   | | Linux Guest  |
>  | I915 (Guest Mode) *Upstreamed | | i915 (Guest Mode)|
>  +^--+ +^-+
>   | |
>  INJECT!  +--+  | INJECT!
>  |  |
> +|--|-+
> | +-+   +|--|---+ |
> | |i915 +--->   GVT-g   | |
> | |(Host Mode)  | DISPATCH! +---+ |
> | +---^-+ |
> +-|---+
>   | Interrupt
> +-|---+
> |Hypervisor   |
> +-+
> +-|---+
> |   GPU Hardware  |
> +-+
> 
>  [Host i915 manages all interrupts]
> 
> DESIGN
> 
> To achieve such kind of an approach, an ideal design in i915 is:
> 
> Introduce two IRQ register caches into i915, one for host and one for GVT-g.
> 
> Then we provide an central IRQ register mainpulation interface to other
> components of host i915, so we can log all interrupt register values of
> host i915.
> 
> Meanwhile, GVT-g will calculate the IRQ register values according to all
> virtual machines and update GVT-g IRQ register cache inside i915 host.
> 
> When i915 host itself wants to update IRQ registers or GVT-g requests i915 
> host
> to update IRQ registers, all related IRQ registers of i915 host and GVT-g
> will be re-calculated and combined together and written into HW later.
> 
> This figure shows the details of the design above
> 
> 

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Daniel Vetter]

On Wed, Sep 09, 2015 at 04:40:56PM +0200, Maarten Lankhorst wrote:
> Previously RMFB and fd close chose to disable any plane that had
> an active framebuffer from this file. If it was a primary plane the
> crtc was disabled. However the fbdev code or any system compositor
> should restore the planes anyway so there's no need to do it twice.
> 
> The old fb_id is zero'd, so there's no danger of being able to
> restore the fb from fb_id.
> 
> Signed-off-by: Maarten Lankhorst 

I think the current behaviour was just a side-effect of the original
implementation and not too intentional - with no refcounting for fbs they
_had_ to be synchronously reaped. And when I've done the conversion to
refcounting I kept this to avoid gettting tangled up in an ABI-change
mess.

But I don't the current behaviour makes much sense and worth an attemp to
rectify it. And as long as we still clear the fb ids there's no real
information leak either.

Reviewed-by: Daniel Vetter 

But I do want other people's opinion before I pull this in.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9b9c4b41422a..626b0a57efbf 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3327,7 +3327,7 @@ int drm_mode_rmfb(struct drm_device *dev,
>   mutex_unlock(>mode_config.fb_lock);
>   mutex_unlock(_priv->fbs_lock);
>  
> - drm_framebuffer_remove(fb);
> + drm_framebuffer_unreference(fb);
>  
>   return 0;
>  
> @@ -3517,7 +3517,7 @@ void drm_fb_release(struct drm_file *priv)
>   list_del_init(>filp_head);
>  
>   /* This will also drop the fpriv->fbs reference. */
> - drm_framebuffer_remove(fb);
> + drm_framebuffer_unreference(fb);
>   }
>  }
>  
> -- 
> 2.1.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH] drm/i915: add kerneldoc for i915_audio_component

[Daniel Vetter]

On Wed, Sep 09, 2015 at 01:45:47AM +, Yang, Libin wrote:
> Hi Daniel,
> 
> As Takashi has already accepted the first 3 patches for 
> sync_audio_rate() and the patches are not merged
> into -nightly branch. If I make a kerneldoc patch
> based on currently -nightly branch, there will
> be conflict when you are merging Takashi's branch.
> 
> What do you think if I make the kerneldoc patch
> after the sync_audio_rate() patches are merged
> into the -nightly branch?

Hm, I do pull in sound/for-next into drm-intel-nightly ... Are the patches
somewhere else? I can easily add another branch to nightly to make things
easier. Takashi, which branches should I all pull in to get all the audio
stuff into drm-intel-nightly?

Thanks, Daniel

> 
> Regards,
> Libin
> 
> 
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > Daniel Vetter
> > Sent: Friday, September 04, 2015 3:55 PM
> > To: Jani Nikula
> > Cc: Yang, Libin; Daniel Vetter; intel-gfx@lists.freedesktop.org;
> > daniel.vet...@ffwll.ch; ville.syrj...@linux.intel.com
> > Subject: Re: [PATCH] drm/i915: add kerneldoc for
> > i915_audio_component
> > 
> > On Fri, Sep 04, 2015 at 09:40:17AM +0300, Jani Nikula wrote:
> > > On Fri, 04 Sep 2015, "Yang, Libin"  wrote:
> > > >> -Original Message-
> > > >> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > > >> Daniel Vetter
> > > >> Sent: Wednesday, September 02, 2015 8:18 PM
> > > >> To: Yang, Libin
> > > >> Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> > > >> jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com
> > > >> Subject: Re: [PATCH] drm/i915: add kerneldoc for
> > > >> i915_audio_component
> > > >>
> > > >> On Wed, Sep 02, 2015 at 02:12:24PM +0800,
> > libin.y...@intel.com
> > > >> wrote:
> > > >> > From: Libin Yang 
> > > >> >
> > > >> > Add the kerneldoc for i915_audio_component in
> > i915_component.h
> > > >> >
> > > >> > Signed-off-by: Libin Yang 
> > > >> > ---
> > > >> >  include/drm/i915_component.h | 39
> > --
> > > >> -
> > > >> >  1 file changed, 24 insertions(+), 15 deletions(-)
> > > >> >
> > > >> > diff --git a/include/drm/i915_component.h
> > > >> b/include/drm/i915_component.h
> > > >> > index 8ad6f1b..187acc8 100644
> > > >> > --- a/include/drm/i915_component.h
> > > >> > +++ b/include/drm/i915_component.h
> > > >> > @@ -24,23 +24,32 @@
> > > >> >  #ifndef _I915_COMPONENT_H_
> > > >> >  #define _I915_COMPONENT_H_
> > > >> >
> > > >> > +/**
> > > >> > + * struct i915_audio_component_ops - callbacks defined in gfx
> > > >> driver
> > > >> > + * @owner: the module owner
> > > >> > + * @get_power: get the POWER_DOMAIN_AUDIO power well
> > > >> > + * @put_power: put the POWER_DOMAIN_AUDIO power well
> > > >> > + * @codec_wake_override: Enable/Disable generating the
> > codec
> > > >> wake signal
> > > >> > + * @get_cdclk_freq: get the Core Display Clock in KHz
> > > >> > + * @sync_audio_rate: set n/cts based on the sample rate
> > > >> > + */
> > > >> > +struct i915_audio_component_ops {
> > > >> > +struct module *owner;
> > > >>
> > > >> New kerneldoc in 4.3 allows you to split structure documentation
> > up
> > > >> into
> > > >> per-member comments. Especially with vtables I think this makes
> > a lot
> > > >> of
> > > >> sense, since then you have enough space to document where and
> > how
> > > >> exactly
> > > >> a given hook is called (looks, place in the overall sequence).
> > > >>
> > > >> Also please include your stancas in the drm.tmpl docbook
> > template,
> > > >> otherwise it won't be included in the html docs. And finally please
> > add
> > > >
> > > > OK, I will add it in drm.tmpl.
> > > >
> > > >> a
> > > >> DOC: overview section which explains at a high level how i915 and
> > > >> hda-intel corporate for hdmi/dp audio.
> > > >
> > > > Where the DOC should be located in?
> > >
> > > i915/intel_audio.c already has a "DOC: High Definition Audio over
> > HDMI
> > > and Display Port" comment. IMO you could just amend that, as
> > there's
> > > already some references to the audio driver.
> > 
> > Yeah I think that would be a perfect place.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

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

Re: [Intel-gfx] [PATCH] drm/i915: Call encoder hot_plug hook only for hdmi

[Daniel Vetter]

On Tue, Sep 08, 2015 at 05:08:02PM +0530, Jindal, Sonika wrote:
> 
> 
> On 9/8/2015 10:12 AM, Jindal, Sonika wrote:
> >
> >
> >On 9/7/2015 9:56 PM, Daniel Vetter wrote:
> >>On Mon, Sep 07, 2015 at 10:34:34AM +0530, Sonika Jindal wrote:
> >>>If the same port is enumerated as hdmi as well as DP, this will call
> >>>hot_plug hook for DP as well which is not required here.
> >>>This splitting of edid read and detect is done only for HDMI with this
> >>>series.
> >>>
> >>>v2: Avoid breaking DP hpd. Also corrected the commit message and
> >>>description accordingly. (Daniel)
> >>>
> >>>Signed-off-by: Sonika Jindal 
> >>>---
> >>>  drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
> >>>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> >>>b/drivers/gpu/drm/i915/intel_hotplug.c
> >>>index 53c0173..ff4692a 100644
> >>>--- a/drivers/gpu/drm/i915/intel_hotplug.c
> >>>+++ b/drivers/gpu/drm/i915/intel_hotplug.c
> >>>@@ -331,7 +331,8 @@ static void i915_hotplug_work_func(struct
> >>>work_struct *work)
> >>>  if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
> >>>  DRM_DEBUG_KMS("Connector %s (pin %i) received hotplug
> >>>event.\n",
> >>>connector->name, intel_encoder->hpd_pin);
> >>>-if (intel_encoder->hot_plug)
> >>>+if (intel_encoder->hot_plug
> >>>+&& connector->connector_type ==
> >>>DRM_MODE_CONNECTOR_HDMIA)
> >>
> >>Please use something like grep to find all the other ->hot_plug
> >>implementations and then please tell me why you don't break them all.
> >>-Daniel
> >>
> >Hmm, I only checked for hot_plug for DP/edp which is not there. Failed
> >to notice that there is one in intel_sdvo.c.
> >My mistake. I will place it properly somewhere else.
> >
> >Regards,
> >Sonika
> 
> Is there any suggestion about how we can differentiate if it is actual DP or
> HDMI hotplug at this point? intel_encoder's type gets updated after detect
> call. So, not sure how to have this kind of check.
> 
> For now, I think we can abandon this patch from this series.

No, hpd is shared between hdmi and dp at the hw level so we can't
differentiate. Long term my idea would be that we merge together all the
hdmi _and_ dp hpd handling into one overall control-flow. Then we can make
sure to not call anything twice and also have sensible high-level flow
(like first checking for dp vs. hdmi and then taking relevant paths).

For dealing with ->hot_plug a quick fix might be to have a separate loop
going over encoders (to make sure we only call it once per encoder if
there's more than one connector for 1 encoder). That behaviour would also
be ok for sdvo.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS

[Ville Syrjälä]

On Tue, Sep 08, 2015 at 09:16:11PM +0100, Chris Wilson wrote:
> On Tue, Sep 08, 2015 at 09:05:12PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > If one disables DDR DVFS in the BIOS, Punit will apparently ignores
> > all DDR DVFS request. Currently we assume that DDR DVFS is always
> > operational, which leads to errors in dmesg when the DDR DVFS requests
> > time out.
> > 
> > Fix the problem by gently prodding Punit during driver load to find out
> > whether it will respond to DDR DVFS requests. If the request times out,
> > we assume that DDR DVFS has been permanenly disabled in the BIOS and
> > no longer perster the Punit about it.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91629
> > Signed-off-by: Ville Syrjälä 
> 
> Code looks clean (just a minor duplicated vlv_read(DDR_SETUP2) in
> setup).

Yeah I suppose I could have reused the orignal value read, or reassign
val also in wait_for().

> Would it make sense to disable dvfs after a failure as well,
> then the user is shown a single DRM_ERROR at runtime and we should
> recover (by not going to the full WM next time)?

I wouldn't expect any failures after we've determined that it works.
That would indicate Punit going belly up or something, and then I'm
not sure anything would work anymore.

So I would hold on doing that unless someone actually hits such a
problem.

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

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Tvrtko Ursulin]

On 09/09/2015 05:07 PM, Daniel Vetter wrote:

On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
 wrote:

It was just an example of a class of vulnerabilities which would be possible
with these changes. If they, as you said, will preserve the last frame on
screen when the compositor crashes.


If your compositor crashes something should take over, either fbdev
(which force-restores) or a new compositor (system one or just the one
that crashed, restarted). And on modern userspace logind has copies of
the fds which it uses to make sure priviledges (i.e. master rights)
don't escape to the wrong person.


The famous "should". fbdev is going out no? And attack just needs to 
prevent compositor from starting again. Or a bug somewhere needs to do 
that. Fact remains, before this = black screen, after this = last frame 
with bank details or similar.


Change makes the scenario more likely, so what is the justification? 
Only that modeset is hard on framebuffer owner exiting?



For me this is serious enough not to go this route.


If that doesn't happen you have yet another bug in userspace. I don't
think there's a real problem really.


If white hats had the imagination of black hats there would be no 
problems whatsoever. :)


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

[Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Maarten Lankhorst]

Previously RMFB and fd close chose to disable any plane that had
an active framebuffer from this file. If it was a primary plane the
crtc was disabled. However the fbdev code or any system compositor
should restore the planes anyway so there's no need to do it twice.

The old fb_id is zero'd, so there's no danger of being able to
restore the fb from fb_id.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9b9c4b41422a..626b0a57efbf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3327,7 +3327,7 @@ int drm_mode_rmfb(struct drm_device *dev,
mutex_unlock(>mode_config.fb_lock);
mutex_unlock(_priv->fbs_lock);
 
-   drm_framebuffer_remove(fb);
+   drm_framebuffer_unreference(fb);
 
return 0;
 
@@ -3517,7 +3517,7 @@ void drm_fb_release(struct drm_file *priv)
list_del_init(>filp_head);
 
/* This will also drop the fpriv->fbs reference. */
-   drm_framebuffer_remove(fb);
+   drm_framebuffer_unreference(fb);
}
 }
 
-- 
2.1.0

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

[Intel-gfx] [PATCH 0/2] Preserve framebuffer during rmfb / drm fd close.

[Maarten Lankhorst]

This is breaks the abi slightly, but allows preserving the framebuffer contents 
across processes.
Any system compositor or fbdev should take care of resetting the planes and 
mode anyway.

Restoring a framebuffer requires a call to getfb, which checks for
CAP_SYS_ADMIN, DRM_MASTER or access to the control file. Any of those
require privileges, so this shouldn't be a security issue.

Maarten Lankhorst (2):
  drm/core: Preserve the framebuffer after removing it.
  drm/core: Preserve the fb id on close.

 drivers/gpu/drm/drm_crtc.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

-- 
2.1.0

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

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Daniel Vetter]

On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
> >Previously RMFB and fd close chose to disable any plane that had
> >an active framebuffer from this file. If it was a primary plane the
> >crtc was disabled. However the fbdev code or any system compositor
> >should restore the planes anyway so there's no need to do it twice.
> >
> >The old fb_id is zero'd, so there's no danger of being able to
> >restore the fb from fb_id.
> 
> What does this mean, say if the compositor dies last frame will remain on
> the screen?

Yes, and the commit message should mention that. It should also mention
that other applications can't get at the data since we clear fb id still,
so no information leak there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Tvrtko Ursulin]

On 09/09/2015 04:04 PM, Daniel Vetter wrote:

On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:


Hi,

On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:

Previously RMFB and fd close chose to disable any plane that had
an active framebuffer from this file. If it was a primary plane the
crtc was disabled. However the fbdev code or any system compositor
should restore the planes anyway so there's no need to do it twice.

The old fb_id is zero'd, so there's no danger of being able to
restore the fb from fb_id.


What does this mean, say if the compositor dies last frame will remain on
the screen?


Yes, and the commit message should mention that. It should also mention
that other applications can't get at the data since we clear fb id still,
so no information leak there.


Perhaps I replied to the wrong patch from the series.

Why is all this needed anyway? It sound pretty undesirable from the 
security point of view to me. If it is exploitable to leave something 
sensitive on screen that's not good.


Regards,

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

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Use a task to cancel the userptr on invalidate_range

[Tvrtko Ursulin]

On 09/09/2015 04:08 PM, Chris Wilson wrote:

On Wed, Sep 09, 2015 at 03:45:40PM +0100, Tvrtko Ursulin wrote:

On 08/10/2015 09:51 AM, Chris Wilson wrote:

Whilst discussing possible ways to trigger an invalidate_range on a
userptr with an aliased GGTT mmapping (and so cause a struct_mutex
deadlock), the conclusion is that we can, and we must, prevent any
possible deadlock by avoiding taking the mutex at all during
invalidate_range. This has numerous advantages all of which stem from
avoid the sleeping function from inside the unknown context. In
particular, it simplifies the invalidate_range because we no longer
have to juggle the spinlock/mutex and can just hold the spinlock
for the entire walk. To compensate, we have to make get_pages a bit more
complicated in order to serialise with a pending cancel_userptr worker.
As we hold the struct_mutex, we have no choice but to return EAGAIN and
hope that the worker is then flushed before we retry after reacquiring
the struct_mutex.

The important caveat is that the invalidate_range itself is no longer
synchronous. There exists a small but definite period in time in which
the old PTE's page remain accessible via the GPU. Note however that the
physical pages themselves are not invalidated by the mmu_notifier, just
the CPU view of the address space. The impact should be limited to a
delay in pages being flushed, rather than a possibility of writing to
the wrong pages. The only race condition that this worsens is remapping
an userptr active on the GPU where fresh work may still reference the
old pages due to struct_mutex contention. Given that userspace is racing
with the GPU, it is fair to say that the results are undefined.

v2: Only queue (and importantly only take one refcnt) the worker once.


This one I looked at at the time of previous posting and it looked
fine, minus one wrong line of thinking of mine. On a brief look it
still looks good, so:

Reviewed-by: Tvrtko Ursulin 

I assume Michał has run all these through the relevant test cases?

Slightly related, I now worry about the WARN_ONs in
__cancel_userptr__worker since they look to be triggerable by
malicious userspace which is not good.


They could always be I thought, if you could somehow pin the userptr
into a hardware register and then unmap the vma. That is a scary thought
and one I would like a WARN for. That should be the only way, and I shudder
at the prospect of working out who to send the SIGBUS to.


Is it not enough to submit work to the GPU and while it is running 
engineer a lot of signals and munmap?


Regards,

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

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Tvrtko Ursulin]

On 09/09/2015 04:29 PM, Daniel Vetter wrote:

On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:


On 09/09/2015 04:04 PM, Daniel Vetter wrote:

On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:


Hi,

On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:

Previously RMFB and fd close chose to disable any plane that had
an active framebuffer from this file. If it was a primary plane the
crtc was disabled. However the fbdev code or any system compositor
should restore the planes anyway so there's no need to do it twice.

The old fb_id is zero'd, so there's no danger of being able to
restore the fb from fb_id.


What does this mean, say if the compositor dies last frame will remain on
the screen?


Yes, and the commit message should mention that. It should also mention
that other applications can't get at the data since we clear fb id still,
so no information leak there.


Perhaps I replied to the wrong patch from the series.

Why is all this needed anyway? It sound pretty undesirable from the security
point of view to me. If it is exploitable to leave something sensitive on
screen that's not good.


fd close is a super-painful context to do a full-blown modeset. It's
userspace but we can't restart anything because no one ever checks the
return value of close(). We could fix it by pushing this to a work item,
but given that the rule itself seems dubious it's easier to adjust the abi
imo. Framebuffers are somewhat global, so not deleting them makes imo
sense.

The big change is patch 2, which will make them survive for real.


I don't follow this closely but it still sounds wrong. If modeset is a 
concern then disable the planes and/or clear them?


It really doesn't feel preservation of fb content is a good thing to do. 
If the higher goal is to enable some smooth transitions clients should 
engineer that themselves.


In any case leaving content on screen sounds really bad to me.

Reminds me of screen locker bugs which sometimes did not clear the 
screen when displaying the unlock dialog. That was pretty common for a 
long period in KDE. And this sounds like it could be attackable in a 
similar way.


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

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Daniel Vetter]

On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
 wrote:
> It was just an example of a class of vulnerabilities which would be possible
> with these changes. If they, as you said, will preserve the last frame on
> screen when the compositor crashes.

If your compositor crashes something should take over, either fbdev
(which force-restores) or a new compositor (system one or just the one
that crashed, restarted). And on modern userspace logind has copies of
the fds which it uses to make sure priviledges (i.e. master rights)
don't escape to the wrong person.

> For me this is serious enough not to go this route.

If that doesn't happen you have yet another bug in userspace. I don't
think there's a real problem really.
-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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS

[Ville Syrjälä]

On Wed, Sep 09, 2015 at 04:41:04PM +0100, Chris Wilson wrote:
> On Wed, Sep 09, 2015 at 06:28:50PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 08, 2015 at 09:16:11PM +0100, Chris Wilson wrote:
> > > Would it make sense to disable dvfs after a failure as well,
> > > then the user is shown a single DRM_ERROR at runtime and we should
> > > recover (by not going to the full WM next time)?
> > 
> > I wouldn't expect any failures after we've determined that it works.
> > That would indicate Punit going belly up or something, and then I'm
> > not sure anything would work anymore.
> 
> We didn't expect any before either :) And it sounds like you are arguing
> that we should be reducing the noise from the victims as well :)

Well, I think I'll still leave it as is. People have generally been
opposed to adding code to deal with conditions that should never
happen in real life.

Should I be proven wrong, you can smack me on the head with a big
"told you so!" sign ;)

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

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Maarten Lankhorst]

Op 09-09-15 om 18:15 schreef Tvrtko Ursulin:
>
> On 09/09/2015 05:07 PM, Daniel Vetter wrote:
>> On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
>>  wrote:
>>> It was just an example of a class of vulnerabilities which would be possible
>>> with these changes. If they, as you said, will preserve the last frame on
>>> screen when the compositor crashes.
>>
>> If your compositor crashes something should take over, either fbdev
>> (which force-restores) or a new compositor (system one or just the one
>> that crashed, restarted). And on modern userspace logind has copies of
>> the fds which it uses to make sure priviledges (i.e. master rights)
>> don't escape to the wrong person.
>
> The famous "should". fbdev is going out no? And attack just needs to prevent 
> compositor from starting again. Or a bug somewhere needs to do that. Fact 
> remains, before this = black screen, after this = last frame with bank 
> details or similar.
>
> Change makes the scenario more likely, so what is the justification? Only 
> that modeset is hard on framebuffer owner exiting?
>>> For me this is serious enough not to go this route.
>>
>> If that doesn't happen you have yet another bug in userspace. I don't
>> think there's a real problem really.
>
> If white hats had the imagination of black hats there would be no problems 
> whatsoever. :)
>
> Tvrtko

I have enough imagination, but the fact is the code to copy the fb contents 
requires the following:

file_priv->is_master || capable(CAP_SYS_ADMIN) || 
drm_is_control_client(file_priv)

If you already have any of those privileges you can draw your own fake TTY 
login screen
and grab the password that way, so I don't see an additional attack vector 
exposed here.

~Maarten

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

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Use a task to cancel the userptr on invalidate_range

[Chris Wilson]

On Wed, Sep 09, 2015 at 03:45:40PM +0100, Tvrtko Ursulin wrote:
> On 08/10/2015 09:51 AM, Chris Wilson wrote:
> >Whilst discussing possible ways to trigger an invalidate_range on a
> >userptr with an aliased GGTT mmapping (and so cause a struct_mutex
> >deadlock), the conclusion is that we can, and we must, prevent any
> >possible deadlock by avoiding taking the mutex at all during
> >invalidate_range. This has numerous advantages all of which stem from
> >avoid the sleeping function from inside the unknown context. In
> >particular, it simplifies the invalidate_range because we no longer
> >have to juggle the spinlock/mutex and can just hold the spinlock
> >for the entire walk. To compensate, we have to make get_pages a bit more
> >complicated in order to serialise with a pending cancel_userptr worker.
> >As we hold the struct_mutex, we have no choice but to return EAGAIN and
> >hope that the worker is then flushed before we retry after reacquiring
> >the struct_mutex.
> >
> >The important caveat is that the invalidate_range itself is no longer
> >synchronous. There exists a small but definite period in time in which
> >the old PTE's page remain accessible via the GPU. Note however that the
> >physical pages themselves are not invalidated by the mmu_notifier, just
> >the CPU view of the address space. The impact should be limited to a
> >delay in pages being flushed, rather than a possibility of writing to
> >the wrong pages. The only race condition that this worsens is remapping
> >an userptr active on the GPU where fresh work may still reference the
> >old pages due to struct_mutex contention. Given that userspace is racing
> >with the GPU, it is fair to say that the results are undefined.
> >
> >v2: Only queue (and importantly only take one refcnt) the worker once.
> 
> This one I looked at at the time of previous posting and it looked
> fine, minus one wrong line of thinking of mine. On a brief look it
> still looks good, so:
> 
> Reviewed-by: Tvrtko Ursulin 
> 
> I assume Michał has run all these through the relevant test cases?
> 
> Slightly related, I now worry about the WARN_ONs in
> __cancel_userptr__worker since they look to be triggerable by
> malicious userspace which is not good.

They could always be I thought, if you could somehow pin the userptr
into a hardware register and then unmap the vma. That is a scary thought
and one I would like a WARN for. That should be the only way, and I shudder
at the prospect of working out who to send the SIGBUS to.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: add kerneldoc for i915_audio_component

[Takashi Iwai]

On Wed, 09 Sep 2015 17:09:52 +0200,
Daniel Vetter wrote:
> 
> On Wed, Sep 09, 2015 at 01:45:47AM +, Yang, Libin wrote:
> > Hi Daniel,
> > 
> > As Takashi has already accepted the first 3 patches for 
> > sync_audio_rate() and the patches are not merged
> > into -nightly branch. If I make a kerneldoc patch
> > based on currently -nightly branch, there will
> > be conflict when you are merging Takashi's branch.
> > 
> > What do you think if I make the kerneldoc patch
> > after the sync_audio_rate() patches are merged
> > into the -nightly branch?
> 
> Hm, I do pull in sound/for-next into drm-intel-nightly ... Are the patches
> somewhere else? I can easily add another branch to nightly to make things
> easier. Takashi, which branches should I all pull in to get all the audio
> stuff into drm-intel-nightly?

No, it's not merged into for-next branch because the 4th patch is
missing, and I didn't get your proper ack yet.  The three patches are
left in topic/drm-sync-audio-rate branch.  If these are OK for you,
I'll add Acked-by to them before you pulling it (if any).

But, still I'm not sure whether we should really merge these partial
changes to 4.3.  Will the last patch be ready in time?  If yes, we can
go forward now.


thanks,

Takashi

> 
> Thanks, Daniel
> 
> > 
> > Regards,
> > Libin
> > 
> > 
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > > Daniel Vetter
> > > Sent: Friday, September 04, 2015 3:55 PM
> > > To: Jani Nikula
> > > Cc: Yang, Libin; Daniel Vetter; intel-gfx@lists.freedesktop.org;
> > > daniel.vet...@ffwll.ch; ville.syrj...@linux.intel.com
> > > Subject: Re: [PATCH] drm/i915: add kerneldoc for
> > > i915_audio_component
> > > 
> > > On Fri, Sep 04, 2015 at 09:40:17AM +0300, Jani Nikula wrote:
> > > > On Fri, 04 Sep 2015, "Yang, Libin"  wrote:
> > > > >> -Original Message-
> > > > >> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > > > >> Daniel Vetter
> > > > >> Sent: Wednesday, September 02, 2015 8:18 PM
> > > > >> To: Yang, Libin
> > > > >> Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> > > > >> jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com
> > > > >> Subject: Re: [PATCH] drm/i915: add kerneldoc for
> > > > >> i915_audio_component
> > > > >>
> > > > >> On Wed, Sep 02, 2015 at 02:12:24PM +0800,
> > > libin.y...@intel.com
> > > > >> wrote:
> > > > >> > From: Libin Yang 
> > > > >> >
> > > > >> > Add the kerneldoc for i915_audio_component in
> > > i915_component.h
> > > > >> >
> > > > >> > Signed-off-by: Libin Yang 
> > > > >> > ---
> > > > >> >  include/drm/i915_component.h | 39
> > > --
> > > > >> -
> > > > >> >  1 file changed, 24 insertions(+), 15 deletions(-)
> > > > >> >
> > > > >> > diff --git a/include/drm/i915_component.h
> > > > >> b/include/drm/i915_component.h
> > > > >> > index 8ad6f1b..187acc8 100644
> > > > >> > --- a/include/drm/i915_component.h
> > > > >> > +++ b/include/drm/i915_component.h
> > > > >> > @@ -24,23 +24,32 @@
> > > > >> >  #ifndef _I915_COMPONENT_H_
> > > > >> >  #define _I915_COMPONENT_H_
> > > > >> >
> > > > >> > +/**
> > > > >> > + * struct i915_audio_component_ops - callbacks defined in gfx
> > > > >> driver
> > > > >> > + * @owner: the module owner
> > > > >> > + * @get_power: get the POWER_DOMAIN_AUDIO power well
> > > > >> > + * @put_power: put the POWER_DOMAIN_AUDIO power well
> > > > >> > + * @codec_wake_override: Enable/Disable generating the
> > > codec
> > > > >> wake signal
> > > > >> > + * @get_cdclk_freq: get the Core Display Clock in KHz
> > > > >> > + * @sync_audio_rate: set n/cts based on the sample rate
> > > > >> > + */
> > > > >> > +struct i915_audio_component_ops {
> > > > >> > +  struct module *owner;
> > > > >>
> > > > >> New kerneldoc in 4.3 allows you to split structure documentation
> > > up
> > > > >> into
> > > > >> per-member comments. Especially with vtables I think this makes
> > > a lot
> > > > >> of
> > > > >> sense, since then you have enough space to document where and
> > > how
> > > > >> exactly
> > > > >> a given hook is called (looks, place in the overall sequence).
> > > > >>
> > > > >> Also please include your stancas in the drm.tmpl docbook
> > > template,
> > > > >> otherwise it won't be included in the html docs. And finally please
> > > add
> > > > >
> > > > > OK, I will add it in drm.tmpl.
> > > > >
> > > > >> a
> > > > >> DOC: overview section which explains at a high level how i915 and
> > > > >> hda-intel corporate for hdmi/dp audio.
> > > > >
> > > > > Where the DOC should be located in?
> > > >
> > > > i915/intel_audio.c already has a "DOC: High Definition Audio over
> > > HDMI
> > > > and Display Port" comment. IMO you could just amend that, as
> > > there's
> > > > already some references to the audio driver.
> > > 
> > > Yeah I think that would be a perfect place.
> > > -Daniel
> > > --
> 

Re: [Intel-gfx] [RFC] drm/i915: Render decompression support for Gen9 and above

[Daniel Vetter]

On Tue, Sep 08, 2015 at 03:07:40PM -0700, Jesse Barnes wrote:
> On 09/07/2015 09:35 AM, Daniel Vetter wrote:
> > On Sat, Sep 05, 2015 at 01:12:50AM +0530, Vandana Kannan wrote:
> >> This patch includes enabling render decompression after checking all the
> >> requirements (format, tiling, rotation etc.). Along with this, the WAs
> >> mentioned in BSpec Workaround page have been implemented.
> >>
> >> This patch has been implemented on top of Nabendu/Chandra's NV12 patches.
> >>
> >> TODO:
> >> 1. Disable stereo 3D when render decomp is enabled (bit 7:6)
> >> 2. Render decompression must not be used in VTd pass-through mode
> >> 3. Program hashing select CHICKEN_MISC1 bit 15
> >> 4. For Gen10, add support for RGB 1010102
> >>
> >> Signed-off-by: Vandana Kannan 
> >> ---
> >>  drivers/gpu/drm/drm_atomic.c |   4 +
> >>  drivers/gpu/drm/drm_crtc.c   |  16 
> >>  drivers/gpu/drm/i915/intel_display.c | 174 
> >> +++
> >>  drivers/gpu/drm/i915/intel_drv.h |   7 ++
> >>  drivers/gpu/drm/i915/intel_sprite.c  |  35 +++
> >>  include/drm/drm_crtc.h   |  11 +++
> >>  6 files changed, 247 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index 940f80b..d9004e8 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -607,6 +607,8 @@ int drm_atomic_plane_set_property(struct drm_plane 
> >> *plane,
> >>state->src_h = val;
> >>} else if (property == config->rotation_property) {
> >>state->rotation = val;
> >> +  } else if (property == config->compression_property) {
> >> +  state->compression = val;
> > 
> > Please use a framebuffer modifier instead. Also this needs userspace.
> 
> I thought we already agreed, based on feedback from the userspace guys,
> that a property was easier to use and therefore the way to go?

Blob hwc want a property because they're afraid of the overhead of
creating an additional drm fb object. Until I see data that that overhead
is real I see no reason at all to have something else than what the
community consensus for these features from 1 year ago at xdc bordeaux.

If someone disagrees please convince Rob Clark and Thierry Redding (and
whomever else took part in that discussion) that we need to change this, I
personally don't see the value in this particular bikeshed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm/i915: Render decompression support for Gen9 and above

[Jesse Barnes]

On 09/09/2015 08:23 AM, Daniel Vetter wrote:
> On Tue, Sep 08, 2015 at 03:07:40PM -0700, Jesse Barnes wrote:
>> On 09/07/2015 09:35 AM, Daniel Vetter wrote:
>>> On Sat, Sep 05, 2015 at 01:12:50AM +0530, Vandana Kannan wrote:
 This patch includes enabling render decompression after checking all the
 requirements (format, tiling, rotation etc.). Along with this, the WAs
 mentioned in BSpec Workaround page have been implemented.

 This patch has been implemented on top of Nabendu/Chandra's NV12 patches.

 TODO:
 1. Disable stereo 3D when render decomp is enabled (bit 7:6)
 2. Render decompression must not be used in VTd pass-through mode
 3. Program hashing select CHICKEN_MISC1 bit 15
 4. For Gen10, add support for RGB 1010102

 Signed-off-by: Vandana Kannan 
 ---
  drivers/gpu/drm/drm_atomic.c |   4 +
  drivers/gpu/drm/drm_crtc.c   |  16 
  drivers/gpu/drm/i915/intel_display.c | 174 
 +++
  drivers/gpu/drm/i915/intel_drv.h |   7 ++
  drivers/gpu/drm/i915/intel_sprite.c  |  35 +++
  include/drm/drm_crtc.h   |  11 +++
  6 files changed, 247 insertions(+)

 diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
 index 940f80b..d9004e8 100644
 --- a/drivers/gpu/drm/drm_atomic.c
 +++ b/drivers/gpu/drm/drm_atomic.c
 @@ -607,6 +607,8 @@ int drm_atomic_plane_set_property(struct drm_plane 
 *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
 +  } else if (property == config->compression_property) {
 +  state->compression = val;
>>>
>>> Please use a framebuffer modifier instead. Also this needs userspace.
>>
>> I thought we already agreed, based on feedback from the userspace guys,
>> that a property was easier to use and therefore the way to go?
> 
> Blob hwc want a property because they're afraid of the overhead of
> creating an additional drm fb object. Until I see data that that overhead
> is real I see no reason at all to have something else than what the
> community consensus for these features from 1 year ago at xdc bordeaux.
> 
> If someone disagrees please convince Rob Clark and Thierry Redding (and
> whomever else took part in that discussion) that we need to change this, I
> personally don't see the value in this particular bikeshed.

I don't think it was overhead, just convenience and reasoning about how
the feature is used.  Cc'ing Gary for more background.

Jesse

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

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS

[Chris Wilson]

On Wed, Sep 09, 2015 at 06:28:50PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 08, 2015 at 09:16:11PM +0100, Chris Wilson wrote:
> > Would it make sense to disable dvfs after a failure as well,
> > then the user is shown a single DRM_ERROR at runtime and we should
> > recover (by not going to the full WM next time)?
> 
> I wouldn't expect any failures after we've determined that it works.
> That would indicate Punit going belly up or something, and then I'm
> not sure anything would work anymore.

We didn't expect any before either :) And it sounds like you are arguing
that we should be reducing the noise from the victims as well :)
-Chris

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

[Intel-gfx] [PATCH] drm: Remove __OS_HAS_AGP

[Daniel Vetter]

We already express the drm/agp depencies correctly in Kconfig, so we
can rip this remnant from the shared drm core days.

Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
if ttm would provide dummy functions. I'm not going to volunteer for
that though.

v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville

v3: Polish from Ville's review.

Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Christian König  (v2)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/Makefile |  3 ++-
 drivers/gpu/drm/drm_agpsupport.c |  4 
 drivers/gpu/drm/drm_bufs.c   |  6 +++---
 drivers/gpu/drm/drm_ioc32.c  |  6 +++---
 drivers/gpu/drm/drm_ioctl.c  |  2 +-
 drivers/gpu/drm/drm_memory.c |  6 +++---
 drivers/gpu/drm/drm_vm.c |  8 
 drivers/gpu/drm/mga/mga_dma.c|  4 ++--
 drivers/gpu/drm/nouveau/nouveau_bo.c |  8 
 drivers/gpu/drm/r128/r128_cce.c  | 12 ++--
 drivers/gpu/drm/radeon/r600_cp.c | 14 +++---
 drivers/gpu/drm/radeon/radeon_agp.c  |  8 
 drivers/gpu/drm/radeon/radeon_cp.c   | 16 
 drivers/gpu/drm/radeon/radeon_ttm.c  | 10 +-
 include/drm/drm_agpsupport.h |  9 +++--
 15 files changed, 55 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 45e7719846b1..f458d6e33655 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -6,7 +6,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
-   drm_agpsupport.o drm_scatter.o drm_pci.o \
+   drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
@@ -19,6 +19,7 @@ drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
+drm-$(CONFIG_AGP) += drm_agpsupport.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 4b2b4aa5033b..a10ea6aec629 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -36,8 +36,6 @@
 #include 
 #include "drm_legacy.h"
 
-#if __OS_HAS_AGP
-
 #include 
 
 /**
@@ -502,5 +500,3 @@ drm_agp_bind_pages(struct drm_device *dev,
return mem;
 }
 EXPORT_SYMBOL(drm_agp_bind_pages);
-
-#endif /* __OS_HAS_AGP */
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 569064a00693..f1a204d253cc 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -582,7 +582,7 @@ static void drm_cleanup_buf_error(struct drm_device * dev,
}
 }
 
-#if __OS_HAS_AGP
+#if IS_ENABLED(CONFIG_AGP)
 /**
  * Add AGP buffers for DMA transfers.
  *
@@ -756,7 +756,7 @@ int drm_legacy_addbufs_agp(struct drm_device *dev,
return 0;
 }
 EXPORT_SYMBOL(drm_legacy_addbufs_agp);
-#endif /* __OS_HAS_AGP */
+#endif /* CONFIG_AGP */
 
 int drm_legacy_addbufs_pci(struct drm_device *dev,
   struct drm_buf_desc *request)
@@ -1145,7 +1145,7 @@ int drm_legacy_addbufs(struct drm_device *dev, void *data,
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
return -EINVAL;
 
-#if __OS_HAS_AGP
+#if IS_ENABLED(CONFIG_AGP)
if (request->flags & _DRM_AGP_BUFFER)
ret = drm_legacy_addbufs_agp(dev, request);
else
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index ddfa6014c2c2..57676f8d7ecf 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -720,7 +720,7 @@ static int compat_drm_dma(struct file *file, unsigned int 
cmd,
return 0;
 }
 
-#if __OS_HAS_AGP
+#if IS_ENABLED(CONFIG_AGP)
 typedef struct drm_agp_mode32 {
u32 mode;   /**< AGP mode */
 } drm_agp_mode32_t;
@@ -882,7 +882,7 @@ static int compat_drm_agp_unbind(struct file *file, 
unsigned int cmd,
 
return drm_ioctl(file, DRM_IOCTL_AGP_UNBIND, (unsigned long)request);
 }
-#endif /* __OS_HAS_AGP */
+#endif /* CONFIG_AGP */
 
 typedef struct drm_scatter_gather32 {
u32 size;   /**< In bytes -- will round to page boundary */
@@ -1090,7 +1090,7 @@ static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_GET_SAREA_CTX32)] = compat_drm_getsareactx,
[DRM_IOCTL_NR(DRM_IOCTL_RES_CTX32)] = compat_drm_resctx,
[DRM_IOCTL_NR(DRM_IOCTL_DMA32)] = 

[Intel-gfx] [PATCH] drm/i915: Fix CSR MMIO address check

[Takashi Iwai]

Fix a wrong logical AND (&&) used for the range check of CSR MMIO.

Spotted nicely by gcc -Wlogical-op flag:
  drivers/gpu/drm/i915/intel_csr.c: In function ‘finish_csr_load’:
  drivers/gpu/drm/i915/intel_csr.c:353:41: warning: logical ‘and’ of mutually 
exclusive tests is always false [-Wlogical-op]

Fixes: eb805623d8b1 ('drm/i915/skl: Add support to load SKL CSR firmware.')
Cc:  # v4.2
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/intel_csr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index ba1ae031e6fd..d0f1b8d833cd 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -350,7 +350,7 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
}
csr->mmio_count = dmc_header->mmio_count;
for (i = 0; i < dmc_header->mmio_count; i++) {
-   if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE &&
+   if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE ||
dmc_header->mmioaddr[i] > CSR_MMIO_END_RANGE) {
DRM_ERROR(" Firmware has wrong mmio address 0x%x\n",
dmc_header->mmioaddr[i]);
-- 
2.5.1

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

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: Fix userptr deadlock with aliased GTT mmappings

[Chris Wilson]

On Wed, Sep 09, 2015 at 02:56:16PM +0100, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 08/10/2015 09:51 AM, Chris Wilson wrote:
> > +out:
> > drm_free_large(pvec);
> > return ret;
> > +
> > +err:
> > +   /* No pages here, no need for the mmu-notifier to wake us */
> > +   __i915_gem_userptr_set_active(obj, false);
> > +err_active:
> > +   release_pages(pvec, pinned, 0);
> > +   goto out;
> >   }
> 
> I don't like the goto dance. Would something like the below be clearer?

We can condense it if we use a bool active and then feed everything
through the single exit path:

active = false;
if (pinned < 0)
ret = pinned, pinned = 0;
else if (pinned < num_pages)
ret = __i915_gem_userptr_get_pages_queue(obj, );
else
ret = __i915_gem_userptr_set_pages(obj, pvec, num_pages);
if (ret) {
__i915_gem_userptr_set_active(obj, active);
release_pages(pvec, pinned, 0);
}
drm_free_large(pvec);
return ret;

Not happy with _queue. I guess i915_gem_userptr_get_pages_via_worker()
is better. Or i915_gem_userptr_get_pages_deferred().
-Chris

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

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 07/11] drm/i915: Added the generic gpio sequence support and gpio table

[Deepak M]

The generic gpio is sequence is parsed from the VBT and the
GPIO table is updated with the North core, South core and
SUS core elements.

v2: Move changes in sideband.c file to new patch(Jani), rebase

Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_reg.h|5 +
 drivers/gpu/drm/i915/intel_dsi.h   |  351 
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |  215 -
 3 files changed, 559 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 84ed9ab..5bef50c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -568,6 +568,11 @@
 #define   IOSF_PORT_DPIO   0x12
 #define   IOSF_PORT_DPIO_2 0x1a
 #define   IOSF_PORT_GPIO_NC0x13
+#define   IOSF_PORT_GPIO_SC0x48
+#define   IOSF_PORT_GPIO_SUS   0xA8
+#define   MAX_GPIO_NUM_NC  26
+#define   MAX_GPIO_NUM_SC  128
+#define   MAX_GPIO_NUM 172
 #define   IOSF_PORT_CCK0x14
 #define   IOSF_PORT_CCU0xA9
 #define   IOSF_PORT_GPS_CORE   0x48
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 42a6859..fc89a6b 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -34,6 +34,357 @@
 #define DSI_DUAL_LINK_FRONT_BACK   1
 #define DSI_DUAL_LINK_PIXEL_ALT2
 
+#define HV_DDI0_HPD_GPIONC_0_PCONF00x4130
+#define HV_DDI0_HPD_GPIONC_0_PAD   0x4138
+#define HV_DDI0_DDC_SDA_GPIONC_1_PCONF00x4120
+#define HV_DDI0_DDC_SDA_GPIONC_1_PAD   0x4128
+#define HV_DDI0_DDC_SCL_GPIONC_2_PCONF00x4110
+#define HV_DDI0_DDC_SCL_GPIONC_2_PAD   0x4118
+#define PANEL0_VDDEN_GPIONC_3_PCONF0   0x4140
+#define PANEL0_VDDEN_GPIONC_3_PAD  0x4148
+#define PANEL0_BKLTEN_GPIONC_4_PCONF0  0x4150
+#define PANEL0_BKLTEN_GPIONC_4_PAD 0x4158
+#define PANEL0_BKLTCTL_GPIONC_5_PCONF0 0x4160
+#define PANEL0_BKLTCTL_GPIONC_5_PAD0x4168
+#define HV_DDI1_HPD_GPIONC_6_PCONF00x4180
+#define HV_DDI1_HPD_GPIONC_6_PAD   0x4188
+#define HV_DDI1_DDC_SDA_GPIONC_7_PCONF00x4190
+#define HV_DDI1_DDC_SDA_GPIONC_7_PAD   0x4198
+#define HV_DDI1_DDC_SCL_GPIONC_8_PCONF00x4170
+#define HV_DDI1_DDC_SCL_GPIONC_8_PAD   0x4178
+#define PANEL1_VDDEN_GPIONC_9_PCONF0   0x4100
+#define PANEL1_VDDEN_GPIONC_9_PAD  0x4108
+#define PANEL1_BKLTEN_GPIONC_10_PCONF0 0x40E0
+#define PANEL1_BKLTEN_GPIONC_10_PAD0x40E8
+#define PANEL1_BKLTCTL_GPIONC_11_PCONF00x40F0
+#define PANEL1_BKLTCTL_GPIONC_11_PAD   0x40F8
+#define GP_INTD_DSI_TE1_GPIONC_12_PCONF0   0x40C0
+#define GP_INTD_DSI_TE1_GPIONC_12_PAD  0x40C8
+#define HV_DDI2_DDC_SDA_GPIONC_13_PCONF0   0x41A0
+#define HV_DDI2_DDC_SDA_GPIONC_13_PAD  0x41A8
+#define HV_DDI2_DDC_SCL_GPIONC_14_PCONF0   0x41B0
+#define HV_DDI2_DDC_SCL_GPIONC_14_PAD  0x41B8
+#define GP_CAMERASB00_GPIONC_15_PCONF0 0x4010
+#define GP_CAMERASB00_GPIONC_15_PAD0x4018
+#define GP_CAMERASB01_GPIONC_16_PCONF0 0x4040
+#define GP_CAMERASB01_GPIONC_16_PAD0x4048
+#define GP_CAMERASB02_GPIONC_17_PCONF0 0x4080
+#define GP_CAMERASB02_GPIONC_17_PAD0x4088
+#define GP_CAMERASB03_GPIONC_18_PCONF0 0x40B0
+#define GP_CAMERASB03_GPIONC_18_PAD0x40B8
+#define GP_CAMERASB04_GPIONC_19_PCONF0 0x4000
+#define GP_CAMERASB04_GPIONC_19_PAD0x4008
+#define GP_CAMERASB05_GPIONC_20_PCONF0 0x4030
+#define GP_CAMERASB05_GPIONC_20_PAD0x4038
+#define GP_CAMERASB06_GPIONC_21_PCONF0 0x4060
+#define GP_CAMERASB06_GPIONC_21_PAD0x4068
+#define GP_CAMERASB07_GPIONC_22_PCONF0 0x40A0
+#define GP_CAMERASB07_GPIONC_22_PAD0x40A8
+#define GP_CAMERASB08_GPIONC_23_PCONF0 0x40D0
+#define GP_CAMERASB08_GPIONC_23_PAD0x40D8
+#define GP_CAMERASB09_GPIONC_24_PCONF0 0x4020
+#define GP_CAMERASB09_GPIONC_24_PAD0x4028
+#define GP_CAMERASB10_GPIONC_25_PCONF0 0x4050
+#define GP_CAMERASB10_GPIONC_25_PAD0x4058
+#define GP_CAMERASB11_GPIONC_26_PCONF0 0x4090
+#define GP_CAMERASB11_GPIONC_26_PAD0x4098
+
+#define SATA_GP0_GPIOC_0_PCONF00x4550
+#define SATA_GP0_GPIOC_0_PAD   0x4558
+#define SATA_GP1_GPIOC_1_PCONF00x4590
+#define SATA_GP1_GPIOC_1_PAD   0x4598
+#define SATA_LEDN_GPIOC_2_PCONF0   0x45D0
+#define SATA_LEDN_GPIOC_2_PAD  0x45D8
+#define 

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 09/11] drm: Add few more wrapper functions for drm panel

[Deepak M]

Currently there are few pair of functions which
are called during the panel enable/disable sequence.
To improve the granularity, adding few more wrapper
functions so that the functions are more specific
on what they are doing.

v2: rebase

Signed-off-by: Deepak M 
Signed-off-by: Gaurav K Singh 
---
 include/drm/drm_panel.h |   47 +++
 1 file changed, 47 insertions(+)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 13ff44b..c729f6d 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -73,6 +73,12 @@ struct drm_panel_funcs {
int (*get_modes)(struct drm_panel *panel);
int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
   struct display_timing *timings);
+   int (*power_on)(struct drm_panel *panel);
+   int (*power_off)(struct drm_panel *panel);
+   int (*backlight_on)(struct drm_panel *panel);
+   int (*backlight_off)(struct drm_panel *panel);
+   int (*get_info)(struct drm_panel *panel,
+   struct drm_connector *connector);
 };
 
 struct drm_panel {
@@ -117,6 +123,47 @@ static inline int drm_panel_enable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
 }
 
+static inline int drm_panel_power_on(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->power_on)
+   return panel->funcs->power_on(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_power_off(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->power_off)
+   return panel->funcs->power_off(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_backlight_on(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->backlight_on)
+   return panel->funcs->backlight_on(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_backlight_off(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->backlight_off)
+   return panel->funcs->backlight_off(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
+static inline int drm_panel_get_info(struct drm_panel *panel,
+   struct drm_connector *connector)
+{
+   if (connector && panel && panel->funcs && panel->funcs->get_info)
+   return panel->funcs->get_info(panel, connector);
+
+   return panel ? -ENOSYS : -EINVAL;
+}
+
 static inline int drm_panel_get_modes(struct drm_panel *panel)
 {
if (panel && panel->funcs && panel->funcs->get_modes)
-- 
1.7.9.5

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

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 08/11] drm/i915: GPIO for CHT generic MIPI

[Deepak M]

From: Yogesh Mohan Marimuthu 

The GPIO configuration and register offsets are different from
baytrail for cherrytrail. Port the gpio programming accordingly
for cherrytrail in this patch.

v2: Rebase

Signed-off-by: Yogesh Mohan Marimuthu 
---
 drivers/gpu/drm/i915/i915_reg.h|   23 ++
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |  117 +++-
 2 files changed, 122 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5bef50c..c5bea41 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -568,11 +568,21 @@
 #define   IOSF_PORT_DPIO   0x12
 #define   IOSF_PORT_DPIO_2 0x1a
 #define   IOSF_PORT_GPIO_NC0x13
+#define   CHV_IOSF_PORT_GPIO_N 0x13
 #define   IOSF_PORT_GPIO_SC0x48
+#define   CHV_IOSF_PORT_GPIO_SE0x48
+#define   CHV_IOSF_PORT_GPIO_SW0xB2
 #define   IOSF_PORT_GPIO_SUS   0xA8
+#define   CHV_IOSF_PORT_GPIO_E 0xA8
 #define   MAX_GPIO_NUM_NC  26
 #define   MAX_GPIO_NUM_SC  128
 #define   MAX_GPIO_NUM 172
+#define   CHV_MAX_GPIO_NUM_N   72
+#define   CHV_MAX_GPIO_NUM_SE  99
+#define   CHV_MAX_GPIO_NUM_SW  197
+#define   CHV_MIN_GPIO_NUM_SE  73
+#define   CHV_MIN_GPIO_NUM_SW  100
+#define   CHV_MIN_GPIO_NUM_E   198
 #define   IOSF_PORT_CCK0x14
 #define   IOSF_PORT_CCU0xA9
 #define   IOSF_PORT_GPS_CORE   0x48
@@ -580,6 +590,19 @@
 #define VLV_IOSF_DATA  (VLV_DISPLAY_BASE + 0x2104)
 #define VLV_IOSF_ADDR  (VLV_DISPLAY_BASE + 0x2108)
 
+#define VLV_GPIO_CFG   0x2000CC00
+#define VLV_GPIO_INPUT_DIS 0x04
+
+#define CHV_PAD_FMLY_BASE  0x4400
+#define CHV_PAD_FMLY_SIZE  0x400
+#define CHV_PAD_CFG_0_1_REG_SIZE   0x8
+#define CHV_PAD_CFG_REG_SIZE   0x4
+#define CHV_VBT_MAX_PINS_PER_FMLY  15
+
+#define CHV_GPIO_CFG_UNLOCK0x
+#define CHV_GPIO_CFG_HiZ   0x8100
+#define CHV_GPIO_CFG_TX_STATE_SHIFT1
+
 /* See configdb bunit SB addr map */
 #define BUNIT_REG_BISOC0x11
 
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 1aa5b19..b0d09f6 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -418,17 +418,75 @@ static const u8 *mipi_exec_delay(struct intel_dsi 
*intel_dsi, const u8 *data)
 
return data;
 }
-
-static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
+static int chv_program_gpio(struct intel_dsi *intel_dsi,
+   const u8 *data, const u8 **cur_data)
 {
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
u8 gpio, action;
+   u16 family_num;
u16 function, pad;
-   u32 val;
u8 block;
+
+   /*
+* Skipping the first byte as it is of no
+* interest for linux kernel in new VBT version
+*/
+   if (dev_priv->vbt.dsi.seq_version >= 3)
+   data++;
+
+   gpio = *data++;
+
+   /* pull up/down */
+   action = *data++;
+
+   if (dev_priv->vbt.dsi.seq_version >= 3) {
+   if (gpio <= CHV_MAX_GPIO_NUM_N) {
+   block = CHV_IOSF_PORT_GPIO_N;
+   DRM_DEBUG_DRIVER("GPIO is in the north Block\n");
+   } else if (gpio <= CHV_MAX_GPIO_NUM_SE) {
+   block = CHV_IOSF_PORT_GPIO_SE;
+   gpio = gpio - CHV_MIN_GPIO_NUM_SE;
+   DRM_DEBUG_DRIVER("GPIO is in the south east Block\n");
+   } else if (gpio <= CHV_MAX_GPIO_NUM_SW) {
+   block = CHV_IOSF_PORT_GPIO_SW;
+   gpio = gpio - CHV_MIN_GPIO_NUM_SW;
+   DRM_DEBUG_DRIVER("GPIO is in the south west Block\n");
+   } else {
+   block = CHV_IOSF_PORT_GPIO_E;
+   gpio = gpio - CHV_MIN_GPIO_NUM_E;
+   DRM_DEBUG_DRIVER("GPIO is in the east Block\n");
+   }
+   } else
+   block = IOSF_PORT_GPIO_NC;
+
+   family_num =  gpio / CHV_VBT_MAX_PINS_PER_FMLY;
+   gpio = gpio - (family_num * CHV_VBT_MAX_PINS_PER_FMLY);
+   pad = CHV_PAD_FMLY_BASE + (family_num * CHV_PAD_FMLY_SIZE) +
+   (((u16)gpio) 

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 06/11] drm/i915: extending gpio read/write to other cores

[Deepak M]

Adding a argument to the gpio read/write functions
which accepts the block name.

v2: rebase

Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_drv.h|5 +++--
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |4 ++--
 drivers/gpu/drm/i915/intel_sideband.c  |9 +
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 91ccbc6..ed3b19b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3363,8 +3363,9 @@ int sandybridge_pcode_write(struct drm_i915_private 
*dev_priv, u32 mbox, u32 val
 u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
 void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
 u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+u32 vlv_gpio_read(struct drm_i915_private *dev_priv, u8 core_offset, u32 reg);
+void vlv_gpio_write(struct drm_i915_private *dev_priv, u8 core_offset,
+   u32 reg, u32 val);
 u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index c6a6fa1..02f1cd5 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -276,14 +276,14 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
if (!gtable[gpio].init) {
/* program the function */
/* FIXME: remove constant below */
-   vlv_gpio_nc_write(dev_priv, function, 0x2000CC00);
+   vlv_gpio_write(dev_priv, IOSF_PORT_GPIO_NC, function, 
0x2000CC00);
gtable[gpio].init = 1;
}
 
val = 0x4 | action;
 
/* pull up/down */
-   vlv_gpio_nc_write(dev_priv, pad, val);
+   vlv_gpio_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
mutex_unlock(_priv->sb_lock);
 
return data;
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index 8831fc5..3e0cbe6 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -129,17 +129,18 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 
addr)
return val;
 }
 
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
+u32 vlv_gpio_read(struct drm_i915_private *dev_priv, u8 core_offset, u32 reg)
 {
u32 val = 0;
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+   vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), core_offset,
SB_CRRDDA_NP, reg, );
return val;
 }
 
-void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+void vlv_gpio_write(struct drm_i915_private *dev_priv, u8 core_offset,
+   u32 reg, u32 val)
 {
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+   vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), core_offset,
SB_CRWRDA_NP, reg, );
 }
 
-- 
1.7.9.5

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

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 10/11] drm/i915: Add functions to execute the new sequences from VBT

[Deepak M]

From: Gaurav K Singh 

New sequences are added in the mipi sequence block of the
VBT from version 3 onwards. The sequences are added to
make the code more generic as the panel related info
are placed in the VBT.

v2: rebase

Signed-off-by: Gaurav K Singh 
Signed-off-by: Shobhit Kumar 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |   84 +++-
 1 file changed, 83 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index b0d09f6..2263559 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -584,7 +584,13 @@ static const char * const seq_name[] = {
"MIPI_SEQ_INIT_OTP",
"MIPI_SEQ_DISPLAY_ON",
"MIPI_SEQ_DISPLAY_OFF",
-   "MIPI_SEQ_DEASSERT_RESET"
+   "MIPI_SEQ_DEASSERT_RESET",
+   "MIPI_SEQ_BACKLIGHT_ON",
+   "MIPI_SEQ_BACKLIGHT_OFF",
+   "MIPI_SEQ_TEAR_ON",
+   "MIPI_SEQ_TEAR_OFF",
+   "MIPI_SEQ_POWER_ON",
+   "MIPI_SEQ_POWER_OFF"
 };
 
 static void generic_exec_sequence(struct intel_dsi *intel_dsi, const u8 *data)
@@ -713,12 +719,88 @@ static int vbt_panel_get_modes(struct drm_panel *panel)
return 1;
 }
 
+static int vbt_panel_power_on(struct drm_panel *panel)
+{
+   struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+   struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   const u8 *sequence;
+
+   sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_POWER_ON];
+   generic_exec_sequence(intel_dsi, sequence);
+
+   return 0;
+}
+
+static int vbt_panel_power_off(struct drm_panel *panel)
+{
+   struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+   struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   const u8 *sequence;
+
+   sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_POWER_OFF];
+   generic_exec_sequence(intel_dsi, sequence);
+
+   return 0;
+}
+
+static int vbt_panel_backlight_on(struct drm_panel *panel)
+{
+   struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+   struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   const u8 *sequence;
+
+   sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_ON];
+   generic_exec_sequence(intel_dsi, sequence);
+
+   return 0;
+}
+
+static int vbt_panel_backlight_off(struct drm_panel *panel)
+{
+   struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+   struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   const u8 *sequence;
+
+   sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_OFF];
+   generic_exec_sequence(intel_dsi, sequence);
+
+   return 0;
+}
+
+static int vbt_panel_get_info(struct drm_panel *panel,
+   struct drm_connector *connector)
+{
+   struct intel_connector *intel_connector =
+   to_intel_connector(connector);
+
+   if (intel_connector) {
+   connector->display_info.width_mm =
+   intel_connector->panel.fixed_mode->width_mm;
+   connector->display_info.height_mm =
+   intel_connector->panel.fixed_mode->height_mm;
+   }
+   return 0;
+}
+
 static const struct drm_panel_funcs vbt_panel_funcs = {
.disable = vbt_panel_disable,
.unprepare = vbt_panel_unprepare,
.prepare = vbt_panel_prepare,
.enable = vbt_panel_enable,
.get_modes = vbt_panel_get_modes,
+   .power_on = vbt_panel_power_on,
+   .power_off = vbt_panel_power_off,
+   .backlight_on = vbt_panel_backlight_on,
+   .backlight_off = vbt_panel_backlight_off,
+   .get_info = vbt_panel_get_info,
 };
 
 struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id)
-- 
1.7.9.5

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

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 11/11] drm/i915: BXT GPIO support for backlight and panel control

[Deepak M]

From: Uma Shankar 

Added the BXT GPIO pin configuration and programming logic for
backlight and panel control.

v2: rebase

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |   46 
 1 file changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 2263559..4c5e33a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "i915_drv.h"
@@ -327,6 +328,16 @@ out:
return data;
 }
 
+struct bxt_gpio_table {
+   u16 gpio_pin;
+   u16 offset;
+};
+
+static struct bxt_gpio_table bxt_gtable[] = {
+   {0xC1, 270},
+   {0x1B, 456}
+};
+
 static inline enum port intel_dsi_seq_port_to_port(u8 port)
 {
return port ? PORT_C : PORT_A;
@@ -539,6 +550,39 @@ static int vlv_program_gpio(struct intel_dsi *intel_dsi,
return 0;
 }
 
+static int bxt_program_gpio(struct intel_dsi *intel_dsi,
+   const u8 *data, const u8 **cur_data)
+{
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u8 gpio, action;
+   u16 function;
+
+   /*
+* Skipping the first byte as it is of no
+* interest for android in new version
+*/
+   if (dev_priv->vbt.dsi.seq_version >= 3)
+   data++;
+
+   gpio = *data++;
+
+   /* pull up/down */
+   action = *data++;
+   function = (bxt_gtable[0].gpio_pin == gpio) ?
+   bxt_gtable[0].offset :
+   (bxt_gtable[1].gpio_pin == gpio) ?
+   bxt_gtable[1].offset : 0;
+   if (!function)
+   return -1;
+
+   gpio_request_one(function, GPIOF_DIR_OUT, "MIPI");
+   gpio_set_value(function, action);
+
+   *cur_data = data;
+   return 0;
+}
+
 static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
 {
struct drm_device *dev = intel_dsi->base.base.dev;
@@ -552,6 +596,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
ret = chv_program_gpio(intel_dsi, data, );
else if (IS_VALLEYVIEW(dev))
ret = vlv_program_gpio(intel_dsi, data, );
+   else if (IS_BROXTON(dev))
+   ret = bxt_program_gpio(intel_dsi, data, );
else
DRM_ERROR("GPIO programming missing for this platform.\n");
 
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Add NV12 to primary plane programming.

[Ville Syrjälä]

On Wed, Sep 09, 2015 at 09:09:27PM +, Konduru, Chandra wrote:
> 
> > > > > > > > > > > + /* For tile-Yf, uv-subplane tile width 
> > > > > > > > > > > is
> > 2x of Y-
> > > > > > subplane
> > > > > > > > > > */
> > > > > > > > > > > + aux_stride = fb->modifier[0] ==
> > > > > > > > > > I915_FORMAT_MOD_Yf_TILED ?
> > > > > > > > > > > + stride / 2 : stride;
> > > > > > > > > >
> > > > > > > > > > The 2x part was rather well hidden in the spec. How do we 
> > > > > > > > > > deal
> > with
> > > > > > > > > > cases when the Y stride is an odd number of tiles?
> > > > > > > > >
> > > > > > > > > It should be a round up division to take care of that 
> > > > > > > > > scenario.
> > > > > > > >
> > > > > > > > That would stil lresult in a corrupted picture I think. So I was
> > > > > > > > thinking that we should just refuse to create NCV12 framebuffers
> > with a
> > > > > > > > poorly aligned stride.
> > > > > > > >
> > > > > > > I added a check in intel_framebuffer_init() which should catch 
> > > > > > > them:
> > > > > > > if (mode_cmd->pitches[0] != mode_cmd->pitches[1]) {
> > > > > > > DRM_DEBUG("y and uv subplanes have different 
> > > > > > > pitches\n");
> > > > > > > return -EINVAL;
> > > > > > > }
> > > > > >
> > > > > > That won't catch the case I'm worried about. We would also need to
> > make
> > > > > > sure pitches[1] is aligned to the UV tile width.
> > > > >
> > > > > If caller is following tile/row/pitch alignments properly for 
> > > > > sub-planes of
> > > > > NV12 Yf buffer, above check will catch.
> > > > > But are you referring a case where userland isn't following tile/row 
> > > > > size
> > > > > alignments properly? In that case, above may not catch. But
> > > > > isn't that is the case even with other FB formats if user land not
> > > > > following tile/row/pitch alignments?
> > > >
> > > > We reject any attempt to create a framebuffer with a poorly aligned
> > > > stride.
> > > >
> > > > Hmm. Actually I suppose we should just handle it in
> > > > intel_fb_stride_alignment(). Eg.:
> > > >
> > > > case Yf:
> > > > if (cpp != 1 || pixel_format == DRM_FORMAT_NV12)
> > > > return 128;
> > > > else
> > > > return 64;
> > >
> > > This check is already there in intel_fb_stride_alignment()
> > > which is called from intel_framebuffer_init(). But it always
> > > does for 1st sub-plane which means does for Y.
> > > It needs an update to pass a sub-plane (for UV) parameter,
> > > and made another call for UV-plane alignment check.
> > > Will this be ok?
> > 
> > Yeah. You could in fact just have it loop over all the planes
> > and call it for each. Something like this perhaps:
> > for (i = 0; i < drm_format_num_planes(formt); i++) {
> > intel_fb_stride_alignment(modifier[i], format, i);
> > ...
> > }
> I planned the same, looping for all subplanes.
> 
> > 
> > Or you could pass the cpp/bits_per_pixel instead of the plane index,
> > since that's the only thing for which you need the plane index within
> > the function.
> > 
> > I also started to wonder whether we should repeat most of the other
> > checks in intel_framebuffer_init() for each plane. But it's probably
> > just easier to check that handle, pitch and modifier matches for
> > both planes in the NV12 case. I think you actually missed the
> > modifier check. You just checked that modifier[1] is Yf, but that
> > leaves modifier[0] unchecked. I failed to notice it as well during
> > my review of the relevant patch.
> 
> Added modifier check.
> Made these changes to " drm/i915: Add NV12 support to intel_framebuffer_init"
> patch. Also sending out updated WA patch to move to init clockgating.
> Rest of your feedback is already addressed. 
> Before sending out these 2 patches, any other comments?

Looking at what was said, I think we covered most open items
reasonably well, so fire away. I'll start going through the
updated patches tomorrow.

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

[Intel-gfx] [PATCH 09/15] drm/i915: Add NV12 support to intel_framebuffer_init

[Chandra Konduru]

This patch adds NV12 as supported format to
intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (me)

v3:
-cosmetic update, split checks into two (Ville)

v4:
-Add stride alignment and modifier checks for UV subplane (Ville)

Signed-off-by: Chandra Konduru 
Testcase: igt/kms_nv12
---
 drivers/gpu/drm/i915/intel_display.c |   67 --
 drivers/gpu/drm/i915/intel_drv.h |2 +-
 drivers/gpu/drm/i915/intel_sprite.c  |2 +-
 3 files changed, 57 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 84dad95..6124339 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2906,9 +2906,9 @@ static void ironlake_update_primary_plane(struct drm_crtc 
*crtc,
 }
 
 u32 intel_fb_stride_alignment(struct drm_device *dev, uint64_t fb_modifier,
- uint32_t pixel_format)
+ uint32_t pixel_format, int plane)
 {
-   u32 bits_per_pixel = drm_format_plane_cpp(pixel_format, 0) * 8;
+   u32 bits_per_pixel = drm_format_plane_cpp(pixel_format, plane) * 8;
 
/*
 * The stride is either expressed as a multiple of 64 bytes
@@ -3117,7 +3117,7 @@ static void skylake_update_primary_plane(struct drm_crtc 
*crtc,
 
obj = intel_fb_obj(fb);
stride_div = intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+  fb->pixel_format, 0);
surf_addr = intel_plane_obj_offset(to_intel_plane(plane), obj, 0);
 
/*
@@ -9101,7 +9101,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
 
val = I915_READ(PLANE_STRIDE(pipe, 0));
stride_mult = intel_fb_stride_alignment(dev, fb->modifier[0],
-   fb->pixel_format);
+   fb->pixel_format, 0);
fb->pitches[0] = (val & 0x3ff) * stride_mult;
 
aligned_height = intel_fb_align_height(dev, fb->height,
@@ -11172,7 +11172,7 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
 */
stride = fb->pitches[0] /
 intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+  fb->pixel_format, 0);
 
/*
 * Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on
@@ -14238,6 +14238,7 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
 {
unsigned int aligned_height;
int ret;
+   int i;
u32 pitch_limit, stride_alignment;
 
WARN_ON(!mutex_is_locked(>struct_mutex));
@@ -14277,12 +14278,15 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
return -EINVAL;
}
 
-   stride_alignment = intel_fb_stride_alignment(dev, mode_cmd->modifier[0],
-mode_cmd->pixel_format);
-   if (mode_cmd->pitches[0] & (stride_alignment - 1)) {
-   DRM_DEBUG("pitch (%d) must be at least %u byte aligned\n",
- mode_cmd->pitches[0], stride_alignment);
-   return -EINVAL;
+   /* check stride alignment for sub-planes */
+   for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format); i++) {
+   stride_alignment = intel_fb_stride_alignment(dev, 
mode_cmd->modifier[i],
+mode_cmd->pixel_format, i);
+   if (mode_cmd->pitches[i] & (stride_alignment - 1)) {
+   DRM_DEBUG("subplane %d pitch (%d) must be at least %u 
bytes "
+   "aligned\n", i, mode_cmd->pitches[i], 
stride_alignment);
+   return -EINVAL;
+   }
}
 
pitch_limit = intel_fb_pitch_limit(dev, mode_cmd->modifier[0],
@@ -14349,9 +14353,48 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
return -EINVAL;
}
break;
+   case DRM_FORMAT_NV12:
+   if (INTEL_INFO(dev)->gen < 9) {
+   DRM_DEBUG("unsupported pixel format: %s\n",
+   drm_get_format_name(mode_cmd->pixel_format));
+   return -EINVAL;
+   }
+   if (obj->tiling_mode == I915_TILING_X &&
+   !(mode_cmd->flags & DRM_MODE_FB_MODIFIERS)) {
+   mode_cmd->modifier[1] = I915_FORMAT_MOD_X_TILED;
+   }
+   if (!mode_cmd->offsets[1]) {
+   DRM_DEBUG("uv start offset not set\n");
+   return -EINVAL;
+   }
+   if (mode_cmd->pitches[0] != mode_cmd->pitches[1]) {
+   DRM_DEBUG("y and uv subplanes 

[Intel-gfx] [PATCH i-g-t 2/2] Adding kms_nv12 to test display NV12 feature

[Chandra Konduru]

From: chandra konduru 

This patch adds kms_nv12 test case. It covers testing NV12
in linear/tile-X/tile-Y tiling formats in 0/90/180/270
orientations. For each tiling format, it tests several
combinations of planes and its scaling.

v2:
-Added 90/270 tests (me)
-took out crc test as it isn't adding much value due to chroma upsampling (me)

v3:
-Make --list-subtests option work (Tvrtko)
-Make nv12 unsupported test run properly either as a sub test
 or along with all other tests (me)
-Added nv12 fb with invalid params (Daniel)

v4:
-Avoid modeset for invalid tests (Daniel)

v5:
-Added negative nv12 addfb tests for modifier and stride alignment (me)

Signed-off-by: chandra konduru 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/kms_nv12.c   | 761 +
 3 files changed, 763 insertions(+)
 create mode 100644 tests/kms_nv12.c

diff --git a/tests/.gitignore b/tests/.gitignore
index d6d05ff..2de4712 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -155,6 +155,7 @@ kms_setmode
 kms_sink_crc_basic
 kms_universal_plane
 kms_vblank
+kms_nv12
 pm_backlight
 pm_lpsp
 pm_rc6_residency
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ef69299..a7804fa 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -85,6 +85,7 @@ TESTS_progs_M = \
kms_crtc_background_color \
kms_plane_scaling \
kms_panel_fitting \
+   kms_nv12 \
pm_backlight \
pm_lpsp \
pm_rpm \
diff --git a/tests/kms_nv12.c b/tests/kms_nv12.c
new file mode 100644
index 000..bad6862
--- /dev/null
+++ b/tests/kms_nv12.c
@@ -0,0 +1,761 @@
+/*
+ * Copyright © 2013,2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "igt_core.h"
+#include "intel_chipset.h"
+#include "ioctl_wrappers.h"
+
+IGT_TEST_DESCRIPTION("Test display NV12 support");
+
+uint32_t devid;
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   int num_scalers;
+   int num_planes;
+
+   struct igt_fb fb1;
+   struct igt_fb fb1_nv12;
+   struct igt_fb fb2;
+   struct igt_fb fb2_nv12;
+   struct igt_fb fb3;
+   struct igt_fb fb3_nv12;
+   int fb_id1;
+   int fb_id1_nv12;
+   int fb_id2;
+   int fb_id2_nv12;
+   int fb_id3;
+   int fb_id3_nv12;
+
+   igt_plane_t *plane1;
+   igt_plane_t *plane2;
+   igt_plane_t *plane3;
+
+   uint64_t tiled;
+   int rotation;
+} data_t;
+
+typedef struct {
+   int width;
+   int height;
+} res_t;
+
+#define IMG_FILE  "1080p-left.png"
+
+static void
+paint_pattern(data_t *d, struct igt_fb *fb, uint16_t w, uint16_t h)
+{
+   cairo_t *cr;
+
+   cr = igt_get_cairo_ctx(d->drm_fd, fb);
+   igt_paint_test_pattern(cr, w, h);
+   cairo_destroy(cr);
+}
+
+static void
+paint_image(data_t *d, struct igt_fb *fb, uint16_t w, uint16_t h)
+{
+   cairo_t *cr;
+
+   cr = igt_get_cairo_ctx(d->drm_fd, fb);
+   igt_paint_image(cr, IMG_FILE, 0, 0, w, h);
+   cairo_destroy(cr);
+}
+
+static void prepare_crtc(data_t *data, igt_output_t *output, enum pipe pipe,
+   igt_plane_t *plane, drmModeModeInfo *mode, enum 
igt_commit_style s)
+{
+   igt_display_t *display = >display;
+
+   igt_output_set_pipe(output, pipe);
+
+   /* before allocating, free if any older fb */
+   if (data->fb_id1) {
+   igt_remove_fb(data->drm_fd, >fb1);
+   data->fb_id1 = 0;
+   }
+
+   /* allocate fb for plane 1 */
+   data->fb_id1 = igt_create_fb(data->drm_fd,
+   mode->hdisplay, mode->vdisplay,
+   DRM_FORMAT_XRGB,
+   data->tiled, 

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 01/11] drm/i915: Adding the parsing logic for the i2c element

[Deepak M]

From: vkorjani 

New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.

v2: Add i2c_put_adapter call(Jani), rebase

Signed-off-by: vkorjani 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_bios.c  |6 +++
 drivers/gpu/drm/i915/intel_bios.h  |1 +
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |   61 
 3 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index c8acc29..0bf0942 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -714,6 +714,12 @@ static u8 *goto_next_sequence(u8 *data, int *size)
 
data += 3;
break;
+   case MIPI_SEQ_ELEM_I2C:
+   /* skip by this element payload size */
+   data += 7;
+   len = *data;
+   data += len + 1;
+   break;
default:
DRM_ERROR("Unknown element\n");
return NULL;
diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 1b7417e..21a7f3f 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -956,6 +956,7 @@ enum mipi_seq_element {
MIPI_SEQ_ELEM_SEND_PKT,
MIPI_SEQ_ELEM_DELAY,
MIPI_SEQ_ELEM_GPIO,
+   MIPI_SEQ_ELEM_I2C,
MIPI_SEQ_ELEM_STATUS,
MIPI_SEQ_ELEM_MAX
 };
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a5e99ac..9989f61 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "i915_drv.h"
@@ -104,6 +105,65 @@ static struct gpio_table gtable[] = {
{ GPIO_NC_11_PCONF0, GPIO_NC_11_PAD, 0}
 };
 
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
+{
+   struct i2c_adapter *adapter;
+   int ret;
+   u8 reg_offset, payload_size, retries = 5;
+   struct i2c_msg msg;
+   u8 *transmit_buffer = NULL;
+   u8 flag = *data++;
+   u8 index = *data++;
+   u8 bus_number = *data++;
+   u16 slave_add = *(u16 *)(data);
+
+   data = data + 2;
+   reg_offset = *data++;
+   payload_size = *data++;
+
+   adapter = i2c_get_adapter(bus_number);
+
+   if (!adapter) {
+   DRM_ERROR("i2c_get_adapter(%u) failed, index:%u flag: %u\n",
+   (bus_number + 1), index, flag);
+   goto out;
+   }
+
+   transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
+
+   if (!transmit_buffer)
+   goto out;
+
+   transmit_buffer[0] = reg_offset;
+   memcpy(_buffer[1], data, (size_t)payload_size);
+
+   msg.addr   = slave_add;
+   msg.flags  = 0;
+   msg.len= payload_size + 1;
+   msg.buf= _buffer[0];
+
+   do {
+   ret =  i2c_transfer(adapter, , 1);
+   if (ret == 1)
+   break;
+   else if (ret == -EAGAIN)
+   usleep_range(1000, 2500);
+   else {
+   DRM_ERROR("i2c transfer failed, error code:%d", ret);
+   break;
+   }
+   } while (retries--);
+
+   if (retries == 0)
+   DRM_ERROR("i2c transfer failed, error code:%d", ret);
+out:
+   kfree(transmit_buffer);
+   i2c_put_adapter(adapter);
+
+   data = data + payload_size;
+   return data;
+}
+
 static inline enum port intel_dsi_seq_port_to_port(u8 port)
 {
return port ? PORT_C : PORT_A;
@@ -236,6 +296,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
mipi_exec_send_packet,
mipi_exec_delay,
mipi_exec_gpio,
+   mipi_exec_i2c,
NULL, /* status read; later */
 };
 
-- 
1.7.9.5

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

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 04/11] drm/i915: Using the approprite vbt size if vbt is not in mailbox4 of opregion

[Deepak M]

Currently the field in bdb header which indicates the VBT size
is of 2 bytes, but there are some cases where VBT size exceeds
64KB in which case this field may not contain the correct VBT size.
So its better to get the VBT size from the mailbox3 if
VBT is not present in the mailbox4 of opregion.

v2: - Use opregion filed from dev_priv struct instead of creating
  a new field in dev_priv (Jani)
- Have vbt_size field vaild in all scenarios (Jani)
- rebase

Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_drv.h   |2 ++
 drivers/gpu/drm/i915/intel_bios.c |   42 +++--
 drivers/gpu/drm/i915/intel_opregion.c |6 +
 3 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 507d57a..91ccbc6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1777,6 +1777,8 @@ struct drm_i915_private {
u32 pm_rps_events;
u32 pipestat_irq_mask[I915_MAX_PIPES];
 
+   u32 vbt_size;
+
struct i915_hotplug hotplug;
struct i915_fbc fbc;
struct i915_drrs drrs;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 1932a86..34a1042 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -37,17 +37,19 @@
 static int panel_type;
 
 static const void *
-find_section(const void *_bdb, int section_id)
+find_section(struct drm_i915_private *dev_priv,
+   const void *_bdb, int section_id)
 {
const struct bdb_header *bdb = _bdb;
const u8 *base = _bdb;
int index = 0;
-   u16 total, current_size;
+   u32 total, current_size;
u8 current_id;
 
/* skip to first section */
index += bdb->header_size;
-   total = bdb->bdb_size;
+
+   total = dev_priv->vbt_size;
 
/* walk the sections looking for section_id */
while (index + 3 < total) {
@@ -179,7 +181,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
struct drm_display_mode *panel_fixed_mode;
int drrs_mode;
 
-   lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
+   lvds_options = find_section(dev_priv, bdb, BDB_LVDS_OPTIONS);
if (!lvds_options)
return;
 
@@ -211,11 +213,12 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
break;
}
 
-   lvds_lfp_data = find_section(bdb, BDB_LVDS_LFP_DATA);
+   lvds_lfp_data = find_section(dev_priv, bdb, BDB_LVDS_LFP_DATA);
if (!lvds_lfp_data)
return;
 
-   lvds_lfp_data_ptrs = find_section(bdb, BDB_LVDS_LFP_DATA_PTRS);
+   lvds_lfp_data_ptrs = find_section(dev_priv, bdb,
+   BDB_LVDS_LFP_DATA_PTRS);
if (!lvds_lfp_data_ptrs)
return;
 
@@ -257,7 +260,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
const struct bdb_lfp_backlight_data *backlight_data;
const struct bdb_lfp_backlight_data_entry *entry;
 
-   backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
+   backlight_data = find_section(dev_priv, bdb, BDB_LVDS_BACKLIGHT);
if (!backlight_data)
return;
 
@@ -305,14 +308,15 @@ parse_sdvo_panel_data(struct drm_i915_private *dev_priv,
if (index == -1) {
const struct bdb_sdvo_lvds_options *sdvo_lvds_options;
 
-   sdvo_lvds_options = find_section(bdb, BDB_SDVO_LVDS_OPTIONS);
+   sdvo_lvds_options = find_section(dev_priv, bdb,
+   BDB_SDVO_LVDS_OPTIONS);
if (!sdvo_lvds_options)
return;
 
index = sdvo_lvds_options->panel_type;
}
 
-   dvo_timing = find_section(bdb, BDB_SDVO_PANEL_DTDS);
+   dvo_timing = find_section(dev_priv, bdb, BDB_SDVO_PANEL_DTDS);
if (!dvo_timing)
return;
 
@@ -349,7 +353,7 @@ parse_general_features(struct drm_i915_private *dev_priv,
struct drm_device *dev = dev_priv->dev;
const struct bdb_general_features *general;
 
-   general = find_section(bdb, BDB_GENERAL_FEATURES);
+   general = find_section(dev_priv, bdb, BDB_GENERAL_FEATURES);
if (general) {
dev_priv->vbt.int_tv_support = general->int_tv_support;
dev_priv->vbt.int_crt_support = general->int_crt_support;
@@ -374,7 +378,7 @@ parse_general_definitions(struct drm_i915_private *dev_priv,
 {
const struct bdb_general_definitions *general;
 
-   general = find_section(bdb, BDB_GENERAL_DEFINITIONS);
+   general = find_section(dev_priv, bdb, BDB_GENERAL_DEFINITIONS);
if (general) {
u16 block_size = get_blocksize(general);
if (block_size >= sizeof(*general)) {
@@ -405,7 +409,7 @@ parse_sdvo_device_mapping(struct drm_i915_private *dev_priv,
int i, 

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 02/11] drm/i915: Updating asle structure with new fields

[Deepak M]

Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_opregion.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index cb1c657..f46231f 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -120,7 +120,9 @@ struct opregion_asle {
u64 fdss;
u32 fdsp;
u32 stat;
-   u8 rsvd[70];
+   u64 rvda;   /* Physical address of raw vbt data */
+   u32 rvds;   /* Size of raw vbt data */
+   u8 rsvd[58];
 } __packed;
 
 /* Driver readiness indicator */
-- 
1.7.9.5

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

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 05/11] drm/i915: Added support the v3 mipi sequence block

[Deepak M]

From: vkorjani 

The Block 53 of the VBT, which is the MIPI sequence block
has undergone a design change because of which the parsing
logic has to be changed.

The current code will handle the parsing of v3 and other
lower versions of the MIPI sequence block.

v2: rebase

Signed-off-by: vkorjani 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_bios.c  |  119 +++-
 drivers/gpu/drm/i915/intel_bios.h  |8 ++
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |7 ++
 3 files changed, 114 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 34a1042..cea641f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -45,6 +45,7 @@ find_section(struct drm_i915_private *dev_priv,
int index = 0;
u32 total, current_size;
u8 current_id;
+   u8 version;
 
/* skip to first section */
index += bdb->header_size;
@@ -56,7 +57,17 @@ find_section(struct drm_i915_private *dev_priv,
current_id = *(base + index);
index++;
 
-   current_size = *((const u16 *)(base + index));
+   if (current_id == BDB_MIPI_SEQUENCE) {
+   version = *(base + index + 2);
+   if (version >= 3)
+   current_size = *((const u32 *)(base +
+   index + 3));
+   else
+   current_size = *((const u16 *)(base + index));
+   } else {
+   current_size = *((const u16 *)(base + index));
+   }
+
index += 2;
 
if (index + current_size > total)
@@ -745,6 +756,55 @@ static u8 *goto_next_sequence(u8 *data, int *size)
return data;
 }
 
+static u8 *goto_next_sequence_v3(u8 *data, int *size)
+{
+   int tmp = *size;
+   int op_size;
+
+   if (--tmp < 0)
+   return NULL;
+
+   /* Skip the panel id and the sequence size */
+   data = data + 5;
+   while (*data != 0) {
+   u8 element_type = *data++;
+
+   switch (element_type) {
+   default:
+   DRM_ERROR("Unknown element type %d\n", element_type);
+   case MIPI_SEQ_ELEM_SEND_PKT:
+   case MIPI_SEQ_ELEM_DELAY:
+   case MIPI_SEQ_ELEM_GPIO:
+   case MIPI_SEQ_ELEM_I2C:
+   case MIPI_SEQ_ELEM_SPI:
+   case MIPI_SEQ_ELEM_PMIC:
+   /*
+* skip by this element payload size
+* skip elem id, command flag and data type
+*/
+   op_size = *data++;
+   tmp = tmp - (op_size + 1);
+   if (tmp < 0)
+   return NULL;
+
+   /* skip by len */
+   data += op_size;
+   break;
+   }
+   }
+
+   /* goto next sequence or end of block byte */
+   if (--tmp < 0)
+   return NULL;
+
+   /* Skip the end element marker */
+   data++;
+
+   /* update amount of data left for the sequence block to be parsed */
+   *size = tmp;
+   return data;
+}
+
 static void
 parse_mipi(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
 {
@@ -754,7 +814,7 @@ parse_mipi(struct drm_i915_private *dev_priv, const struct 
bdb_header *bdb)
const struct mipi_pps_data *pps;
u8 *data;
const u8 *seq_data;
-   int i, panel_id, seq_size;
+   int i, panel_id, panel_seq_size;
u16 block_size;
 
/* parse MIPI blocks only if LFP type is MIPI */
@@ -811,29 +871,40 @@ parse_mipi(struct drm_i915_private *dev_priv, const 
struct bdb_header *bdb)
 
DRM_DEBUG_DRIVER("Found MIPI sequence block\n");
 
-   block_size = get_blocksize(sequence);
-
/*
 * parse the sequence block for individual sequences
 */
dev_priv->vbt.dsi.seq_version = sequence->version;
 
seq_data = >data[0];
+   if (dev_priv->vbt.dsi.seq_version >= 3) {
+   block_size = *((unsigned int *)seq_data);
+   seq_data = seq_data + 4;
+   } else
+   block_size = get_blocksize(sequence);
 
/*
 * sequence block is variable length and hence we need to parse and
 * get the sequence data for specific panel id
 */
for (i = 0; i < MAX_MIPI_CONFIGURATIONS; i++) {
-   panel_id = *seq_data;
-   seq_size = *((u16 *) (seq_data + 1));
+   panel_id = *seq_data++;
+   if (dev_priv->vbt.dsi.seq_version >= 3) {
+   panel_seq_size = *((u32 *)seq_data);
+ 

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 00/11] Patches to support the version 3 of MIPI sequence in VBT.

[Deepak M]

Currently in our kernel we ioremap 8KB of memory for the
opregion and holds a maximum of 6KB sized RAW vbt data.

As per the latest opregion spec when the VBT size exceeds
6KB it cant be placed in the mailbox4 of the opregion, so
the physical address of the buffer where the Raw VBT is
stored will be mentioned in the mailbox3 with the VBT size
in the opregion version 2 and above.
A non-zero value here is an indication to driver that a
valid Raw VBT is stored here and driver should not refer
to mailbox4 for getting VBT. This is implemented in one
of the patches in this series.

link for the opregion spec : 
https://securewiki.ith.intel.com/pages/viewpage.action?pageId=48147378
(spec is under intel firewall)

In the version 3 of the MIPI sequence block, the size
field is 4 bytes so that it can support block size of
more than 64KB, but the vbt size field in the bdb header is only
2 bytes. Based on the below points this issue can be handled.
1. When the VBT is not present in the mailbox4 then VBT size
needs to be read from the mailbox3 and this VBT size field
is of 4 bytes which implies that it can be more than 64KB also.
2. If the VBT size is more than 64KB then the VBT size field
in the bdb header cant be relied. So its better to consider
the vbt size from the mailbox3 when the VBT is not present in
mailbox4.

Other patches implements the parsing of the new sequence type
which are added in the block 53.

v2: Addressed Jani`s review comments.

Deepak M (6):
  drm/i915: Updating asle structure with new fields
  drm/i915: Parsing VBT if size of VBT exceeds 6KB
  drm/i915: Using the approprite vbt size if vbt is not in mailbox4 of
opregion
  drm/i915: extending gpio read/write to other cores
  drm/i915: Added the generic gpio sequence support and gpio table
  drm: Add few more wrapper functions for drm panel

Gaurav K Singh (1):
  drm/i915: Add functions to execute the new sequences from VBT

Uma Shankar (1):
  drm/i915: BXT GPIO support for backlight and panel control

Yogesh Mohan Marimuthu (1):
  drm/i915: GPIO for CHT generic MIPI

vkorjani (2):
  drm/i915: Adding the parsing logic for the i2c element
  drm/i915: Added support the v3 mipi sequence block

 drivers/gpu/drm/i915/i915_debugfs.c|   24 +-
 drivers/gpu/drm/i915/i915_drv.h|   11 +-
 drivers/gpu/drm/i915/i915_reg.h|   28 ++
 drivers/gpu/drm/i915/intel_bios.c  |  216 +++-
 drivers/gpu/drm/i915/intel_bios.h  |9 +
 drivers/gpu/drm/i915/intel_dsi.h   |  351 +++
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |  514 ++--
 drivers/gpu/drm/i915/intel_opregion.c  |  283 +--
 drivers/gpu/drm/i915/intel_opregion.h  |  230 +
 drivers/gpu/drm/i915/intel_sideband.c  |9 +-
 include/drm/drm_panel.h|   47 +++
 11 files changed, 1400 insertions(+), 322 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_opregion.h

-- 
1.7.9.5

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

[Intel-gfx] [MIPI SEQ PARSING v2 PATCH 03/11] drm/i915: Parsing VBT if size of VBT exceeds 6KB

[Deepak M]

Currently the iomap for VBT works only if the size of the
VBT is less than 6KB, but if the size of the VBT exceeds
6KB than the physical address and the size of the VBT to
be iomapped is specified in the mailbox3 and is iomapped
accordingly.

v2: - Moving the validate_vbt to opregion file (Jani)
- Fix the i915_opregion() in debugfs (Jani)

Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |   24 ++-
 drivers/gpu/drm/i915/i915_drv.h   |4 +
 drivers/gpu/drm/i915/intel_bios.c |   49 +-
 drivers/gpu/drm/i915/intel_opregion.c |  279 +
 drivers/gpu/drm/i915/intel_opregion.h |  230 +++
 5 files changed, 329 insertions(+), 257 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_opregion.h

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 41629fa..5534aa2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,6 +26,8 @@
  *
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +41,7 @@
 #include "intel_ringbuffer.h"
 #include 
 #include "i915_drv.h"
+#include "intel_opregion.h"
 
 enum {
ACTIVE_LIST,
@@ -1832,7 +1835,7 @@ static int i915_opregion(struct seq_file *m, void *unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_opregion *opregion = _priv->opregion;
-   void *data = kmalloc(OPREGION_SIZE, GFP_KERNEL);
+   void *data = kmalloc(OPREGION_VBT_OFFSET, GFP_KERNEL);
int ret;
 
if (data == NULL)
@@ -1843,12 +1846,25 @@ static int i915_opregion(struct seq_file *m, void 
*unused)
goto out;
 
if (opregion->header) {
-   memcpy_fromio(data, opregion->header, OPREGION_SIZE);
-   seq_write(m, data, OPREGION_SIZE);
+   memcpy_fromio(data, opregion->header, OPREGION_VBT_OFFSET);
+   seq_write(m, data, OPREGION_VBT_OFFSET);
+   kfree(data);
+   if (opregion->asle->rvda) {
+   data = kmalloc(opregion->asle->rvds, GFP_KERNEL);
+   memcpy_fromio(data,
+   (const void __iomem *) opregion->asle->rvda,
+   opregion->asle->rvds);
+   seq_write(m, data, opregion->asle->rvds);
+   } else {
+   data = kmalloc(OPREGION_SIZE - OPREGION_VBT_OFFSET,
+   GFP_KERNEL);
+   memcpy_fromio(data, opregion->vbt,
+   OPREGION_SIZE - OPREGION_VBT_OFFSET);
+   seq_write(m, data, OPREGION_SIZE - OPREGION_VBT_OFFSET);
+   }
}
 
mutex_unlock(>struct_mutex);
-
 out:
kfree(data);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1287007..507d57a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1780,6 +1780,7 @@ struct drm_i915_private {
struct i915_hotplug hotplug;
struct i915_fbc fbc;
struct i915_drrs drrs;
+   const struct bdb_header *bdb_start;
struct intel_opregion opregion;
struct intel_vbt_data vbt;
 
@@ -3306,6 +3307,9 @@ intel_opregion_notify_adapter(struct drm_device *dev, 
pci_power_t state)
 }
 #endif
 
+const struct bdb_header *validate_vbt(const void __iomem *_vbt,
+   size_t size, const char *source);
+
 /* intel_acpi.c */
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 0bf0942..1932a86 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1227,49 +1227,6 @@ static const struct dmi_system_id 
intel_no_opregion_vbt[] = {
{ }
 };
 
-static const struct bdb_header *validate_vbt(const void __iomem *_base,
-size_t size,
-const void __iomem *_vbt,
-const char *source)
-{
-   /*
-* This is the one place where we explicitly discard the address space
-* (__iomem) of the BIOS/VBT. (And this will cause a sparse complaint.)
-* From now on everything is based on 'base', and treated as regular
-* memory.
-*/
-   const void *base = (const void *) _base;
-   size_t offset = _vbt - _base;
-   const struct vbt_header *vbt = base + offset;
-   const struct bdb_header *bdb;
-
-   if (offset + sizeof(struct vbt_header) > size) {
-   DRM_DEBUG_DRIVER("VBT header incomplete\n");
-   return NULL;
-   }
-
-   if (memcmp(vbt->signature, "$VBT", 4)) {
-   DRM_DEBUG_DRIVER("VBT invalid 

[Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 wa - NV12 to RGB switch

[Chandra Konduru]

Switching format from NV12 to RGB can result in display underrun
and corruption. This workaround sets bits 15 & 19 to 1 in
CLKGATE_DIS_PSL register to address transition underrun.

v2:
-Move workaround to init clock gating (Ville)

Signed-off-by: Chandra Konduru 
---
 drivers/gpu/drm/i915/i915_reg.h |8 
 drivers/gpu/drm/i915/intel_pm.c |8 
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d20f235..2e2636d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5366,6 +5366,14 @@ enum skl_disp_power_wells {
 #define CHICKEN_DCPR_1 0x46430
 #define IDLE_WAKEMEM_MASK  (1 << 13)
 
+#define CLKGATE_DIS_PSL_A0x46520
+#define CLKGATE_DIS_PSL_B0x46524
+#define CLKGATE_DIS_PSL_C0x46528
+#define DUPS1_GATING_DIS (1 << 15)
+#define DUPS2_GATING_DIS (1 << 19)
+#define DUPS3_GATING_DIS (1 << 23)
+#define CLKGATE_DIS_PSL(pipe)  _PIPE(pipe, CLKGATE_DIS_PSL_A, 
CLKGATE_DIS_PSL_B)
+
 /* SKL new cursor registers */
 #define _CUR_BUF_CFG_A 0x7017c
 #define _CUR_BUF_CFG_B 0x7117c
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8a36ab9..9a3deed 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -63,6 +63,14 @@ static void gen9_init_clock_gating(struct drm_device *dev)
/* WaDisableKillLogic:bxt,skl */
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
   ECOCHK_DIS_TLB);
+
+   /*
+* Switching format from NV12 to RGB can result in display underrun
+* and corruption. This workaround sets bits 15 & 19 to 1 in
+* CLKGATE_DIS_PSL register to address transition underrun.
+*/
+   I915_WRITE(CLKGATE_DIS_PSL(PIPE_A), DUPS1_GATING_DIS | 
DUPS2_GATING_DIS);
+   I915_WRITE(CLKGATE_DIS_PSL(PIPE_B), DUPS1_GATING_DIS | 
DUPS2_GATING_DIS);
 }
 
 static void skl_init_clock_gating(struct drm_device *dev)
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Add NV12 to primary plane programming.

[Konduru, Chandra]

> Looking at what was said, I think we covered most open items
> reasonably well, so fire away. I'll start going through the
> updated patches tomorrow.
> 
Updates patches:
http://lists.freedesktop.org/archives/intel-gfx/2015-September/075235.html

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

Re: [Intel-gfx] [PATCH 5/6] drm/i915: drm/i915: Process hpd only for hdmi inside hotplug_work_func

[Jindal, Sonika]

Since, the port is enumerated as DP as well as hdmi, the init connector is 
called for both and the same intel encoder gets attached to both the connectors.
Now the intel_encoder’s type could be a differentiator. But since, hdmi’s 
detect gets called, the type of the encoder remains hdmi.
When hpd occurs, it checks from the list of connectors whose hpd pin is same as 
the one asserted.
Since both dp and hdmi are INITed, both the connectors have that pin and since 
DP’s connector is first in the list, it calls the ->hot_plug once when it finds 
DP connector matching and then again when HDMI connector is found matching as 
per the pin.

This code check will avoid calling in the case when we have found the DP 
connector because we are sure that there is no ->hot_plug hook for DP.
Anyways, that was not a generic implementation.

Regards,
Sonika

From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
Sent: Thursday, September 10, 2015 12:51 AM
To: Jindal, Sonika; Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: drm/i915: Process hpd only for 
hdmi inside hotplug_work_func

I was also going to say that I believe this breaks DP hotplug, but this was 
agreed already...

But I also don't understand how hot_plug is called twice since it calls 
encoder->hot_plug...
and dp has no ->hot_plug...
And also if this is happening how this code that checks for connector would 
help... there is something else strange happening...



On Sat, Sep 5, 2015 at 9:31 PM Jindal, Sonika 
> wrote:


On 9/4/2015 8:17 PM, Daniel Vetter wrote:
> On Fri, Sep 04, 2015 at 06:56:15PM +0530, Sonika Jindal wrote:
>> If the same port is enumerated as hdmi as well as DP, this will get
>> called for DP connector as well which is not required because
>> i915_hotplug_work_func is solely to handle hdmi HPD.
>>
>> Signed-off-by: Sonika Jindal 
>> >
>> ---
>>   drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
>> b/drivers/gpu/drm/i915/intel_hotplug.c
>> index 53c0173..8e1c43e 100644
>> --- a/drivers/gpu/drm/i915/intel_hotplug.c
>> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
>> @@ -325,7 +325,8 @@ static void i915_hotplug_work_func(struct work_struct 
>> *work)
>>
>>  list_for_each_entry(connector, _config->connector_list, head) {
>>  intel_connector = to_intel_connector(connector);
>> -if (!intel_connector->encoder)
>> +if (!intel_connector->encoder
>> +&& connector->connector_type != 
>> DRM_MODE_CONNECTOR_HDMIA)
>>  continue;
>
> Pretty sure this breaks hotplug detection for everything but HDMI (since
> now nothing but hdmi gets called it's ->detect function, and only if that
> signals a status change will we send out an uevent to userspace). Does
> this really not break DP hotplug?
>
> Yes we probe both hdmi and DP always, and probably we could be more
> intelligent with the fallback between the too. But this here doesn't seem
> to be the right solution.
> -Daniel

Hmm :(
This doesn't allow detect to be called for dp. I missed the part that
hpd_pulse only handles mst. From the name and comments it looks like it
should handle hpd for dp completely. I think this this code needs some
refactoring.

For now, I think I better move this check to intel_encoder->hot_plug
function because for the connectors with dp and hdmi both, this hot_plug
hook gets called twice.

>
>>  intel_encoder = intel_connector->encoder;
>>  if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
>> --
>> 1.7.10.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] drm/atomic/helper: Allow duplication of in-flight states

[Matt Roper]

Drivers may wish to duplicate in-flight states internally, but the
__drm_atomic_helper_{crtc,plane}_duplicate_state helper functions can
only be used to make a copy of state that has already been committed to
obj->state.  Let's update the helpers to take any existing state object
as their first parameter rather than the DRM object pointer.  We can
update handful of existing callsites to just pass obj->state for it.

Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_atomic_helper.c   | 12 ++--
 drivers/gpu/drm/i915/intel_atomic.c   |  2 +-
 drivers/gpu/drm/i915/intel_atomic_plane.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  2 +-
 drivers/gpu/drm/tegra/dc.c|  4 ++--
 include/drm/drm_atomic_helper.h   |  4 ++--
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9941167..915b462 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2149,10 +2149,10 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_reset);
  * Copies atomic state from a CRTC's current state and resets inferred values.
  * This is useful for drivers that subclass the CRTC state.
  */
-void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
+void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc_state *from,
  struct drm_crtc_state *state)
 {
-   memcpy(state, crtc->state, sizeof(*state));
+   memcpy(state, from, sizeof(*state));
 
if (state->mode_blob)
drm_property_reference_blob(state->mode_blob);
@@ -2181,7 +2181,7 @@ drm_atomic_helper_crtc_duplicate_state(struct drm_crtc 
*crtc)
 
state = kmalloc(sizeof(*state), GFP_KERNEL);
if (state)
-   __drm_atomic_helper_crtc_duplicate_state(crtc, state);
+   __drm_atomic_helper_crtc_duplicate_state(crtc->state, state);
 
return state;
 }
@@ -2248,10 +2248,10 @@ EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
  * Copies atomic state from a plane's current state. This is useful for
  * drivers that subclass the plane state.
  */
-void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
+void __drm_atomic_helper_plane_duplicate_state(struct drm_plane_state *from,
   struct drm_plane_state *state)
 {
-   memcpy(state, plane->state, sizeof(*state));
+   memcpy(state, from, sizeof(*state));
 
if (state->fb)
drm_framebuffer_reference(state->fb);
@@ -2275,7 +2275,7 @@ drm_atomic_helper_plane_duplicate_state(struct drm_plane 
*plane)
 
state = kmalloc(sizeof(*state), GFP_KERNEL);
if (state)
-   __drm_atomic_helper_plane_duplicate_state(plane, state);
+   __drm_atomic_helper_plane_duplicate_state(plane->state, state);
 
return state;
 }
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 3ffc385..45b21ac 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -97,7 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
if (!crtc_state)
return NULL;
 
-   __drm_atomic_helper_crtc_duplicate_state(crtc, _state->base);
+   __drm_atomic_helper_crtc_duplicate_state(crtc->state, 
_state->base);
 
crtc_state->base.crtc = crtc;
 
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index f1ab8e4..afbbfe0 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -87,7 +87,7 @@ intel_plane_duplicate_state(struct drm_plane *plane)
 
state = _state->base;
 
-   __drm_atomic_helper_plane_duplicate_state(plane, state);
+   __drm_atomic_helper_plane_duplicate_state(plane->state, state);
 
return state;
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 09e363b..8962e6b 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -258,7 +258,7 @@ omap_plane_atomic_duplicate_state(struct drm_plane *plane)
if (copy == NULL)
return NULL;
 
-   __drm_atomic_helper_plane_duplicate_state(plane, >base);
+   __drm_atomic_helper_plane_duplicate_state(plane->state, >base);
 
return >base;
 }
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index c669864..e050f54 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -310,7 +310,7 @@ rcar_du_plane_atomic_duplicate_state(struct drm_plane 
*plane)
if (copy == NULL)
return NULL;
 
-   __drm_atomic_helper_plane_duplicate_state(plane, >state);
+   

[Intel-gfx] [PATCH 3/4] drm/i915: Calculate an intermediate atomic state for modesets (v2)

[Matt Roper]

To simplify the modeset process for atomic, start calculating an
"intermediate" state.  This state only modifies CRTC's that undergo a
modeset (or disable)...in that case it will be a copy of the final state
with ->active set to false (which will in turn cause various derived
state to be calculated differently).  This state represents the status
of the CRTC and planes at the point in which the CRTC's have been
disabled even if the CRTC will be running again once the full modeset is
complete.  This will allow us to calculate proper derived state fields
for this point in the modeset process which should in turn should help
us properly perform tasks like watermark calculation with less special
cases.

For review simplicity, this patch simply allocates and calculates the
intermediate state, but doesn't actually do anything with it yet.
The next patch will start actually using this intermediate state data.

v2:
 - Use a whole new top-level state object rather than just sticking
   extra plane state and crtc state arrays in the existing
   intel_atomic_state object.  (Ville)

Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_atomic.c   | 142 +-
 drivers/gpu/drm/i915/intel_atomic_plane.c |  36 +---
 drivers/gpu/drm/i915/intel_display.c  |   3 +-
 drivers/gpu/drm/i915/intel_drv.h  |  14 +++
 4 files changed, 160 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 45b21ac..0487073 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -74,32 +74,23 @@ intel_connector_atomic_get_property(struct drm_connector 
*connector,
 }
 
 /*
- * intel_crtc_duplicate_state - duplicate crtc state
- * @crtc: drm crtc
- *
- * Allocates and returns a copy of the crtc state (both common and
- * Intel-specific) for the specified crtc.
- *
- * Returns: The newly allocated crtc state, or NULL on failure.
+ * Duplicate any CRTC state (not just an already committed state).
  */
-struct drm_crtc_state *
-intel_crtc_duplicate_state(struct drm_crtc *crtc)
+static struct drm_crtc_state *
+__intel_crtc_duplicate_state(struct drm_crtc_state *cs)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *crtc_state;
 
-   if (WARN_ON(!intel_crtc->config))
+   if (WARN_ON(!cs))
crtc_state = kzalloc(sizeof(*crtc_state), GFP_KERNEL);
else
-   crtc_state = kmemdup(intel_crtc->config,
-sizeof(*intel_crtc->config), GFP_KERNEL);
-
+   crtc_state = kmemdup(cs, sizeof(*crtc_state), GFP_KERNEL);
if (!crtc_state)
return NULL;
 
-   __drm_atomic_helper_crtc_duplicate_state(crtc->state, 
_state->base);
+   __drm_atomic_helper_crtc_duplicate_state(cs, _state->base);
 
-   crtc_state->base.crtc = crtc;
+   crtc_state->base.crtc = cs->crtc;
 
crtc_state->wait_for_flips = false;
crtc_state->disable_fbc = false;
@@ -118,6 +109,21 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
return _state->base;
 }
 
+/*
+ * intel_crtc_duplicate_state - duplicate crtc state
+ * @crtc: drm crtc
+ *
+ * Allocates and returns a copy of the crtc state (both common and
+ * Intel-specific) for the specified crtc.
+ *
+ * Returns: The newly allocated crtc state, or NULL on failure.
+ */
+struct drm_crtc_state *
+intel_crtc_duplicate_state(struct drm_crtc *crtc)
+{
+   return __intel_crtc_duplicate_state(crtc->state);
+}
+
 /**
  * intel_crtc_destroy_state - destroy crtc state
  * @crtc: drm crtc
@@ -315,17 +321,113 @@ intel_atomic_state_alloc(struct drm_device *dev)
 {
struct intel_atomic_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (!state || drm_atomic_state_init(dev, >base) < 0) {
-   kfree(state);
-   return NULL;
-   }
+   if (!state || drm_atomic_state_init(dev, >base) < 0)
+   goto fail;
+
+   /* Also allocate an intermediate state */
+   state->intermediate = kzalloc(sizeof(*state->intermediate), GFP_KERNEL);
+   if (!state->intermediate ||
+   drm_atomic_state_init(dev, state->intermediate) < 0)
+   goto fail;
 
+   state->intermediate->acquire_ctx = state->base.acquire_ctx;
return >base;
+
+fail:
+   if (state)
+   kfree(state->intermediate);
+   drm_atomic_state_default_release(>base);
+   kfree(state);
+   return NULL;
+}
+
+void
+intel_atomic_state_free(struct drm_atomic_state *s)
+{
+   struct intel_atomic_state *state = to_intel_atomic_state(s);
+
+   if (WARN_ON(!s))
+   return;
+
+   drm_atomic_state_default_release(state->intermediate);
+   drm_atomic_state_default_release(s);
 }
 
 void intel_atomic_state_clear(struct drm_atomic_state *s)
 {

[Intel-gfx] [PATCH 4/4] drm/i915: Update modeset programming to use intermediate state (v2)

[Matt Roper]

As suggested by Ville, the general flow should now roughly follow:

// whatever the user wanted
compute_final_atomic_state()

// include all crtcs in the intermediate state which are
// getting disabled (even temporarily to perform a modeset)
compute_intermediate_atomic_state()

ret = check_state_change(old, intermediate)
ret = check_state_change(intermediate, new)

// commit all planes in one go to make them pop out as
// atomically as possible
for_each_crtc_in(intermediate) {
commit_planes()
}

for_each_crtc_in(intermediate) {
disable_crtc()
}

for_each_crtc_in(new) {
if (!currently_active)
crtc_enable()
}

// commit all planes in one go to make them pop in as atomically
// as possible
for_each_crtc_in(new) {
commit_planes()
}

v2: Because we're potentially performing two state swaps here, the
actual set of FB's that need to be cleaned up at the end of the
process may need to be fetched from the intermediate state rather
than the final state, so use our own intel_cleanup_planes() rather
than the helper version.

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Signed-off-by: Matt Roper 
---
I know Maarten had some reservations about this approach, so hopefully
providing an implementation will allow us to continue the discussion and come
to an agreement on whether or not intermediate states are the way to go.

 drivers/gpu/drm/i915/intel_display.c | 104 +++
 1 file changed, 80 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5081a9e..d63ad1d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13027,6 +13027,36 @@ static int intel_atomic_check(struct drm_device *dev,
return intel_atomic_check_planes(state->dev, state);
 }
 
+/*
+ * An Intel-specific version of drm_atomic_helper_cleanup_planes().
+ * Since we've potentially swapped to an intermediate state before
+ * swapping again to the final state, the actual framebuffers that
+ * need to be cleaned up will have been swapped into the intermediate
+ * state object for any CRTC's that are undergoing a modeset, so we
+ * need to grab them from there instead of the old_state object.
+ */
+static void
+intel_cleanup_planes(struct drm_device *dev,
+struct drm_atomic_state *old_state)
+{
+   struct drm_atomic_state *inter =
+   to_intel_atomic_state(old_state)->intermediate;
+   struct drm_plane *plane;
+   struct drm_plane_state *plane_state;
+   int i;
+
+   for_each_plane_in_state(old_state, plane, plane_state, i) {
+   const struct drm_plane_helper_funcs *funcs;
+
+   funcs = plane->helper_private;
+
+   plane_state = inter->plane_states[i] ?: plane_state;
+
+   if (funcs->cleanup_fb)
+   funcs->cleanup_fb(plane, plane_state);
+   }
+}
+
 /**
  * intel_atomic_commit - commit validated state object
  * @dev: DRM device
@@ -13048,11 +13078,12 @@ static int intel_atomic_commit(struct drm_device *dev,
   bool async)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_atomic_state *istate = to_intel_atomic_state(state);
+   struct drm_atomic_state *inter = istate->intermediate;
struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_state *old_crtc_state;
int ret = 0;
int i;
-   bool any_ms = false;
 
if (async) {
DRM_DEBUG_KMS("i915 does not yet support async commit\n");
@@ -13063,59 +13094,84 @@ static int intel_atomic_commit(struct drm_device *dev,
if (ret)
return ret;
 
-   drm_atomic_helper_swap_state(dev, state);
+   if (!istate->any_ms) {
+   /*
+* If there's no modeset involved, just move to the final state
+* and jump directly to the final plane updates.
+*/
+   drm_atomic_helper_swap_state(dev, state);
+   intel_modeset_update_crtc_state(state);
+   goto nomodeset;
+   }
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   /* Swap in intermediate state */
+   drm_atomic_helper_swap_state(dev, inter);
 
-   if (!needs_modeset(crtc->state))
-   continue;
+   /*
+* Commit all planes in one go to make them pop out as atomically
+* as possible.
+*/
+   for_each_crtc_in_state(inter, crtc, old_crtc_state, i) {

[Intel-gfx] [PATCH 1/4] drm/i915: Roll intel_crtc->atomic into intel_crtc_state

[Matt Roper]

Way back at the beginning of i915's atomic conversion I added
intel_crtc->atomic as a temporary dumping ground for "stuff to do
outside vblank evasion" flags since CRTC states weren't properly wired
up and tracked at that time.  We've had proper CRTC state tracking for a
while now, so there's really no reason for this hack to continue to
exist.  Moving forward we want to store intermediate crtc/plane state
data for modesets in addition to the final state, so moving these fields
into the proper state object allows us to properly compute them for both
the intermediate and final state.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_atomic.c  | 16 ++-
 drivers/gpu/drm/i915/intel_display.c | 83 ++--
 drivers/gpu/drm/i915/intel_drv.h | 42 +++---
 3 files changed, 73 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 9336e80..3ffc385 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -101,6 +101,20 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
 
crtc_state->base.crtc = crtc;
 
+   crtc_state->wait_for_flips = false;
+   crtc_state->disable_fbc = false;
+   crtc_state->disable_ips = false;
+   crtc_state->disable_cxsr = false;
+   crtc_state->pre_disable_primary = false;
+   crtc_state->update_wm_pre = false;
+   crtc_state->update_wm_post = false;
+   crtc_state->disabled_planes = 0;
+   crtc_state->fb_bits = 0;
+   crtc_state->wait_vblank = false;
+   crtc_state->update_fbc = false;
+   crtc_state->post_enable_primary = false;
+   crtc_state->update_sprite_watermarks = 0;
+
return _state->base;
 }
 
@@ -212,7 +226,7 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
 * minimum required validation.
 */
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
-   intel_crtc->atomic.wait_for_flips = 
true;
+   crtc_state->wait_for_flips = true;
crtc_state->base.planes_changed = true;
}
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index af48c1e..46931f9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4710,44 +4710,42 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
 
 static void intel_post_plane_update(struct intel_crtc *crtc)
 {
-   struct intel_crtc_atomic_commit *atomic = >atomic;
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_plane *plane;
 
-   if (atomic->wait_vblank)
+   if (cstate->wait_vblank)
intel_wait_for_vblank(dev, crtc->pipe);
 
-   intel_frontbuffer_flip(dev, atomic->fb_bits);
+   intel_frontbuffer_flip(dev, cstate->fb_bits);
 
-   if (atomic->disable_cxsr)
+   if (cstate->disable_cxsr)
crtc->wm.cxsr_allowed = true;
 
-   if (crtc->atomic.update_wm_post)
+   if (cstate->update_wm_post)
intel_update_watermarks(>base);
 
-   if (atomic->update_fbc)
+   if (cstate->update_fbc)
intel_fbc_update(dev_priv);
 
-   if (atomic->post_enable_primary)
+   if (cstate->post_enable_primary)
intel_post_enable_primary(>base);
 
-   drm_for_each_plane_mask(plane, dev, atomic->update_sprite_watermarks)
+   drm_for_each_plane_mask(plane, dev, cstate->update_sprite_watermarks)
intel_update_sprite_watermarks(plane, >base,
   0, 0, 0, false, false);
-
-   memset(atomic, 0, sizeof(*atomic));
 }
 
 static void intel_pre_plane_update(struct intel_crtc *crtc)
 {
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc_atomic_commit *atomic = >atomic;
struct drm_plane *p;
 
/* Track fb's for any planes being disabled */
-   drm_for_each_plane_mask(p, dev, atomic->disabled_planes) {
+   drm_for_each_plane_mask(p, dev, cstate->disabled_planes) {
struct intel_plane *plane = to_intel_plane(p);
 
mutex_lock(>struct_mutex);
@@ -4756,19 +4754,19 @@ static void intel_pre_plane_update(struct intel_crtc 
*crtc)
mutex_unlock(>struct_mutex);
}
 
-   if (atomic->wait_for_flips)
+   if (cstate->wait_for_flips)
intel_crtc_wait_for_pending_flips(>base);
 
-   if (atomic->disable_fbc)
+   if (cstate->disable_fbc)

[Intel-gfx] [PATCH 0/4] Intermediate state for modesets

[Matt Roper]

During review of the atomic watermark work, there was some discussion about how
to best handle modeset sequences where the CRTC's active state goes
enable->disable->enable.  One of the suggestions from Ville was to break the
modeset sequence into two atomic states by adding a new intermediate state that
represents the CRTC's being modeset at the point they (and their planes) have
been disabled.  This would hopefully allow us to eliminate some of the special
casing that exists in current modeset sequence (especially where we can't
always trust the state->active values).

I know there's been a bit of disagreement on IRC and mailing lists as to
whether this is the best direction to go or not, so I figured it might be
easier to discuss if I posted an actual implementation to look at.  I'll post
another iteration of the atomic watermark series tomorrow based on top of this
code to look at as well, in case that helps us make a decision.


Matt Roper (4):
  drm/i915: Roll intel_crtc->atomic into intel_crtc_state
  drm/atomic/helper: Allow duplication of in-flight states
  drm/i915: Calculate an intermediate atomic state for modesets (v2)
  drm/i915: Update modeset programming to use intermediate state (v2)

 drivers/gpu/drm/drm_atomic_helper.c   |  12 +-
 drivers/gpu/drm/i915/intel_atomic.c   | 158 +
 drivers/gpu/drm/i915/intel_atomic_plane.c |  36 +++---
 drivers/gpu/drm/i915/intel_display.c  | 190 +++---
 drivers/gpu/drm/i915/intel_drv.h  |  56 +
 drivers/gpu/drm/omapdrm/omap_plane.c  |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   2 +-
 drivers/gpu/drm/tegra/dc.c|   4 +-
 include/drm/drm_atomic_helper.h   |   4 +-
 9 files changed, 325 insertions(+), 139 deletions(-)

-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Call encoder hot_plug hook only for hdmi

[Jindal, Sonika]

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, September 9, 2015 8:48 PM
To: Jindal, Sonika
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Sharma, Shashank
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Call encoder hot_plug hook only for 
hdmi

On Tue, Sep 08, 2015 at 05:08:02PM +0530, Jindal, Sonika wrote:
> 
> 
> On 9/8/2015 10:12 AM, Jindal, Sonika wrote:
> >
> >
> >On 9/7/2015 9:56 PM, Daniel Vetter wrote:
> >>On Mon, Sep 07, 2015 at 10:34:34AM +0530, Sonika Jindal wrote:
> >>>If the same port is enumerated as hdmi as well as DP, this will 
> >>>call hot_plug hook for DP as well which is not required here.
> >>>This splitting of edid read and detect is done only for HDMI with 
> >>>this series.
> >>>
> >>>v2: Avoid breaking DP hpd. Also corrected the commit message and 
> >>>description accordingly. (Daniel)
> >>>
> >>>Signed-off-by: Sonika Jindal 
> >>>---
> >>>  drivers/gpu/drm/i915/intel_hotplug.c |3 ++-
> >>>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> >>>b/drivers/gpu/drm/i915/intel_hotplug.c
> >>>index 53c0173..ff4692a 100644
> >>>--- a/drivers/gpu/drm/i915/intel_hotplug.c
> >>>+++ b/drivers/gpu/drm/i915/intel_hotplug.c
> >>>@@ -331,7 +331,8 @@ static void i915_hotplug_work_func(struct 
> >>>work_struct *work)
> >>>  if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
> >>>  DRM_DEBUG_KMS("Connector %s (pin %i) received hotplug 
> >>>event.\n",
> >>>connector->name, intel_encoder->hpd_pin);
> >>>-if (intel_encoder->hot_plug)
> >>>+if (intel_encoder->hot_plug
> >>>+&& connector->connector_type ==
> >>>DRM_MODE_CONNECTOR_HDMIA)
> >>
> >>Please use something like grep to find all the other ->hot_plug 
> >>implementations and then please tell me why you don't break them all.
> >>-Daniel
> >>
> >Hmm, I only checked for hot_plug for DP/edp which is not there. 
> >Failed to notice that there is one in intel_sdvo.c.
> >My mistake. I will place it properly somewhere else.
> >
> >Regards,
> >Sonika
> 
> Is there any suggestion about how we can differentiate if it is actual 
> DP or HDMI hotplug at this point? intel_encoder's type gets updated 
> after detect call. So, not sure how to have this kind of check.
> 
> For now, I think we can abandon this patch from this series.

No, hpd is shared between hdmi and dp at the hw level so we can't 
differentiate. Long term my idea would be that we merge together all the hdmi 
_and_ dp hpd handling into one overall control-flow. Then we can make sure to 
not call anything twice and also have sensible high-level flow (like first 
checking for dp vs. hdmi and then taking relevant paths).

For dealing with ->hot_plug a quick fix might be to have a separate loop going 
over encoders (to make sure we only call it once per encoder if there's more 
than one connector for 1 encoder). That behaviour would also be ok for sdvo.

 Hmm, so instead of relying on connector, we can check for the hpd_pin 
on encoder and remove the connector loop completely?

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Update modeset programming to use intermediate state (v2)

[Maarten Lankhorst]

Op 10-09-15 om 03:57 schreef Matt Roper:
> As suggested by Ville, the general flow should now roughly follow:
>
> // whatever the user wanted
> compute_final_atomic_state()
>
> // include all crtcs in the intermediate state which are
> // getting disabled (even temporarily to perform a modeset)
> compute_intermediate_atomic_state()
>
> ret = check_state_change(old, intermediate)
> ret = check_state_change(intermediate, new)
>
> // commit all planes in one go to make them pop out as
> // atomically as possible
> for_each_crtc_in(intermediate) {
> commit_planes()
> }
>
> for_each_crtc_in(intermediate) {
> disable_crtc()
> }
>
> for_each_crtc_in(new) {
> if (!currently_active)
> crtc_enable()
> }
>
> // commit all planes in one go to make them pop in as atomically
> // as possible
> for_each_crtc_in(new) {
> commit_planes()
> }
>
> v2: Because we're potentially performing two state swaps here, the
> actual set of FB's that need to be cleaned up at the end of the
> process may need to be fetched from the intermediate state rather
> than the final state, so use our own intel_cleanup_planes() rather
> than the helper version.
>
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Signed-off-by: Matt Roper 
> ---
> I know Maarten had some reservations about this approach, so hopefully
> providing an implementation will allow us to continue the discussion and come
> to an agreement on whether or not intermediate states are the way to go.
I still don't like it. Intermediate wm's should be calculated in the check 
function, if it
can potentially fail.

The final state should be swapped in right away, not any intermediate state or 
async
modesets will never work.

And nothing should depend on the current state in the crtc_disable callbacks, 
if it
does it's a bug or it needs to get passed the old crtc_state so it knows what 
to disable.
This is probably why crtc->config is not dead yet.

Not committing DPLL state right after swap_state is a special case right now, 
but
that's easily fixed by changing pll->active from a refcount to a crtc mask.

~Maarten

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

[Intel-gfx] [PATCH i-g-t v3 1/2] tests: Add blob-property test

[Daniel Stone]

Exercises the new blob-creation ioctl, testing lifetimes and behaviour
of user-created blobs, as well as exercising all the invariant
conditions we guarantee from modes exposed as blob properties.

v2: Renamed to core_prop_blob, skip test if blob not available.
v3: No changes.

Signed-off-by: Daniel Stone 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/core_prop_blob.c | 237 +
 3 files changed, 239 insertions(+)
 create mode 100644 tests/core_prop_blob.c

diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53..beda511 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -3,6 +3,7 @@ core_get_client_auth
 core_getclient
 core_getstats
 core_getversion
+core_prop_blob
 drm_auth
 drm_import_export
 drm_read
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2e2e088..0f0e481 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -76,6 +76,7 @@ TESTS_progs_M = \
kms_pipe_b_c_ivb \
kms_pipe_crc_basic \
kms_plane \
+   kms_prop_blob \
kms_psr_sink_crc \
kms_render \
kms_rotation_crc \
diff --git a/tests/core_prop_blob.c b/tests/core_prop_blob.c
new file mode 100644
index 000..1250c00
--- /dev/null
+++ b/tests/core_prop_blob.c
@@ -0,0 +1,237 @@
+/*
+ * Copyright © 2014-2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *   Damien Lespiau 
+ *   Daniel Stone 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION("Tests behaviour of mass-data 'blob' properties.");
+
+static const struct drm_mode_modeinfo test_mode_valid = {
+   .clock = 1234,
+   .hdisplay = 640,
+   .hsync_start = 641,
+   .hsync_end = 642,
+   .htotal = 643,
+   .hskew = 0,
+   .vdisplay = 480,
+   .vsync_start = 481,
+   .vsync_end = 482,
+   .vtotal = 483,
+   .vscan = 0,
+   .vrefresh = 6,
+   .flags = 0,
+   .type = 0,
+   .name = "FROMUSER",
+};
+
+
+static int
+validate_prop(int fd, uint32_t prop_id)
+{
+   struct drm_mode_get_blob get;
+   struct drm_mode_modeinfo ret_mode;
+   int err;
+
+   get.blob_id = prop_id;
+   get.length = 0;
+   get.data = (uintptr_t) 0;
+
+   err = drmIoctl(fd, DRM_IOCTL_MODE_GETPROPBLOB, );
+   if (err != 0)
+   return err;
+
+   if (get.length != sizeof(test_mode_valid))
+   return ENOMEM;
+
+   get.data = (uintptr_t) _mode;
+
+   err = drmIoctl(fd, DRM_IOCTL_MODE_GETPROPBLOB, );
+   if (err != 0)
+   return err;
+
+   if (memcmp(_mode, _mode_valid, sizeof(test_mode_valid)) != 0)
+   return EINVAL;
+
+   return 0;
+}
+
+static uint32_t
+create_prop(int fd)
+{
+   struct drm_mode_create_blob create;
+
+   create.length = sizeof(test_mode_valid);
+   create.data = (uintptr_t) _mode_valid;
+
+   do_ioctl(fd, DRM_IOCTL_MODE_CREATEPROPBLOB, );
+
+   return create.blob_id;
+}
+
+static int
+destroy_prop(int fd, uint32_t prop_id)
+{
+   struct drm_mode_destroy_blob destroy;
+   int err;
+
+   destroy.blob_id = prop_id;
+   err = drmIoctl(fd, DRM_IOCTL_MODE_DESTROYPROPBLOB, );
+   return err;
+}
+
+static void
+test_validate(int fd)
+{
+   struct drm_mode_create_blob create;
+   struct drm_mode_get_blob get;
+   char too_small[32];
+   uint32_t prop_id;
+   int ret;
+
+   memset(too_small, 0, sizeof(too_small));
+
+   /* Outlandish size. */
+   create.length = 0x1;
+   create.data = (uintptr_t) _small;
+   ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATEPROPBLOB, );
+   igt_assert(ret != 0 && errno == EFAULT);
+
+   /* 

[Intel-gfx] [PATCH i-g-t v3 1/2] tests: Add blob-property test

[Daniel Stone]

Exercises the new blob-creation ioctl, testing lifetimes and behaviour
of user-created blobs, as well as exercising all the invariant
conditions we guarantee from modes exposed as blob properties.

v2: Renamed to core_prop_blob, skip test if blob not available.
v3: No changes.

Signed-off-by: Daniel Stone 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/core_prop_blob.c | 237 +
 3 files changed, 239 insertions(+)
 create mode 100644 tests/core_prop_blob.c

diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53..beda511 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -3,6 +3,7 @@ core_get_client_auth
 core_getclient
 core_getstats
 core_getversion
+core_prop_blob
 drm_auth
 drm_import_export
 drm_read
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2e2e088..0f0e481 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -76,6 +76,7 @@ TESTS_progs_M = \
kms_pipe_b_c_ivb \
kms_pipe_crc_basic \
kms_plane \
+   kms_prop_blob \
kms_psr_sink_crc \
kms_render \
kms_rotation_crc \
diff --git a/tests/core_prop_blob.c b/tests/core_prop_blob.c
new file mode 100644
index 000..1250c00
--- /dev/null
+++ b/tests/core_prop_blob.c
@@ -0,0 +1,237 @@
+/*
+ * Copyright © 2014-2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *   Damien Lespiau 
+ *   Daniel Stone 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION("Tests behaviour of mass-data 'blob' properties.");
+
+static const struct drm_mode_modeinfo test_mode_valid = {
+   .clock = 1234,
+   .hdisplay = 640,
+   .hsync_start = 641,
+   .hsync_end = 642,
+   .htotal = 643,
+   .hskew = 0,
+   .vdisplay = 480,
+   .vsync_start = 481,
+   .vsync_end = 482,
+   .vtotal = 483,
+   .vscan = 0,
+   .vrefresh = 6,
+   .flags = 0,
+   .type = 0,
+   .name = "FROMUSER",
+};
+
+
+static int
+validate_prop(int fd, uint32_t prop_id)
+{
+   struct drm_mode_get_blob get;
+   struct drm_mode_modeinfo ret_mode;
+   int err;
+
+   get.blob_id = prop_id;
+   get.length = 0;
+   get.data = (uintptr_t) 0;
+
+   err = drmIoctl(fd, DRM_IOCTL_MODE_GETPROPBLOB, );
+   if (err != 0)
+   return err;
+
+   if (get.length != sizeof(test_mode_valid))
+   return ENOMEM;
+
+   get.data = (uintptr_t) _mode;
+
+   err = drmIoctl(fd, DRM_IOCTL_MODE_GETPROPBLOB, );
+   if (err != 0)
+   return err;
+
+   if (memcmp(_mode, _mode_valid, sizeof(test_mode_valid)) != 0)
+   return EINVAL;
+
+   return 0;
+}
+
+static uint32_t
+create_prop(int fd)
+{
+   struct drm_mode_create_blob create;
+
+   create.length = sizeof(test_mode_valid);
+   create.data = (uintptr_t) _mode_valid;
+
+   do_ioctl(fd, DRM_IOCTL_MODE_CREATEPROPBLOB, );
+
+   return create.blob_id;
+}
+
+static int
+destroy_prop(int fd, uint32_t prop_id)
+{
+   struct drm_mode_destroy_blob destroy;
+   int err;
+
+   destroy.blob_id = prop_id;
+   err = drmIoctl(fd, DRM_IOCTL_MODE_DESTROYPROPBLOB, );
+   return err;
+}
+
+static void
+test_validate(int fd)
+{
+   struct drm_mode_create_blob create;
+   struct drm_mode_get_blob get;
+   char too_small[32];
+   uint32_t prop_id;
+   int ret;
+
+   memset(too_small, 0, sizeof(too_small));
+
+   /* Outlandish size. */
+   create.length = 0x1;
+   create.data = (uintptr_t) _small;
+   ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATEPROPBLOB, );
+   igt_assert(ret != 0 && errno == EFAULT);
+
+   /* 

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add HDMI probe function

[Rodrigo Vivi]

I liked the approach and agree with Daniel, so with his suggestions feel
free to use:
Reviewed-by: Rodrigo Vivi 

On Fri, Sep 4, 2015 at 7:46 AM Daniel Vetter  wrote:

> On Fri, Sep 04, 2015 at 06:56:12PM +0530, Sonika Jindal wrote:
> > From: Shashank Sharma 
> >
> > This patch adds a separate probe function for HDMI
> > EDID read over DDC channel. This function has been
> > registered as a .hot_plug handler for HDMI encoder.
> >
> > The current implementation of hdmi_detect()
> > function re-sets the cached HDMI edid (in connector->detect_edid) in
> > every detect call.This function gets called many times, sometimes
> > directly from userspace probes, forcing drivers to read EDID every
> > detect function call.This causes several problems like:
> >
> > 1. Race conditions in multiple hot_plug / unplug cases, between
> >interrupts bottom halves and userspace detections.
> > 2. Many Un-necessary EDID reads for single hotplug/unplug
> > 3. HDMI complaince failures which expects only one EDID read per hotplug
> >
> > This function will be serving the purpose of really reading the EDID
> > by really probing the DDC channel, and updating the cached EDID.
> >
> > The plan is to:
> > 1. i915 IRQ handler bottom half function already calls
> >intel_encoder->hotplug() function. Adding This probe function which
> >will read the EDID only in case of a hotplug / unplug.
> > 2. During init_connector his probe will be called to read the edid
> > 3. Reuse the cached EDID in hdmi_detect() function.
> >
> > The "< gen7" check is there because this was tested only for >=gen7
> > platforms. For older platforms the hotplug/reading edid path remains
> same.
> >
> > v2: Calling set_edid instead of hdmi_probe during init.
> > Also, for platforms having DDI, intel_encoder for DP and HDMI is same
> > (taken from intel_dig_port), so for DP also, hot_plug function gets
> called
> > which is not intended here. So, check for HDMI in intel_hdmi_probe
> > Rely on HPD for updating edid only for platforms gen > 8 and also for
> VLV.
> >
> > v3: Dropping the gen < 8 || !VLV  check. Now all platforms should rely on
> > hotplug or init for updating the edid.(Daniel)
> > Also, calling hdmi_probe in init instead of set_edid
> >
> > Signed-off-by: Shashank Sharma 
> > Signed-off-by: Sonika Jindal 
> > ---
> >  drivers/gpu/drm/i915/intel_hdmi.c |   46
> -
> >  1 file changed, 40 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 5bdb386..1eda71a 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1368,23 +1368,53 @@ intel_hdmi_set_edid(struct drm_connector
> *connector)
> >   return connected;
> >  }
> >
> > +void intel_hdmi_probe(struct intel_encoder *intel_encoder)
>
> Please call it _hot_plug if it's for the _hot_plug path.
>
> > +{
> > + struct intel_hdmi *intel_hdmi =
> > + enc_to_intel_hdmi(_encoder->base);
> > + struct intel_connector *intel_connector =
> > + intel_hdmi->attached_connector;
> > +
> > + /*
> > +  * We are here, means there is a hotplug or a force
> > +  * detection. Clear the cached EDID and probe the
> > +  * DDC bus to check the current status of HDMI.
> > +  */
> > + intel_hdmi_unset_edid(_connector->base);
> > + if (intel_hdmi_set_edid(_connector->base))
> > + DRM_DEBUG_DRIVER("DDC probe: got EDID\n");
> > + else
> > + DRM_DEBUG_DRIVER("DDC probe: no EDID\n");
> > +}
> > +
> >  static enum drm_connector_status
> >  intel_hdmi_detect(struct drm_connector *connector, bool force)
> >  {
> >   enum drm_connector_status status;
> > + struct intel_connector *intel_connector =
> > + to_intel_connector(connector);
> >
> >   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> > connector->base.id, connector->name);
> > + /*
> > +  * There are many userspace calls which probe EDID from
> > +  * detect path. In case of multiple hotplug/unplug, these
> > +  * can cause race conditions while probing EDID. Also its
> > +  * waste of CPU cycles to read the EDID again and again
> > +  * unless there is a real hotplug.
> > +  * So, rely on hotplugs and init to read edid.
> > +  * Check connector status based on availability of cached EDID.
> > +  */
> >
> > - intel_hdmi_unset_edid(connector);
> > -
> > - if (intel_hdmi_set_edid(connector)) {
> > + if (intel_connector->detect_edid) {
> >   struct intel_hdmi *intel_hdmi =
> intel_attached_hdmi(connector);
> > -
> > - hdmi_to_dig_port(intel_hdmi)->base.type =
> INTEL_OUTPUT_HDMI;
> >   status = connector_status_connected;
> > - } else
> > + 

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Make intel_digital_port_connected global

[Rodrigo Vivi]

On Fri, Sep 4, 2015 at 6:37 AM Sonika Jindal 
wrote:

> This is to allow live status check for HDMI as well.
> Also, using intel_encoder->hpd_pin to check the live status
> for bxt because of BXT A0/A1 WA for HPD pins.
>

This is actually the only thing this patch does... So please use separated
patch for this

But the global intel_digital_port connected can be done in the same patch
that uses it actually...


>
> Signed-off-by: Sonika Jindal 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  |   11 +++
>  drivers/gpu/drm/i915/intel_drv.h |2 ++
>  2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 796f930..fedf6d1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4663,11 +4663,14 @@ static bool vlv_digital_port_connected(struct
> drm_i915_private *dev_priv,
>  }
>
>  static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
> -  struct intel_digital_port *port)
> +  struct intel_digital_port
> *intel_dig_port)
>  {
> +   struct intel_encoder *intel_encoder = _dig_port->base;
> +   enum port port;
> u32 bit;
>
> -   switch (port->port) {
> +   intel_hpd_pin_to_port(intel_encoder->hpd_pin, );
> +   switch (port) {
> case PORT_A:
> bit = BXT_DE_PORT_HP_DDIA;
> break;
> @@ -4678,7 +4681,7 @@ static bool bxt_digital_port_connected(struct
> drm_i915_private *dev_priv,
> bit = BXT_DE_PORT_HP_DDIC;
> break;
> default:
> -   MISSING_CASE(port->port);
> +   MISSING_CASE(port);
> return false;
> }
>
> @@ -4692,7 +4695,7 @@ static bool bxt_digital_port_connected(struct
> drm_i915_private *dev_priv,
>   *
>   * Return %true if @port is connected, %false otherwise.
>   */
> -static bool intel_digital_port_connected(struct drm_i915_private
> *dev_priv,
> +bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
>  struct intel_digital_port *port)
>  {
> if (HAS_PCH_IBX(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index b6c2c20..ac6d748 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1210,6 +1210,8 @@ void intel_edp_drrs_disable(struct intel_dp
> *intel_dp);
>  void intel_edp_drrs_invalidate(struct drm_device *dev,
> unsigned frontbuffer_bits);
>  void intel_edp_drrs_flush(struct drm_device *dev, unsigned
> frontbuffer_bits);
> +bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *port);
>
>  /* intel_dp_mst.c */
>  int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port,
> int conn_id);
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: drm/i915: Check live status before reading edid

[Rodrigo Vivi]

On Fri, Sep 4, 2015 at 7:47 AM Daniel Vetter  wrote:

> On Fri, Sep 04, 2015 at 06:56:14PM +0530, Sonika Jindal wrote:
> > The Bspec is very clear that Live status must be checked about before
> > trying to read EDID over DDC channel. This patch makes sure that HDMI
> > EDID is read only when live status us up.
>

s/us/is


> >
> > The live status doesn't seem to perform very consistent across various
> > platforms when tested with different monitors. The reason behind that is
> > some monitors are late to provide right voltage to set live_status up.
> > So, after getting the interrupt, for a small duration, live status reg
> > fluctuates, and then settles down showing the correct staus.
> >
> > This is explained here in, in a rough way:
> > HPD line  
> >|\ T1 = Monitor Hotplug causing IRQ
> >| \__
> >| |
> >  | |
> >| |   T2 = Live status is stable
> >| |  _
> >| | /|
> > Live status _|_|/ |
> >| |  |
> >| |  |
> >| |  |
> >   T0 T1  T2
> >
> > (Between T1 and T2 Live status fluctuates or can be even low, depending
> on
> >  the monitor)
> >
> > After several experiments, we have concluded that a max delay
> > of 30ms is enough to allow the live status to settle down with
> > most of the monitors. This total delay of 30ms has been split into
> > a resolution of 3 retries of 10ms each, for the better cases.
> >
> > This delay is kept at 30ms, keeping in consideration that, HDCP
> compliance
> > expect the HPD handler to respond a plug out in 100ms, by disabling the
> port.
> >
> > v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
> > to check digital port status. Adding a separate function to get bxt live
> > status (Daniel)
> > v3: Using intel_encoder->hpd_pin to check the live status (Siva)
> > Moving the live status read to intel_hdmi_probe and passing parameter
> > to read/not to read the edid. (me)
> > v4:
> > * Added live status check for all platforms using
> > intel_digital_port_connected.
> > * Rebased on top of Jani's DP cleanup series
> > * Some monitors take time in setting the live status. So retry for few
> > times if this is a connect HPD
> >
> > Signed-off-by: Sonika Jindal 
>
> Really pretty commit message! Had some minor comments on two other patches
> in this series while reading through them, but looks good otherwise.
> Please sign up someone for final review of the details and I'll pull in
> the patches once that's done.
> -Daniel
>
> > ---
> >  drivers/gpu/drm/i915/intel_hdmi.c |   35
> ---
> >  1 file changed, 28 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 1eda71a..d82887b 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1329,22 +1329,23 @@ intel_hdmi_unset_edid(struct drm_connector
> *connector)
> >  }
> >
> >  static bool
> > -intel_hdmi_set_edid(struct drm_connector *connector)
> > +intel_hdmi_set_edid(struct drm_connector *connector, bool force)
> >  {
> >   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> >   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> >   struct intel_encoder *intel_encoder =
> >   _to_dig_port(intel_hdmi)->base;
> >   enum intel_display_power_domain power_domain;
> > - struct edid *edid;
> > + struct edid *edid = NULL;
> >   bool connected = false;
> >
> >   power_domain = intel_display_port_power_domain(intel_encoder);
> >   intel_display_power_get(dev_priv, power_domain);
> >
> > - edid = drm_get_edid(connector,
> > - intel_gmbus_get_adapter(dev_priv,
> > - intel_hdmi->ddc_bus));
> > + if (force)
>

The force name is confusing here since you only don't get edid in any other
way when it is false...

But also there is the risk of this function to get called only with this
false and never gets edid..
So I believe we should add a debug message here at least for this case so
if we start getting cases where panel is taking more than 30ms to get live
we will know why we did't actually read the edid


> > + edid = drm_get_edid(connector,
> > + intel_gmbus_get_adapter(dev_priv,
> > + intel_hdmi->ddc_bus));
> >
> >   intel_display_power_put(dev_priv, power_domain);
> >
> > @@ -1374,6 +1375,26 @@ void intel_hdmi_probe(struct intel_encoder
> *intel_encoder)
> >   enc_to_intel_hdmi(_encoder->base);
> >   struct 

Re: [Intel-gfx] [PATCH i-g-t] tools/Android.mk: Fix compile error in intel_reg.c

[Morton, Derek J]

-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com] 
Sent: Wednesday, September 9, 2015 2:48 PM
To: Morton, Derek J
Cc: Intel Graphics Development
Subject: Re: [PATCH i-g-t] tools/Android.mk: Fix compile error in intel_reg.c
>
>On 9 September 2015 at 14:30, Derek Morton  wrote:
>> The patch "tools: install the register definition files" caused a 
>> build error on android as it added 'PKGDATADIR' which was not defined 
>> in the Android build environment. This patch adds that define to 
>> tools/Android.mk. It also copies the files it points to so they are 
>> actually in the target file system.
>
>Missing Signed-off-by line.

Will add.

>
>> ---
>>  tools/Android.mk | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/tools/Android.mk b/tools/Android.mk index 
>> 0a196e4..aae7db5 100644
>> --- a/tools/Android.mk
>> +++ b/tools/Android.mk
>> @@ -34,11 +34,18 @@ define add_tool
>>libdrm\
>>libdrm_intel
>>
>> +LOCAL_MODULE_PATH := 
>> + $(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools
>
>Is this part of the same fix?

This is putting all the tools with the other igt binaries so the register files 
then have somewhere logical to also be put.

>
>
>> +LOCAL_CFLAGS += 
>> -DPKGDATADIR=\"/system/vendor/intel/validation/core/igt/tools\"
>
>This should have /registers on the end. Might be worth having a local variable 
>to avoid specifying the path explicitly each time.

I don’t think it should. /registers is added in intel_reg.c
path = PKGDATADIR"/registers";

I can create a local variable.

>
>
>>  include $(BUILD_EXECUTABLE)
>>  endef
>>
>>  ##
>>
>> +# Copy the register files
>> +$(shell mkdir -p 
>> +$(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools/registers)
>> +$(shell cp $(LOCAL_PATH)/registers/* 
>> +$(TARGET_OUT_VENDOR)/intel/validation/core/igt/tools/registers)
>> +
>> +
>>  skip_tools_list := \
>>  intel_framebuffer_dump \
>>  intel_reg_dumper \
>> --
>> 1.9.1
>>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm/i915: add attached connector to hdmi container

[Rodrigo Vivi]

Reviewed-by: Rodrigo Vivi 

On Fri, Sep 4, 2015 at 6:37 AM Sonika Jindal 
wrote:

> From: Shashank Sharma 
>
> This patch adds the intel_connector initialized to intel_hdmi
> display, during the init phase, just like the other encoders do.
> This attachment is very useful when we need to extract the connector
> pointer during the hotplug handler function
>
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/intel_drv.h  |1 +
>  drivers/gpu/drm/i915/intel_hdmi.c |1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index c61ba47..b6c2c20 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -667,6 +667,7 @@ struct intel_hdmi {
> enum hdmi_force_audio force_audio;
> bool rgb_quant_range_selectable;
> enum hdmi_picture_aspect aspect_ratio;
> +   struct intel_connector *attached_connector;
> void (*write_infoframe)(struct drm_encoder *encoder,
> enum hdmi_infoframe_type type,
> const void *frame, ssize_t len);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index ed25f64..5bdb386 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2107,6 +2107,7 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
>
> intel_connector_attach_encoder(intel_connector, intel_encoder);
> drm_connector_register(connector);
> +   intel_hdmi->attached_connector = intel_connector;
>
> /* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be
> written
>  * 0xd.  Failure to do so will result in spurious interrupts being
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Daniel Vetter]

On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
 wrote:
> I am not even going that far, just talking about last frame stuck on screen.
> For me making that easier is a regression.

So let's look at various systems:
- super-modern fbdev less system: logind keeps a dup of every
master-capabel drm fd. Compositor crashing won't ever result in
close() getting called since logind still has its copy. Cleanup needs
to be done manually anyway with the system compositor.
- Current systems: Compositor restarts and cleans up the mess we left behind.
- Greybeards who start X with startx: Those folks also have fbdev,
which will do the recover.

In the strictest sense the screen leaks for a bit. In practice no one
will ever notice, at least assuming I haven't missed a use-case. And
for regression it only counts as one if you can actually spot a
difference ;-)
-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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx