[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int i915_oa_read(struct i915_perf_stream *stream,
> + struct i915_perf_read_state *read_state)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + return dev_priv->perf.oa.ops.read(stream, read_state);
> +}

> + stream->destroy = i915_oa_stream_destroy;
> + stream->enable = i915_oa_stream_enable;
> + stream->disable = i915_oa_stream_disable;
> + stream->can_read = i915_oa_can_read;
> + stream->wait_unlocked = i915_oa_wait_unlocked;
> + stream->poll_wait = i915_oa_poll_wait;
> + stream->read = i915_oa_read;

Why aren't these a const ops table?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void gen7_init_oa_buffer(struct drm_i915_private *dev_priv)
> +{
> + /* Pre-DevBDW: OABUFFER must be set with counters off,
> +  * before OASTATUS1, but after OASTATUS2
> +  */
> + I915_WRITE(GEN7_OASTATUS2, dev_priv->perf.oa.oa_buffer.gtt_offset |
> +OA_MEM_SELECT_GGTT); /* head */
> + I915_WRITE(GEN7_OABUFFER, dev_priv->perf.oa.oa_buffer.gtt_offset);
> + I915_WRITE(GEN7_OASTATUS1, dev_priv->perf.oa.oa_buffer.gtt_offset |
> +OABUFFER_SIZE_16M); /* tail */
> +
> + /* On Haswell we have to track which OASTATUS1 flags we've
> +  * already seen since they can't be cleared while periodic
> +  * sampling is enabled.
> +  */
> + dev_priv->perf.oa.gen7_latched_oastatus1 = 0;
> +
> + /* We have a sanity check in gen7_append_oa_reports() that
> +  * looks at the report-id field to make sure it's non-zero
> +  * which relies on the assumption that new reports are
> +  * being written to zeroed memory...
> +  */
> + memset(dev_priv->perf.oa.oa_buffer.addr, 0, SZ_16M);

You allocated zeroed memory.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH 1/9] drm/i915: Add i915 perf infrastructure

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:06PM +0100, Robert Bragg wrote:
> +static struct intel_context *
> +lookup_context(struct drm_i915_private *dev_priv,
> +struct file *user_filp,
> +u32 ctx_user_handle)
> +{
> + struct intel_context *ctx;
> +
> + mutex_lock(&dev_priv->dev->struct_mutex);
> + list_for_each_entry(ctx, &dev_priv->context_list, link) {
> + struct drm_file *drm_file;
> +
> + if (!ctx->file_priv)
> + continue;
> +
> + drm_file = ctx->file_priv->file;
> +
> + if (user_filp->private_data == drm_file &&
> + ctx->user_handle == ctx_user_handle) {
> + i915_gem_context_reference(ctx);
> + mutex_unlock(&dev_priv->dev->struct_mutex);
> +
> + return ctx;
> + }
> + }
> + mutex_unlock(&dev_priv->dev->struct_mutex);
> +
> + return NULL;
> +}
> +
> +int i915_perf_open_ioctl_locked(struct drm_device *dev,
> + struct drm_i915_perf_open_param *param,
> + struct perf_open_properties *props,
> + struct drm_file *file)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_context *specific_ctx = NULL;
> + struct i915_perf_stream *stream = NULL;
> + unsigned long f_flags = 0;
> + int stream_fd;
> + int ret = 0;
> +
> + if (props->single_context) {
> + u32 ctx_handle = props->ctx_handle;
> +
> + specific_ctx = lookup_context(dev_priv, file->filp, ctx_handle);

i915_gem_context_get(file->driver_priv, ctx_handle) ?

Though this doesn't allow ptrace like ability to watch a context
elsewhere. For that you need to pass in fd:ctx props.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[Intel-gfx] [PATCH 4/4] drm/i915: Move ioremap_wc tracking onto VMA

2016-04-20 Thread Luis R. Rodriguez
On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote:
> > Reason I ask is since I noticed a while ago a lot of drivers
> > were using info->fix.smem_start and info->fix.smem_len consistently
> > for their ioremap'd areas it might make sense instead to let the
> > internal framebuffer (register_framebuffer()) optionally manage the
> > ioremap_wc() for drivers, given that this is pretty generic stuff.
> 
> All that legacy fbdev stuff is just for legacy support, and I prefer to
> have that as dumb as possible. There's been some discussion even around
> lifting the "kick out firmware fb driver" out of fbdev, since we'd need it
> to have a simple drm driver for e.g. uefi.
> 
> But I definitely don't want a legacy horror show like fbdev to
> automagically take care of device mappings for drivers.

Makes sense, it also still begs the question if more modern APIs
could manage the ioremap for you. Evidence shows people get
sloppy and if things were done internally with helpers it may
be easier to later make adjustments.

  Luis


[PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

2016-04-20 Thread Luis R. Rodriguez
On Wed, Apr 20, 2016 at 08:14:32PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > > can be used for remapping multiple pages. Extend the helper so that
> > > future callers can use it for larger ranges.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Daniel Vetter 
> > > Cc: Jani Nikula 
> > > Cc: David Airlie 
> > > Cc: Yishai Hadas 
> > > Cc: Dan Williams 
> > > Cc: Ingo Molnar 
> > > Cc: "Peter Zijlstra (Intel)" 
> > > Cc: David Hildenbrand 
> > > Cc: Luis R. Rodriguez 
> > > Cc: intel-gfx at lists.freedesktop.org
> > > Cc: dri-devel at lists.freedesktop.org
> > > Cc: netdev at vger.kernel.org
> > > Cc: linux-rdma at vger.kernel.org
> > > Cc: linux-kernel at vger.kernel.org
> > 
> > We have 2 callers today, in the future, can you envision
> > this API getting more options? If so, in order to avoid the
> > pain of collateral evolutions I can suggest a descriptor
> > being passed with the required settings / options. This lets
> > you evolve the API without needing to go in and modify
> > old users. If you choose not to that's fine too, just
> > figured I'd chime in with that as I've seen the pain
> > with other APIs, and I'm putting an end to the needless
> > set of collateral evolutions this way.
> 
> Do you have a good example in mind? I've one more patch to try and take
> advantage of the io-mapping (that may or not be such a good idea in
> practice) but I may as well see if I can make io_mapping more useful
> when I do.

Sure, here's my current version of the revamp of the firmware API
to a more flexible API, which lets us compartamentalize the
usermode helper, and through the new API avoids the issues with further
future collateral evolutions. It is still being baked, I'm fine tuning
the SmPL to folks automatically do conversion if they want:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160417-sysdata-api-v1

It also has a test driver (which I'd also recommend if you can pull off).
It would be kind of hard to do something like a lib/io-mapping_test.c
given there is no real device to ioremap -- _but_ perhaps regular
RAM can be used for fake a device MMIO. I am not sure if its even
possible... but if so it would not only be useful for something
like your API but also for testing ioremap() and friends, and
any possible aliasing bombs we may want to vet for. It also hints
how we may in the future be able to automatically write test drivers
for APIs for us through inference, but that needs a lot of more love
to make it tangible.

  Luis


[PATCH 8/8] drm/udl: Use drm_fb_helper deferred_io support

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 9:20 PM, Noralf Trønnes  wrote:
>>> @@ -330,20 +203,20 @@ static int udl_fb_open(struct fb_info *info, int
>>> user)
>>> ufbdev->fb_count++;
>>>   - if (fb_defio && (info->fbdefio == NULL)) {
>>> -   /* enable defio at last moment if not disabled by client
>>> */
>>> +   if (!info->fbdefio) {
>>> +   /* enable defio at last moment */
>>> struct fb_deferred_io *fbdefio;
>>> fbdefio = kmalloc(sizeof(struct fb_deferred_io),
>>> GFP_KERNEL);
>>> -
>>> if (fbdefio) {
>>> fbdefio->delay = DL_DEFIO_WRITE_DELAY;
>>> -   fbdefio->deferred_io = udlfb_dpy_deferred_io;
>>> +   fbdefio->deferred_io = drm_fb_helper_deferred_io;
>>
>> Why all these changes here? I figured just exchanging the deferred_io
>> pointer should be all that's really needed in the setup code?
>
>
> Because we always need to initialize deferred_io since we use it's worker
> to handle fb_{fillrect,copyarea,imageblit} damage in drm_fb_helper.
>
> The previous code didn't use deferred_io to handle these, it just handled
> the damage directly unless it was running in atomic context, in which case
> it just recorded the damage and returned, leaving it to the next call to
> push the changes.

That kind of explanation needs to be added to the commit message. I
completely missed that udl doesn't have an async work item for defio
from atomic.

> And in the following code I fixed a null pointer problem as well, maybe I
> shouldn't have packed it in here. If fbdefio allocation fails == NULL,
> fb_deferred_io_init() will trigger a BUG().

Yeah, better to split that out into a separate bugfix I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int alloc_oa_buffer(struct drm_i915_private *dev_priv)
> +{
> + struct drm_i915_gem_object *bo;
> + int ret;
> +
> + BUG_ON(dev_priv->perf.oa.oa_buffer.obj);
> +
> + ret = i915_mutex_lock_interruptible(dev_priv->dev);
> + if (ret)
> + return ret;
> +
> + bo = i915_gem_alloc_object(dev_priv->dev, OA_BUFFER_SIZE);
> + if (bo == NULL) {
> + DRM_ERROR("Failed to allocate OA buffer\n");
> + ret = -ENOMEM;
> + goto unlock;
> + }
> + dev_priv->perf.oa.oa_buffer.obj = bo;
> +
> + ret = i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> + if (ret)
> + goto err_unref;
> +
> + /* PreHSW required 512K alignment, HSW requires 16M */
> + ret = i915_gem_obj_ggtt_pin(bo, SZ_16M, 0);
> + if (ret)
> + goto err_unref;
> +
> + dev_priv->perf.oa.oa_buffer.gtt_offset = i915_gem_obj_ggtt_offset(bo);
> + dev_priv->perf.oa.oa_buffer.addr = vmap_oa_buffer(bo);

Now i915_gem_object_pin_map(bo) instead of manually vmapping it, and
i915_gem_object_unpin_map() to release.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH 1/1] change the order to cleanup drm_property_blob after drm_crtc

2016-04-20 Thread Xiong, James
Could someone please take a look and see if the change makes sense at all?

Thanks,
James

-Original Message-
From: Xiong, James 
Sent: Wednesday, April 13, 2016 11:09 AM
To: dri-devel at lists.freedesktop.org
Cc: intel-gfx at lists.freedesktop.org; Xiong, James 
Subject: [PATCH 1/1] change the order to cleanup drm_property_blob after 
drm_crtc

From: "Xiong, James" 

Previously drm_mode_config_cleanup freed drm_property_blob first, then the 
drm_crtc which triggered unref calls to its associated drm_propery_blob, and 
could potentially cause memory corruption.

Signed-off-by: Xiong, James 
---
 drivers/gpu/drm/drm_crtc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 
30fea23..c93576a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5950,11 +5950,6 @@ void drm_mode_config_cleanup(struct drm_device *dev)
drm_property_destroy(dev, property);
}

-   list_for_each_entry_safe(blob, bt, &dev->mode_config.property_blob_list,
-head_global) {
-   drm_property_unreference_blob(blob);
-   }
-
/*
 * Single-threaded teardown context, so it's not required to grab the
 * fb_lock to protect against concurrent fb_list access. Contrary, it 
@@ -5977,6 +5972,11 @@ void drm_mode_config_cleanup(struct drm_device *dev)
crtc->funcs->destroy(crtc);
}

+   list_for_each_entry_safe(blob, bt, &dev->mode_config.property_blob_list,
+   head_global) {
+   drm_property_unreference_blob(blob);
+   }
+
ida_destroy(&dev->mode_config.connector_ida);
idr_destroy(&dev->mode_config.tile_idr);
idr_destroy(&dev->mode_config.crtc_idr);
--
1.9.1



[Bug 93144] [radeonsi] Alien: Isolation feature request

2016-04-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93144

--- Comment #36 from Christoph Haag  ---
For me it's still only almost.

Here is another video I recorded:
https://youtu.be/RDO0MeZAvms?t=321

This time all doors and rooms were fine, but the characters were not.

Hardware:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Wimbledon XT [Radeon HD 7970M] (rev ff)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/8cf52226/attachment.html>


[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void gen7_update_oacontrol_locked(struct drm_i915_private *dev_priv)
> +{
> + assert_spin_locked(&dev_priv->perf.hook_lock);
> +
> + if (dev_priv->perf.oa.exclusive_stream->enabled) {
> + unsigned long ctx_id = 0;
> +
> + if (dev_priv->perf.oa.exclusive_stream->ctx)
> + ctx_id = dev_priv->perf.oa.specific_ctx_id;
> +
> + if (dev_priv->perf.oa.exclusive_stream->ctx == NULL || ctx_id) {
> + bool periodic = dev_priv->perf.oa.periodic;
> + u32 period_exponent = dev_priv->perf.oa.period_exponent;
> + u32 report_format = dev_priv->perf.oa.oa_buffer.format;
> +
> + I915_WRITE(GEN7_OACONTROL,
> +(ctx_id & GEN7_OACONTROL_CTX_MASK) |
> +(period_exponent <<
> + GEN7_OACONTROL_TIMER_PERIOD_SHIFT) |
> +(periodic ?
> + GEN7_OACONTROL_TIMER_ENABLE : 0) |
> +(report_format <<
> + GEN7_OACONTROL_FORMAT_SHIFT) |
> +(ctx_id ?
> + GEN7_OACONTROL_PER_CTX_ENABLE : 0) |
> +GEN7_OACONTROL_ENABLE);

So this works by only recording when the OACONTROL context address
matches the CCID.

Rather than hooking into switch context and checking every batch whether
you have the exclusive context in case it changed address, you could
just pin the exclusive context when told by the user to bind perf to
that context. Then it will also have the same address until oa is
finished (and releases it vma pin).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH 8/8] drm/udl: Use drm_fb_helper deferred_io support

2016-04-20 Thread Noralf Trønnes

Den 20.04.2016 19:59, skrev Daniel Vetter:
> On Wed, Apr 20, 2016 at 05:25:29PM +0200, Noralf Trønnes wrote:
>> Use the fbdev deferred io support in drm_fb_helper.
>> The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
>> now be deferred in the same way that mmap damage is, instead of being
>> flushed directly.
>> The deferred mmap functionality is kept disabled by default, because of the
>> list corruption problems mentioned in commit 677d23b70bf9
>> ("drm/udl: disable fb_defio by default").
>> This patch has only been compile tested.
>>
>> Signed-off-by: Noralf Trønnes 
>> ---
>>   drivers/gpu/drm/udl/udl_drv.h |   2 -
>>   drivers/gpu/drm/udl/udl_fb.c  | 152 
>> --
>>   2 files changed, 12 insertions(+), 142 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
>> index 4a064ef..0b03d34 100644
>> --- a/drivers/gpu/drm/udl/udl_drv.h
>> +++ b/drivers/gpu/drm/udl/udl_drv.h
>> @@ -81,8 +81,6 @@ struct udl_framebuffer {
>>  struct drm_framebuffer base;
>>  struct udl_gem_object *obj;
>>  bool active_16; /* active on the 16-bit channel */
>> -int x1, y1, x2, y2; /* dirty rect */
>> -spinlock_t dirty_lock;
>>   };
>>   
>>   #define to_udl_fb(x) container_of(x, struct udl_framebuffer, base)
>> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
>> index a52de2f..b44d4a7 100644
>> --- a/drivers/gpu/drm/udl/udl_fb.c
>> +++ b/drivers/gpu/drm/udl/udl_fb.c
>> @@ -77,68 +77,6 @@ static uint16_t rgb16(uint32_t col)
>>   }
>>   #endif
>>   
>> -/*
>> - * NOTE: fb_defio.c is holding info->fbdefio.mutex
>> - *   Touching ANY framebuffer memory that triggers a page fault
>> - *   in fb_defio will cause a deadlock, when it also tries to
>> - *   grab the same mutex.
>> - */
>> -static void udlfb_dpy_deferred_io(struct fb_info *info,
>> -  struct list_head *pagelist)
>> -{
>> -struct page *cur;
>> -struct fb_deferred_io *fbdefio = info->fbdefio;
>> -struct udl_fbdev *ufbdev = info->par;
>> -struct drm_device *dev = ufbdev->ufb.base.dev;
>> -struct udl_device *udl = dev->dev_private;
>> -struct urb *urb;
>> -char *cmd;
>> -cycles_t start_cycles, end_cycles;
>> -int bytes_sent = 0;
>> -int bytes_identical = 0;
>> -int bytes_rendered = 0;
>> -
>> -if (!fb_defio)
>> -return;
>> -
>> -start_cycles = get_cycles();
>> -
>> -urb = udl_get_urb(dev);
>> -if (!urb)
>> -return;
>> -
>> -cmd = urb->transfer_buffer;
>> -
>> -/* walk the written page list and render each to device */
>> -list_for_each_entry(cur, &fbdefio->pagelist, lru) {
>> -
>> -if (udl_render_hline(dev, (ufbdev->ufb.base.bits_per_pixel / 8),
>> - &urb, (char *) info->fix.smem_start,
>> - &cmd, cur->index << PAGE_SHIFT,
>> - cur->index << PAGE_SHIFT,
>> - PAGE_SIZE, &bytes_identical, &bytes_sent))
>> -goto error;
>> -bytes_rendered += PAGE_SIZE;
>> -}
>> -
>> -if (cmd > (char *) urb->transfer_buffer) {
>> -/* Send partial buffer remaining before exiting */
>> -int len = cmd - (char *) urb->transfer_buffer;
>> -udl_submit_urb(dev, urb, len);
>> -bytes_sent += len;
>> -} else
>> -udl_urb_completion(urb);
>> -
>> -error:
>> -atomic_add(bytes_sent, &udl->bytes_sent);
>> -atomic_add(bytes_identical, &udl->bytes_identical);
>> -atomic_add(bytes_rendered, &udl->bytes_rendered);
>> -end_cycles = get_cycles();
>> -atomic_add(((unsigned int) ((end_cycles - start_cycles)
>> ->> 10)), /* Kcycles */
>> -   &udl->cpu_kcycles_used);
>> -}
>> -
>>   int udl_handle_damage(struct udl_framebuffer *fb, int x, int y,
>>int width, int height)
>>   {
>> @@ -152,9 +90,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
>> int y,
>>  struct urb *urb;
>>  int aligned_x;
>>  int bpp = (fb->base.bits_per_pixel / 8);
>> -int x2, y2;
>> -bool store_for_later = false;
>> -unsigned long flags;
>>   
>>  if (!fb->active_16)
>>  return 0;
>> @@ -180,38 +115,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int 
>> x, int y,
>>  (y + height > fb->base.height))
>>  return -EINVAL;
>>   
>> -/* if we are in atomic just store the info
>> -   can't test inside spin lock */
>> -if (in_atomic())
>> -store_for_later = true;
>> -
>> -x2 = x + width - 1;
>> -y2 = y + height - 1;
>> -
>> -spin_lock_irqsave(&fb->dirty_lock, flags);
>> -
>> -if (fb->y1 < y)
>> -y = fb->y1;
>> -if (fb->y2 > y2)
>> -y2 = fb->y2;
>> -if (fb->x1 < x)
>> -x = fb->x1;
>> -if (fb->x2 > x2)
>> -x2 =

[PATCH 7/8] drm/qxl: Use drm_fb_helper deferred_io support

2016-04-20 Thread Noralf Trønnes

Den 20.04.2016 19:47, skrev Daniel Vetter:
> On Wed, Apr 20, 2016 at 05:25:28PM +0200, Noralf Trønnes wrote:
>> Use the fbdev deferred io support in drm_fb_helper.
>> The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
>> now be deferred in the same way that mmap damage is, instead of being
>> flushed directly.
>> This patch has only been compile tested.
>>
>> Signed-off-by: Noralf Trønnes 
>> ---
>>   drivers/gpu/drm/qxl/qxl_display.c |   9 +-
>>   drivers/gpu/drm/qxl/qxl_drv.h |   7 +-
>>   drivers/gpu/drm/qxl/qxl_fb.c  | 220 
>> ++
>>   drivers/gpu/drm/qxl/qxl_kms.c |   4 -
>>   4 files changed, 62 insertions(+), 178 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
>> b/drivers/gpu/drm/qxl/qxl_display.c
>> index 030409a..9a03524 100644
>> --- a/drivers/gpu/drm/qxl/qxl_display.c
>> +++ b/drivers/gpu/drm/qxl/qxl_display.c
>> @@ -465,7 +465,7 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
>>  .page_flip = qxl_crtc_page_flip,
>>   };
>>   
>> -static void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
>> +void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
>>   {
>>  struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
>>   
>> @@ -527,12 +527,13 @@ int
>>   qxl_framebuffer_init(struct drm_device *dev,
>>   struct qxl_framebuffer *qfb,
>>   const struct drm_mode_fb_cmd2 *mode_cmd,
>> - struct drm_gem_object *obj)
>> + struct drm_gem_object *obj,
>> + const struct drm_framebuffer_funcs *funcs)
> There should be no need at all to have a separate fb funcs table for the
> fbdev fb. Both /should/ be able to use the exact same (already existing)
> ->dirty() callback. We need this only in CMA because CMA is a midlayer
> used by multiple drivers.

I don't see how I can avoid it.

fbdev framebuffer flushing:

static void qxl_fb_dirty_flush(struct fb_info *info)
{
 qxl_fb_image_init(&qxl_fb_image, qdev, info, NULL);
 qxl_draw_opaque_fb(&qxl_fb_image, stride);
}

drm framebuffer flushing:

static int qxl_framebuffer_surface_dirty(...)
{
 qxl_draw_dirty_fb(...);
}

qxl_draw_opaque_fb() and qxl_draw_dirty_fb() differ so much that it's way
over my head to see if they can be combined.
Here's an online diff of the two functions:
https://www.diffchecker.com/jqbbalux


>
> With that change you should be able to condense this patch down to pretty
> much just removing lines. Which is Good (tm).
>
> Cheers, Daniel
>
>>   {
>>  int ret;
>>   
>>  qfb->obj = obj;
>> -ret = drm_framebuffer_init(dev, &qfb->base, &qxl_fb_funcs);
>> +ret = drm_framebuffer_init(dev, &qfb->base, funcs);
>>  if (ret) {
>>  qfb->obj = NULL;
>>  return ret;
>> @@ -999,7 +1000,7 @@ qxl_user_framebuffer_create(struct drm_device *dev,
>>  if (qxl_fb == NULL)
>>  return NULL;
>>   
>> -ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj);
>> +ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj, &qxl_fb_funcs);
>>  if (ret) {
>>  kfree(qxl_fb);
>>  drm_gem_object_unreference_unlocked(obj);
>> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
>> index 3f3897e..3ad6604 100644
>> --- a/drivers/gpu/drm/qxl/qxl_drv.h
>> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
>> @@ -324,8 +324,6 @@ struct qxl_device {
>>  struct workqueue_struct *gc_queue;
>>  struct work_struct gc_work;
>>   
>> -struct work_struct fb_work;
>> -
>>  struct drm_property *hotplug_mode_update_property;
>>  int monitors_config_width;
>>  int monitors_config_height;
>> @@ -389,11 +387,13 @@ int qxl_get_handle_for_primary_fb(struct qxl_device 
>> *qdev,
>>   void qxl_fbdev_set_suspend(struct qxl_device *qdev, int state);
>>   
>>   /* qxl_display.c */
>> +void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb);
>>   int
>>   qxl_framebuffer_init(struct drm_device *dev,
>>   struct qxl_framebuffer *rfb,
>>   const struct drm_mode_fb_cmd2 *mode_cmd,
>> - struct drm_gem_object *obj);
>> + struct drm_gem_object *obj,
>> + const struct drm_framebuffer_funcs *funcs);
>>   void qxl_display_read_client_monitors_config(struct qxl_device *qdev);
>>   void qxl_send_monitors_config(struct qxl_device *qdev);
>>   int qxl_create_monitors_object(struct qxl_device *qdev);
>> @@ -553,7 +553,6 @@ int qxl_irq_init(struct qxl_device *qdev);
>>   irqreturn_t qxl_irq_handler(int irq, void *arg);
>>   
>>   /* qxl_fb.c */
>> -int qxl_fb_init(struct qxl_device *qdev);
>>   bool qxl_fbdev_qobj_is_fb(struct qxl_device *qdev, struct qxl_bo *qobj);
>>   
>>   int qxl_debugfs_add_files(struct qxl_device *qdev,
>> diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
>> index 06f032d..090dcee 100644
>> --- a/drivers/gpu/drm/qxl/qxl_fb.c
>> +++ b/drivers/gpu/

[PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

2016-04-20 Thread Luis R. Rodriguez
On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> can be used for remapping multiple pages. Extend the helper so that
> future callers can use it for larger ranges.
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: Yishai Hadas 
> Cc: Dan Williams 
> Cc: Ingo Molnar 
> Cc: "Peter Zijlstra (Intel)" 
> Cc: David Hildenbrand 
> Cc: Luis R. Rodriguez 
> Cc: intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: netdev at vger.kernel.org
> Cc: linux-rdma at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org

We have 2 callers today, in the future, can you envision
this API getting more options? If so, in order to avoid the
pain of collateral evolutions I can suggest a descriptor
being passed with the required settings / options. This lets
you evolve the API without needing to go in and modify
old users. If you choose not to that's fine too, just
figured I'd chime in with that as I've seen the pain
with other APIs, and I'm putting an end to the needless
set of collateral evolutions this way.

Other than that possible API optimization:

Reviewed-by: Luis R. Rodriguez 

  Luis


[PATCH 5/8] fbdev: fb_defio: Export fb_deferred_io_mmap

2016-04-20 Thread Noralf Trønnes

Den 20.04.2016 19:44, skrev Daniel Vetter:
> On Wed, Apr 20, 2016 at 05:25:26PM +0200, Noralf Trønnes wrote:
>> Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
>> When the framebuffer memory is allocated using dma_alloc_writecombine()
>> instead of vmalloc(), I get cache syncing problems.
>> This solves it:
>>
>> static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
>>struct vm_area_struct *vma)
>> {
>>  fb_deferred_io_mmap(info, vma);
>>  vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> Hm, do we need pgpropt_writecombine? There recently was some discussion
> (on the arc platform) that fbdev pgprots need to be fixed up in fbdev
> code. I have no idea, just repeating from memory ...

I need it or else I get partial lines that doesn't get updated on the 
display.
fbdev code that doesn't set (struct fb_ops *)->fb_mmap, gets this for free
in the default fb_mmap implementation (drivers/video/fbdev/core/fbmem.c).
It calls fb_pgprotect() at the end which is an architecture specific
function that on many platforms uses pgprot_writecombine(), but not on all.
And looking at some of the fb_mmap implementations, some of them sets
vm_page_prot to nocache for instance, so I think the safest bet is to do
this here and not in the fbdev core. And we can't call fb_pgprotect() from
fb_deferred_io_mmap() either because we don't have access to the file
pointer that powerpc needs.
I think the case you refer to was solved with using fb_pgprotect() for
the platform in question and it didn't involve deferred io.

> -Daniel
>
>>  return 0;
>> }
>>
>> Signed-off-by: Noralf Trønnes 
>> ---
>>   drivers/video/fbdev/core/fb_defio.c | 3 ++-
>>   include/linux/fb.h  | 1 +
>>   2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/core/fb_defio.c 
>> b/drivers/video/fbdev/core/fb_defio.c
>> index 57721c7..74b5bca 100644
>> --- a/drivers/video/fbdev/core/fb_defio.c
>> +++ b/drivers/video/fbdev/core/fb_defio.c
>> @@ -164,7 +164,7 @@ static const struct address_space_operations 
>> fb_deferred_io_aops = {
>>  .set_page_dirty = fb_deferred_io_set_page_dirty,
>>   };
>>   
>> -static int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct 
>> *vma)
>> +int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
>>   {
>>  vma->vm_ops = &fb_deferred_io_vm_ops;
>>  vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
>> @@ -173,6 +173,7 @@ static int fb_deferred_io_mmap(struct fb_info *info, 
>> struct vm_area_struct *vma)
>>  vma->vm_private_data = info;
>>  return 0;
>>   }
>> +EXPORT_SYMBOL(fb_deferred_io_mmap);
>>   
>>   /* workqueue callback */
>>   static void fb_deferred_io_work(struct work_struct *work)
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index dfe8835..a964d07 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -673,6 +673,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
>> d_pitch,
>>   }
>>   
>>   /* drivers/video/fb_defio.c */
>> +int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
>>   extern void fb_deferred_io_init(struct fb_info *info);
>>   extern void fb_deferred_io_open(struct fb_info *info,
>>  struct inode *inode,
>> -- 
>> 2.2.2
>>



[Bug 93144] [radeonsi] Alien: Isolation feature request

2016-04-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93144

Luzipher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #35 from Luzipher  ---
Today, since compute shaders are committed to the mesa repo (commit
7143068296aaca8c5af3469c013a7c2a850aee84) and the llvm repo this game runs
flawlessly with nothing but "MESA_GL_VERSION_OVERRIDE=4.3
MESA_GLSL_VERSION_OVERRIDE=430" (which isn't enabled yet due to some bug that
doesn't affect Alien Isolation). I didn't see any flickery colours on fog or
anywhere else during the first level (on the Torrens).

Setting this bug to resolved. Thanks for getting it working, devs ! :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/891a4f36/attachment.html>


[PATCH 2/8] drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()

2016-04-20 Thread Noralf Trønnes

Den 20.04.2016 19:42, skrev Daniel Vetter:
> On Wed, Apr 20, 2016 at 05:25:23PM +0200, Noralf Trønnes wrote:
>> Now that drm_fb_helper gets deferred io support, the
>> drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
>> the worker that calls the deferred_io callback. This will break this
>> driver so use the sys_{fillrect,copyarea,imageblit} functions directly.
>>
>> Signed-off-by: Noralf Trønnes 
> I think this intermediately breaks the build, if you disable fbdev
> support. That's now supported in the fbdev helpers core generically across
> all drivers.
>
> Not sure how to best fix this up, since the only way would be to squash
> these patches, plus generic deferred io plus the conversion patches for
> udl/qxl all into one. Tricky.

Yes you're right, I missed that.
How about this:
#ifdef CONFIG_FB
 sys_fillrect(info, rect);
#endif

The later patch will then remove this ugliness...

> -Daniel
>
>> ---
>>   drivers/gpu/drm/udl/udl_fb.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
>> index fd1eb9d..a52de2f 100644
>> --- a/drivers/gpu/drm/udl/udl_fb.c
>> +++ b/drivers/gpu/drm/udl/udl_fb.c
>> @@ -287,7 +287,7 @@ static void udl_fb_fillrect(struct fb_info *info, const 
>> struct fb_fillrect *rect
>>   {
>>  struct udl_fbdev *ufbdev = info->par;
>>   
>> -drm_fb_helper_sys_fillrect(info, rect);
>> +sys_fillrect(info, rect);
>>   
>>  udl_handle_damage(&ufbdev->ufb, rect->dx, rect->dy, rect->width,
>>rect->height);
>> @@ -297,7 +297,7 @@ static void udl_fb_copyarea(struct fb_info *info, const 
>> struct fb_copyarea *regi
>>   {
>>  struct udl_fbdev *ufbdev = info->par;
>>   
>> -drm_fb_helper_sys_copyarea(info, region);
>> +sys_copyarea(info, region);
>>   
>>  udl_handle_damage(&ufbdev->ufb, region->dx, region->dy, region->width,
>>region->height);
>> @@ -307,7 +307,7 @@ static void udl_fb_imageblit(struct fb_info *info, const 
>> struct fb_image *image)
>>   {
>>  struct udl_fbdev *ufbdev = info->par;
>>   
>> -drm_fb_helper_sys_imageblit(info, image);
>> +sys_imageblit(info, image);
>>   
>>  udl_handle_damage(&ufbdev->ufb, image->dx, image->dy, image->width,
>>image->height);
>> -- 
>> 2.2.2
>>



[PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

2016-04-20 Thread Chris Wilson
On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > can be used for remapping multiple pages. Extend the helper so that
> > future callers can use it for larger ranges.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc: David Airlie 
> > Cc: Yishai Hadas 
> > Cc: Dan Williams 
> > Cc: Ingo Molnar 
> > Cc: "Peter Zijlstra (Intel)" 
> > Cc: David Hildenbrand 
> > Cc: Luis R. Rodriguez 
> > Cc: intel-gfx at lists.freedesktop.org
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: netdev at vger.kernel.org
> > Cc: linux-rdma at vger.kernel.org
> > Cc: linux-kernel at vger.kernel.org
> 
> We have 2 callers today, in the future, can you envision
> this API getting more options? If so, in order to avoid the
> pain of collateral evolutions I can suggest a descriptor
> being passed with the required settings / options. This lets
> you evolve the API without needing to go in and modify
> old users. If you choose not to that's fine too, just
> figured I'd chime in with that as I've seen the pain
> with other APIs, and I'm putting an end to the needless
> set of collateral evolutions this way.

Do you have a good example in mind? I've one more patch to try and take
advantage of the io-mapping (that may or not be such a good idea in
practice) but I may as well see if I can make io_mapping more useful
when I do.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH 8/8] drm/udl: Use drm_fb_helper deferred_io support

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 05:25:29PM +0200, Noralf Trønnes wrote:
> Use the fbdev deferred io support in drm_fb_helper.
> The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
> now be deferred in the same way that mmap damage is, instead of being
> flushed directly.
> The deferred mmap functionality is kept disabled by default, because of the
> list corruption problems mentioned in commit 677d23b70bf9
> ("drm/udl: disable fb_defio by default").
> This patch has only been compile tested.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/udl/udl_drv.h |   2 -
>  drivers/gpu/drm/udl/udl_fb.c  | 152 
> --
>  2 files changed, 12 insertions(+), 142 deletions(-)
> 
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 4a064ef..0b03d34 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -81,8 +81,6 @@ struct udl_framebuffer {
>   struct drm_framebuffer base;
>   struct udl_gem_object *obj;
>   bool active_16; /* active on the 16-bit channel */
> - int x1, y1, x2, y2; /* dirty rect */
> - spinlock_t dirty_lock;
>  };
>  
>  #define to_udl_fb(x) container_of(x, struct udl_framebuffer, base)
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index a52de2f..b44d4a7 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -77,68 +77,6 @@ static uint16_t rgb16(uint32_t col)
>  }
>  #endif
>  
> -/*
> - * NOTE: fb_defio.c is holding info->fbdefio.mutex
> - *   Touching ANY framebuffer memory that triggers a page fault
> - *   in fb_defio will cause a deadlock, when it also tries to
> - *   grab the same mutex.
> - */
> -static void udlfb_dpy_deferred_io(struct fb_info *info,
> -   struct list_head *pagelist)
> -{
> - struct page *cur;
> - struct fb_deferred_io *fbdefio = info->fbdefio;
> - struct udl_fbdev *ufbdev = info->par;
> - struct drm_device *dev = ufbdev->ufb.base.dev;
> - struct udl_device *udl = dev->dev_private;
> - struct urb *urb;
> - char *cmd;
> - cycles_t start_cycles, end_cycles;
> - int bytes_sent = 0;
> - int bytes_identical = 0;
> - int bytes_rendered = 0;
> -
> - if (!fb_defio)
> - return;
> -
> - start_cycles = get_cycles();
> -
> - urb = udl_get_urb(dev);
> - if (!urb)
> - return;
> -
> - cmd = urb->transfer_buffer;
> -
> - /* walk the written page list and render each to device */
> - list_for_each_entry(cur, &fbdefio->pagelist, lru) {
> -
> - if (udl_render_hline(dev, (ufbdev->ufb.base.bits_per_pixel / 8),
> -  &urb, (char *) info->fix.smem_start,
> -  &cmd, cur->index << PAGE_SHIFT,
> -  cur->index << PAGE_SHIFT,
> -  PAGE_SIZE, &bytes_identical, &bytes_sent))
> - goto error;
> - bytes_rendered += PAGE_SIZE;
> - }
> -
> - if (cmd > (char *) urb->transfer_buffer) {
> - /* Send partial buffer remaining before exiting */
> - int len = cmd - (char *) urb->transfer_buffer;
> - udl_submit_urb(dev, urb, len);
> - bytes_sent += len;
> - } else
> - udl_urb_completion(urb);
> -
> -error:
> - atomic_add(bytes_sent, &udl->bytes_sent);
> - atomic_add(bytes_identical, &udl->bytes_identical);
> - atomic_add(bytes_rendered, &udl->bytes_rendered);
> - end_cycles = get_cycles();
> - atomic_add(((unsigned int) ((end_cycles - start_cycles)
> - >> 10)), /* Kcycles */
> -&udl->cpu_kcycles_used);
> -}
> -
>  int udl_handle_damage(struct udl_framebuffer *fb, int x, int y,
> int width, int height)
>  {
> @@ -152,9 +90,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
> int y,
>   struct urb *urb;
>   int aligned_x;
>   int bpp = (fb->base.bits_per_pixel / 8);
> - int x2, y2;
> - bool store_for_later = false;
> - unsigned long flags;
>  
>   if (!fb->active_16)
>   return 0;
> @@ -180,38 +115,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
> int y,
>   (y + height > fb->base.height))
>   return -EINVAL;
>  
> - /* if we are in atomic just store the info
> -can't test inside spin lock */
> - if (in_atomic())
> - store_for_later = true;
> -
> - x2 = x + width - 1;
> - y2 = y + height - 1;
> -
> - spin_lock_irqsave(&fb->dirty_lock, flags);
> -
> - if (fb->y1 < y)
> - y = fb->y1;
> - if (fb->y2 > y2)
> - y2 = fb->y2;
> - if (fb->x1 < x)
> - x = fb->x1;
> - if (fb->x2 > x2)
> - x2 = fb->x2;
> -
> - if (store_for_later) {
> - fb->x1 = x;
> - fb->x2 = x2;
> - fb

[PATCH 7/8] drm/qxl: Use drm_fb_helper deferred_io support

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 05:25:28PM +0200, Noralf Trønnes wrote:
> Use the fbdev deferred io support in drm_fb_helper.
> The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
> now be deferred in the same way that mmap damage is, instead of being
> flushed directly.
> This patch has only been compile tested.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/qxl/qxl_display.c |   9 +-
>  drivers/gpu/drm/qxl/qxl_drv.h |   7 +-
>  drivers/gpu/drm/qxl/qxl_fb.c  | 220 
> ++
>  drivers/gpu/drm/qxl/qxl_kms.c |   4 -
>  4 files changed, 62 insertions(+), 178 deletions(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 030409a..9a03524 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -465,7 +465,7 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
>   .page_flip = qxl_crtc_page_flip,
>  };
>  
> -static void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
> +void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
>  {
>   struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
>  
> @@ -527,12 +527,13 @@ int
>  qxl_framebuffer_init(struct drm_device *dev,
>struct qxl_framebuffer *qfb,
>const struct drm_mode_fb_cmd2 *mode_cmd,
> -  struct drm_gem_object *obj)
> +  struct drm_gem_object *obj,
> +  const struct drm_framebuffer_funcs *funcs)

There should be no need at all to have a separate fb funcs table for the
fbdev fb. Both /should/ be able to use the exact same (already existing)
->dirty() callback. We need this only in CMA because CMA is a midlayer
used by multiple drivers.

With that change you should be able to condense this patch down to pretty
much just removing lines. Which is Good (tm).

Cheers, Daniel

>  {
>   int ret;
>  
>   qfb->obj = obj;
> - ret = drm_framebuffer_init(dev, &qfb->base, &qxl_fb_funcs);
> + ret = drm_framebuffer_init(dev, &qfb->base, funcs);
>   if (ret) {
>   qfb->obj = NULL;
>   return ret;
> @@ -999,7 +1000,7 @@ qxl_user_framebuffer_create(struct drm_device *dev,
>   if (qxl_fb == NULL)
>   return NULL;
>  
> - ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj);
> + ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj, &qxl_fb_funcs);
>   if (ret) {
>   kfree(qxl_fb);
>   drm_gem_object_unreference_unlocked(obj);
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 3f3897e..3ad6604 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -324,8 +324,6 @@ struct qxl_device {
>   struct workqueue_struct *gc_queue;
>   struct work_struct gc_work;
>  
> - struct work_struct fb_work;
> -
>   struct drm_property *hotplug_mode_update_property;
>   int monitors_config_width;
>   int monitors_config_height;
> @@ -389,11 +387,13 @@ int qxl_get_handle_for_primary_fb(struct qxl_device 
> *qdev,
>  void qxl_fbdev_set_suspend(struct qxl_device *qdev, int state);
>  
>  /* qxl_display.c */
> +void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb);
>  int
>  qxl_framebuffer_init(struct drm_device *dev,
>struct qxl_framebuffer *rfb,
>const struct drm_mode_fb_cmd2 *mode_cmd,
> -  struct drm_gem_object *obj);
> +  struct drm_gem_object *obj,
> +  const struct drm_framebuffer_funcs *funcs);
>  void qxl_display_read_client_monitors_config(struct qxl_device *qdev);
>  void qxl_send_monitors_config(struct qxl_device *qdev);
>  int qxl_create_monitors_object(struct qxl_device *qdev);
> @@ -553,7 +553,6 @@ int qxl_irq_init(struct qxl_device *qdev);
>  irqreturn_t qxl_irq_handler(int irq, void *arg);
>  
>  /* qxl_fb.c */
> -int qxl_fb_init(struct qxl_device *qdev);
>  bool qxl_fbdev_qobj_is_fb(struct qxl_device *qdev, struct qxl_bo *qobj);
>  
>  int qxl_debugfs_add_files(struct qxl_device *qdev,
> diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
> index 06f032d..090dcee 100644
> --- a/drivers/gpu/drm/qxl/qxl_fb.c
> +++ b/drivers/gpu/drm/qxl/qxl_fb.c
> @@ -30,6 +30,7 @@
>  #include "drm/drm.h"
>  #include "drm/drm_crtc.h"
>  #include "drm/drm_crtc_helper.h"
> +#include "drm/drm_rect.h"
>  #include "qxl_drv.h"
>  
>  #include "qxl_object.h"
> @@ -46,15 +47,6 @@ struct qxl_fbdev {
>   struct list_head delayed_ops;
>   void *shadow;
>   int size;
> -
> - /* dirty memory logging */
> - struct {
> - spinlock_t lock;
> - unsigned x1;
> - unsigned y1;
> - unsigned x2;
> - unsigned y2;
> - } dirty;
>  };
>  
>  static void qxl_fb_image_init(struct qxl_fb_image *qxl_fb_image,
> @@ -82,169 +74,18 @@ static void qxl_fb_image_init(struct qxl_fb_ima

[PATCH 5/8] fbdev: fb_defio: Export fb_deferred_io_mmap

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 05:25:26PM +0200, Noralf Trønnes wrote:
> Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
> When the framebuffer memory is allocated using dma_alloc_writecombine()
> instead of vmalloc(), I get cache syncing problems.
> This solves it:
> 
> static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> struct vm_area_struct *vma)
> {
>   fb_deferred_io_mmap(info, vma);
>   vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);

Hm, do we need pgpropt_writecombine? There recently was some discussion
(on the arc platform) that fbdev pgprots need to be fixed up in fbdev
code. I have no idea, just repeating from memory ...
-Daniel

> 
>   return 0;
> }
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/video/fbdev/core/fb_defio.c | 3 ++-
>  include/linux/fb.h  | 1 +
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/core/fb_defio.c 
> b/drivers/video/fbdev/core/fb_defio.c
> index 57721c7..74b5bca 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -164,7 +164,7 @@ static const struct address_space_operations 
> fb_deferred_io_aops = {
>   .set_page_dirty = fb_deferred_io_set_page_dirty,
>  };
>  
> -static int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct 
> *vma)
> +int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
>  {
>   vma->vm_ops = &fb_deferred_io_vm_ops;
>   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
> @@ -173,6 +173,7 @@ static int fb_deferred_io_mmap(struct fb_info *info, 
> struct vm_area_struct *vma)
>   vma->vm_private_data = info;
>   return 0;
>  }
> +EXPORT_SYMBOL(fb_deferred_io_mmap);
>  
>  /* workqueue callback */
>  static void fb_deferred_io_work(struct work_struct *work)
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index dfe8835..a964d07 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -673,6 +673,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
> d_pitch,
>  }
>  
>  /* drivers/video/fb_defio.c */
> +int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
>  extern void fb_deferred_io_init(struct fb_info *info);
>  extern void fb_deferred_io_open(struct fb_info *info,
>   struct inode *inode,
> -- 
> 2.2.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH 2/8] drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 05:25:23PM +0200, Noralf Trønnes wrote:
> Now that drm_fb_helper gets deferred io support, the
> drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
> the worker that calls the deferred_io callback. This will break this
> driver so use the sys_{fillrect,copyarea,imageblit} functions directly.
> 
> Signed-off-by: Noralf Trønnes 

I think this intermediately breaks the build, if you disable fbdev
support. That's now supported in the fbdev helpers core generically across
all drivers.

Not sure how to best fix this up, since the only way would be to squash
these patches, plus generic deferred io plus the conversion patches for
udl/qxl all into one. Tricky.
-Daniel

> ---
>  drivers/gpu/drm/udl/udl_fb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index fd1eb9d..a52de2f 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -287,7 +287,7 @@ static void udl_fb_fillrect(struct fb_info *info, const 
> struct fb_fillrect *rect
>  {
>   struct udl_fbdev *ufbdev = info->par;
>  
> - drm_fb_helper_sys_fillrect(info, rect);
> + sys_fillrect(info, rect);
>  
>   udl_handle_damage(&ufbdev->ufb, rect->dx, rect->dy, rect->width,
> rect->height);
> @@ -297,7 +297,7 @@ static void udl_fb_copyarea(struct fb_info *info, const 
> struct fb_copyarea *regi
>  {
>   struct udl_fbdev *ufbdev = info->par;
>  
> - drm_fb_helper_sys_copyarea(info, region);
> + sys_copyarea(info, region);
>  
>   udl_handle_damage(&ufbdev->ufb, region->dx, region->dy, region->width,
> region->height);
> @@ -307,7 +307,7 @@ static void udl_fb_imageblit(struct fb_info *info, const 
> struct fb_image *image)
>  {
>   struct udl_fbdev *ufbdev = info->par;
>  
> - drm_fb_helper_sys_imageblit(info, image);
> + sys_imageblit(info, image);
>  
>   udl_handle_damage(&ufbdev->ufb, image->dx, image->dy, image->width,
> image->height);
> -- 
> 2.2.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

2016-04-20 Thread Chris Wilson
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: Yishai Hadas 
Cc: Dan Williams 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: David Hildenbrand 
Cc: Luis R. Rodriguez 
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
Cc: netdev at vger.kernel.org
Cc: linux-rdma at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/gpu/drm/i915/intel_overlay.c|  3 ++-
 drivers/net/ethernet/mellanox/mlx4/pd.c |  4 +++-
 include/linux/io-mapping.h  | 10 +++---
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 9746b9841c13..0d5a376878d3 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem 
*)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
-overlay->flip_addr);
+overlay->flip_addr,
+PAGE_SIZE);

return regs;
 }
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c 
b/drivers/net/ethernet/mellanox/mlx4/pd.c
index b3cc3ab63799..6fc156a3918d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, 
int node)
goto free_uar;
}

-   uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << 
PAGE_SHIFT);
+   uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
+   uar->index << PAGE_SHIFT,
+   PAGE_SIZE);
if (!uar->bf_map) {
err = -ENOMEM;
goto unamp_uar;
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e399029b68c5..645ad06b5d52 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
 }

 static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
 {
resource_size_t phys_addr;

BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;

-   return ioremap_wc(phys_addr, PAGE_SIZE);
+   return ioremap_wc(phys_addr, size);
 }

 static inline void
@@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)

 /* Non-atomic map/unmap */
 static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
 {
return ((char __force __iomem *) mapping) + offset;
 }
-- 
2.8.1



[GIT PULL] MT8173 DRM support

2016-04-20 Thread Philipp Zabel
On Wed, Apr 20, 2016 at 7:32 PM, Daniel Vetter  wrote:
> On Wed, Apr 20, 2016 at 09:21:17AM -0700, Eric Anholt wrote:
>> Daniel Vetter  writes:
>>
>> > On Wed, Apr 20, 2016 at 03:36:16PM +0200, Matthias Brugger wrote:
>> >>
>> >>
>> >> On 19/04/16 15:42, Philipp Zabel wrote:
>> >> >Hi Dave,
>> >> >
>> >> >please consider pulling this tag with initial MediaTek MT8173 DRM
>> >> >support, corresponding to v14 of the patch series. These patches have
>> >> >been mostly stable for the last few rounds. I'll follow up with the HDMI
>> >> >encoder support pending review of the latest version.
>> >> >
>> >>
>> >> Please don't pull
>> >> e34ba70de8c4 ("arm64: dts: mt8173: Add display subsystem related nodes")
>> >> If you pull the rest, this patch will go through my branch.
>> >
>> > So not on top of this at all, but do we have to split up arm drm drivers
>> > so much? Generally this stuff goes in through one tree with the driver,
>> > with acks from other subsystem as needed. That ack seems to be missing,
>> > but imo better to supply it and just get this pull req through. Or double
>> > merge a patch, we do that fairly often.
>> >
>> > Anyway just a comment, but sitting outside watching I think arm has a
>> > pretty serious problem with tree proliferation. And it's not helping to
>> > get fairly simple drivers like this one merged ...
>>
>> DT changes do get merged through the arm DT tree separately.  ARM has
>> absurd tree proliferation, but I think in this case it actually makes
>> sense.  DT is the most common place I have merge conflicts when working
>> on platform enabling across the steaming piles of subsystem trees out
>> there, and keeping DT separate means that a merged -next tree can be
>> built sanely.
>
> Ok, makes sense. Still I guess just double-merging in this case would be
> the simplest option. Git should be clever enough in general to realize
> what's going on.
> -Daniel

I have added a new tag without commit e34ba70de8c4
(at mediatek-drm-2016-04-19^1):
git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-04-20
to pull instead.

regards
Philipp


[GIT PULL] MT8173 DRM support

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 09:21:17AM -0700, Eric Anholt wrote:
> Daniel Vetter  writes:
> 
> > On Wed, Apr 20, 2016 at 03:36:16PM +0200, Matthias Brugger wrote:
> >> 
> >> 
> >> On 19/04/16 15:42, Philipp Zabel wrote:
> >> >Hi Dave,
> >> >
> >> >please consider pulling this tag with initial MediaTek MT8173 DRM
> >> >support, corresponding to v14 of the patch series. These patches have
> >> >been mostly stable for the last few rounds. I'll follow up with the HDMI
> >> >encoder support pending review of the latest version.
> >> >
> >> 
> >> Please don't pull
> >> e34ba70de8c4 ("arm64: dts: mt8173: Add display subsystem related nodes")
> >> If you pull the rest, this patch will go through my branch.
> >
> > So not on top of this at all, but do we have to split up arm drm drivers
> > so much? Generally this stuff goes in through one tree with the driver,
> > with acks from other subsystem as needed. That ack seems to be missing,
> > but imo better to supply it and just get this pull req through. Or double
> > merge a patch, we do that fairly often.
> >
> > Anyway just a comment, but sitting outside watching I think arm has a
> > pretty serious problem with tree proliferation. And it's not helping to
> > get fairly simple drivers like this one merged ...
> 
> DT changes do get merged through the arm DT tree separately.  ARM has
> absurd tree proliferation, but I think in this case it actually makes
> sense.  DT is the most common place I have merge conflicts when working
> on platform enabling across the steaming piles of subsystem trees out
> there, and keeping DT separate means that a merged -next tree can be
> built sanely.

Ok, makes sense. Still I guess just double-merging in this case would be
the simplest option. Git should be clever enough in general to realize
what's going on.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

2016-04-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #97 from Jonas  ---
Actually, it sure is annoying to have to change files on every firmware update.
Today's firmware update in Arch Linux broke DPM again. After using firmware
files of 16 october 2015, everything is fine again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/abdb0d27/attachment.html>


[PATCH 2/3] kernel.h: add u64_to_user_ptr()

2016-04-20 Thread Joe Perches
On Wed, 2016-04-20 at 16:18 -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This function had copies in 3 different files. Unify them in kernel.h.
[]
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
[]
> @@ -53,6 +53,12 @@
> 
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>  
> +static inline void __user *u64_to_user_ptr(u64 address)
> +{
> + typecheck(u64, address);
> + return (void __user *)(uintptr_t)address;
> +}
> +

This won't work because by the time address is checked
address is already u64

This would need to be something like

#define u64_to_user_ptr(x)  \
({  \
typecheck(u64, x);  \
u64_to_user_ptr(x); \
})


[GIT PULL] MT8173 DRM support

2016-04-20 Thread Matthias Brugger


On 20/04/16 17:19, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 03:36:16PM +0200, Matthias Brugger wrote:
>>
>>
>> On 19/04/16 15:42, Philipp Zabel wrote:
>>> Hi Dave,
>>>
>>> please consider pulling this tag with initial MediaTek MT8173 DRM
>>> support, corresponding to v14 of the patch series. These patches have
>>> been mostly stable for the last few rounds. I'll follow up with the HDMI
>>> encoder support pending review of the latest version.
>>>
>>
>> Please don't pull
>> e34ba70de8c4 ("arm64: dts: mt8173: Add display subsystem related nodes")
>> If you pull the rest, this patch will go through my branch.
>
> So not on top of this at all, but do we have to split up arm drm drivers
> so much? Generally this stuff goes in through one tree with the driver,
> with acks from other subsystem as needed. That ack seems to be missing,
> but imo better to supply it and just get this pull req through. Or double
> merge a patch, we do that fairly often.
>
> Anyway just a comment, but sitting outside watching I think arm has a
> pretty serious problem with tree proliferation. And it's not helping to
> get fairly simple drivers like this one merged ...
>

Device tree (DTS) patches are not really part of the driver. They are 
part of the SoC/board that has the device. DTS describes the hardware 
that is on the SoC/board.

AFAIK the idea behind splitting that from the rest of the drivers is to 
make the merging easier. If every driver repository has it's own DTS 
entries, then when merging all this repositories into master, you will 
get a merge error in the DTS part on every driver repository. Which most 
probably will drive the maintainer insane.

If instead you have the DTS bits in the arm-soc repository, you can 
easily merge the rest of the drivers.

Regards,
Matthias

> Cheers, Daniel
>
>
>>
>> Regards,
>> Matthias
>>
>>> regards
>>> Philipp
>>>
>>> The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9:
>>>
>>>Linux 4.6-rc2 (2016-04-03 09:09:40 -0500)
>>>
>>> are available in the git repository at:
>>>
>>>git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-04-19
>>>
>>> for you to fetch changes up to e34ba70de8c46a460328a362eece4db6e9b63ec7:
>>>
>>>arm64: dts: mt8173: Add display subsystem related nodes (2016-04-19 
>>> 14:54:42 +0200)
>>>
>>> 
>>> MT8173 DRM support
>>>
>>> - device tree bindings for all MT8173 display subsystem
>>>components
>>> - basic mediatek drm driver for MT8173 with two optional,
>>>currently fixed output paths:
>>> - DSI encoder support for DSI and (via bridge) eDP panels
>>> - DPI encoder support for output to HDMI bridge
>>> - necessary clock tree changes for the DPI->HDMI path
>>>
>>> 
>>> CK Hu (4):
>>>dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
>>>drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
>>>drm/mediatek: Add DSI sub driver
>>>arm64: dts: mt8173: Add display subsystem related nodes
>>>
>>> Jie Qiu (1):
>>>drm/mediatek: Add DPI sub driver
>>>
>>> Philipp Zabel (3):
>>>clk: mediatek: make dpi0_sel propagate rate changes
>>>clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output
>>>clk: mediatek: remove hdmitx_dig_cts from TOP clocks
>>>
>>>   .../bindings/display/mediatek/mediatek,disp.txt| 203 +
>>>   .../bindings/display/mediatek/mediatek,dpi.txt |  35 +
>>>   .../bindings/display/mediatek/mediatek,dsi.txt |  60 ++
>>>   arch/arm64/boot/dts/mediatek/mt8173.dtsi   | 223 +
>>>   drivers/clk/mediatek/clk-mt8173.c  |  12 +-
>>>   drivers/clk/mediatek/clk-mtk.h |  15 +-
>>>   drivers/gpu/drm/Kconfig|   2 +
>>>   drivers/gpu/drm/Makefile   |   1 +
>>>   drivers/gpu/drm/mediatek/Kconfig   |  14 +
>>>   drivers/gpu/drm/mediatek/Makefile  |  14 +
>>>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 302 +++
>>>   drivers/gpu/drm/mediatek/mtk_disp_rdma.c   | 240 ++
>>>   drivers/gpu/drm/mediatek/mtk_dpi.c | 769 +
>>>   drivers/gpu/drm/mediatek/mtk_dpi_regs.h| 228 +
>>>   drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 582 +
>>>   drivers/gpu/drm/mediatek/mtk_drm_crtc.h|  32 +
>>>   drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 355 
>>>   drivers/gpu/drm/mediatek/mtk_drm_ddp.h |  41 +
>>>   drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 225 +
>>>   drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 150 
>>>   drivers/gpu/drm/mediatek/mtk_drm_drv.c | 567 +
>>>   drivers/gpu/drm/mediatek/mtk_drm_drv.h |  59 ++
>>>   drivers/gpu/drm/mediatek/mtk_drm_fb.c  | 165 
>>>  

[PATCH v2 3/4] drm/dsi: Implement set tear scanline

2016-04-20 Thread kbuild test robot
Hi,

[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on v4.6-rc4 next-20160420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Vinay-Simha-BN/dt-bindings-Add-jdi-panel-vendor/20160420-173456
base:   git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: x86_64-randconfig-x012-201616 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/linkage.h:6:0,
from include/linux/kernel.h:6,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/drm/drm_mipi_dsi.h:15,
from drivers/gpu/drm/drm_mipi_dsi.c:28:
>> drivers/gpu/drm/drm_mipi_dsi.c:1006:15: error: 
>> 'mipi_dsi_dcs_set_tear_scanline' undeclared here (not in a function)
EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_scanline);
  ^
   include/linux/export.h:57:16: note: in definition of macro '__EXPORT_SYMBOL'
 extern typeof(sym) sym; \
   ^
>> drivers/gpu/drm/drm_mipi_dsi.c:1006:1: note: in expansion of macro 
>> 'EXPORT_SYMBOL'
EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_scanline);
^

vim +/mipi_dsi_dcs_set_tear_scanline +1006 drivers/gpu/drm/drm_mipi_dsi.c

  1000  err = mipi_dsi_generic_write(dsi, &payload, sizeof(payload));
  1001  if (err < 0)
  1002  return err;
  1003  
  1004  return 0;
  1005  }
> 1006  EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_scanline);
  1007  /**
  1008   * mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB 
image
  1009   *data used by the interface

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 24624 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/3d506555/attachment-0001.obj>


[PATCH 8/8] drm/udl: Use drm_fb_helper deferred_io support

2016-04-20 Thread Noralf Trønnes
Use the fbdev deferred io support in drm_fb_helper.
The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
now be deferred in the same way that mmap damage is, instead of being
flushed directly.
The deferred mmap functionality is kept disabled by default, because of the
list corruption problems mentioned in commit 677d23b70bf9
("drm/udl: disable fb_defio by default").
This patch has only been compile tested.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/udl/udl_drv.h |   2 -
 drivers/gpu/drm/udl/udl_fb.c  | 152 --
 2 files changed, 12 insertions(+), 142 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 4a064ef..0b03d34 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -81,8 +81,6 @@ struct udl_framebuffer {
struct drm_framebuffer base;
struct udl_gem_object *obj;
bool active_16; /* active on the 16-bit channel */
-   int x1, y1, x2, y2; /* dirty rect */
-   spinlock_t dirty_lock;
 };

 #define to_udl_fb(x) container_of(x, struct udl_framebuffer, base)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index a52de2f..b44d4a7 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -77,68 +77,6 @@ static uint16_t rgb16(uint32_t col)
 }
 #endif

-/*
- * NOTE: fb_defio.c is holding info->fbdefio.mutex
- *   Touching ANY framebuffer memory that triggers a page fault
- *   in fb_defio will cause a deadlock, when it also tries to
- *   grab the same mutex.
- */
-static void udlfb_dpy_deferred_io(struct fb_info *info,
- struct list_head *pagelist)
-{
-   struct page *cur;
-   struct fb_deferred_io *fbdefio = info->fbdefio;
-   struct udl_fbdev *ufbdev = info->par;
-   struct drm_device *dev = ufbdev->ufb.base.dev;
-   struct udl_device *udl = dev->dev_private;
-   struct urb *urb;
-   char *cmd;
-   cycles_t start_cycles, end_cycles;
-   int bytes_sent = 0;
-   int bytes_identical = 0;
-   int bytes_rendered = 0;
-
-   if (!fb_defio)
-   return;
-
-   start_cycles = get_cycles();
-
-   urb = udl_get_urb(dev);
-   if (!urb)
-   return;
-
-   cmd = urb->transfer_buffer;
-
-   /* walk the written page list and render each to device */
-   list_for_each_entry(cur, &fbdefio->pagelist, lru) {
-
-   if (udl_render_hline(dev, (ufbdev->ufb.base.bits_per_pixel / 8),
-&urb, (char *) info->fix.smem_start,
-&cmd, cur->index << PAGE_SHIFT,
-cur->index << PAGE_SHIFT,
-PAGE_SIZE, &bytes_identical, &bytes_sent))
-   goto error;
-   bytes_rendered += PAGE_SIZE;
-   }
-
-   if (cmd > (char *) urb->transfer_buffer) {
-   /* Send partial buffer remaining before exiting */
-   int len = cmd - (char *) urb->transfer_buffer;
-   udl_submit_urb(dev, urb, len);
-   bytes_sent += len;
-   } else
-   udl_urb_completion(urb);
-
-error:
-   atomic_add(bytes_sent, &udl->bytes_sent);
-   atomic_add(bytes_identical, &udl->bytes_identical);
-   atomic_add(bytes_rendered, &udl->bytes_rendered);
-   end_cycles = get_cycles();
-   atomic_add(((unsigned int) ((end_cycles - start_cycles)
-   >> 10)), /* Kcycles */
-  &udl->cpu_kcycles_used);
-}
-
 int udl_handle_damage(struct udl_framebuffer *fb, int x, int y,
  int width, int height)
 {
@@ -152,9 +90,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, int 
y,
struct urb *urb;
int aligned_x;
int bpp = (fb->base.bits_per_pixel / 8);
-   int x2, y2;
-   bool store_for_later = false;
-   unsigned long flags;

if (!fb->active_16)
return 0;
@@ -180,38 +115,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
(y + height > fb->base.height))
return -EINVAL;

-   /* if we are in atomic just store the info
-  can't test inside spin lock */
-   if (in_atomic())
-   store_for_later = true;
-
-   x2 = x + width - 1;
-   y2 = y + height - 1;
-
-   spin_lock_irqsave(&fb->dirty_lock, flags);
-
-   if (fb->y1 < y)
-   y = fb->y1;
-   if (fb->y2 > y2)
-   y2 = fb->y2;
-   if (fb->x1 < x)
-   x = fb->x1;
-   if (fb->x2 > x2)
-   x2 = fb->x2;
-
-   if (store_for_later) {
-   fb->x1 = x;
-   fb->x2 = x2;
-   fb->y1 = y;
-   fb->y2 = y2;
-   spin_unlock_irqrestore(&fb->dirty_lock, flags);
-   return 0;
-   }
-
-   fb->x1 = fb->y1 = INT_MAX;
-   fb->x2 = fb-

[PATCH 7/8] drm/qxl: Use drm_fb_helper deferred_io support

2016-04-20 Thread Noralf Trønnes
Use the fbdev deferred io support in drm_fb_helper.
The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
now be deferred in the same way that mmap damage is, instead of being
flushed directly.
This patch has only been compile tested.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/qxl/qxl_display.c |   9 +-
 drivers/gpu/drm/qxl/qxl_drv.h |   7 +-
 drivers/gpu/drm/qxl/qxl_fb.c  | 220 ++
 drivers/gpu/drm/qxl/qxl_kms.c |   4 -
 4 files changed, 62 insertions(+), 178 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 030409a..9a03524 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -465,7 +465,7 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
.page_flip = qxl_crtc_page_flip,
 };

-static void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
+void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
 {
struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);

@@ -527,12 +527,13 @@ int
 qxl_framebuffer_init(struct drm_device *dev,
 struct qxl_framebuffer *qfb,
 const struct drm_mode_fb_cmd2 *mode_cmd,
-struct drm_gem_object *obj)
+struct drm_gem_object *obj,
+const struct drm_framebuffer_funcs *funcs)
 {
int ret;

qfb->obj = obj;
-   ret = drm_framebuffer_init(dev, &qfb->base, &qxl_fb_funcs);
+   ret = drm_framebuffer_init(dev, &qfb->base, funcs);
if (ret) {
qfb->obj = NULL;
return ret;
@@ -999,7 +1000,7 @@ qxl_user_framebuffer_create(struct drm_device *dev,
if (qxl_fb == NULL)
return NULL;

-   ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj);
+   ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj, &qxl_fb_funcs);
if (ret) {
kfree(qxl_fb);
drm_gem_object_unreference_unlocked(obj);
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 3f3897e..3ad6604 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -324,8 +324,6 @@ struct qxl_device {
struct workqueue_struct *gc_queue;
struct work_struct gc_work;

-   struct work_struct fb_work;
-
struct drm_property *hotplug_mode_update_property;
int monitors_config_width;
int monitors_config_height;
@@ -389,11 +387,13 @@ int qxl_get_handle_for_primary_fb(struct qxl_device *qdev,
 void qxl_fbdev_set_suspend(struct qxl_device *qdev, int state);

 /* qxl_display.c */
+void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb);
 int
 qxl_framebuffer_init(struct drm_device *dev,
 struct qxl_framebuffer *rfb,
 const struct drm_mode_fb_cmd2 *mode_cmd,
-struct drm_gem_object *obj);
+struct drm_gem_object *obj,
+const struct drm_framebuffer_funcs *funcs);
 void qxl_display_read_client_monitors_config(struct qxl_device *qdev);
 void qxl_send_monitors_config(struct qxl_device *qdev);
 int qxl_create_monitors_object(struct qxl_device *qdev);
@@ -553,7 +553,6 @@ int qxl_irq_init(struct qxl_device *qdev);
 irqreturn_t qxl_irq_handler(int irq, void *arg);

 /* qxl_fb.c */
-int qxl_fb_init(struct qxl_device *qdev);
 bool qxl_fbdev_qobj_is_fb(struct qxl_device *qdev, struct qxl_bo *qobj);

 int qxl_debugfs_add_files(struct qxl_device *qdev,
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 06f032d..090dcee 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -30,6 +30,7 @@
 #include "drm/drm.h"
 #include "drm/drm_crtc.h"
 #include "drm/drm_crtc_helper.h"
+#include "drm/drm_rect.h"
 #include "qxl_drv.h"

 #include "qxl_object.h"
@@ -46,15 +47,6 @@ struct qxl_fbdev {
struct list_head delayed_ops;
void *shadow;
int size;
-
-   /* dirty memory logging */
-   struct {
-   spinlock_t lock;
-   unsigned x1;
-   unsigned y1;
-   unsigned x2;
-   unsigned y2;
-   } dirty;
 };

 static void qxl_fb_image_init(struct qxl_fb_image *qxl_fb_image,
@@ -82,169 +74,18 @@ static void qxl_fb_image_init(struct qxl_fb_image 
*qxl_fb_image,
}
 }

-static void qxl_fb_dirty_flush(struct fb_info *info)
-{
-   struct qxl_fbdev *qfbdev = info->par;
-   struct qxl_device *qdev = qfbdev->qdev;
-   struct qxl_fb_image qxl_fb_image;
-   struct fb_image *image = &qxl_fb_image.fb_image;
-   unsigned long flags;
-   u32 x1, x2, y1, y2;
-
-   /* TODO: hard coding 32 bpp */
-   int stride = qfbdev->qfb.base.pitches[0];
-
-   spin_lock_irqsave(&qfbdev->dirty.lock, flags);
-
-   x1 = qfbdev->dirty.x1;
-   x2 = qfbdev->dirty.x2;
-   y1 = qfbdev->dirty.y1;
-   y2 = qfbdev->dirty.y2;

[PATCH 6/8] drm/fb-cma-helper: Add fb_deferred_io support

2016-04-20 Thread Noralf Trønnes
This adds fbdev deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
The driver has to provide a (struct drm_framebuffer_funcs *)->dirty()
callback to get notification of fbdev framebuffer changes.
If the dirty() hook is set, then fb_deferred_io is set up automatically
by the helper.

Two functions have been added so that the driver can provide a dirty()
function:
- drm_fbdev_cma_init_with_funcs()
  This makes it possible for the driver to provided a custom
  (struct drm_fb_helper_funcs *)->fb_probe() function.
- drm_fbdev_cma_create_with_funcs()
  This is used by the .fb_probe hook to set a driver provided
  (struct drm_framebuffer_funcs *)->dirty() function.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 190 +---
 include/drm/drm_fb_cma_helper.h |  14 +++
 2 files changed, 192 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index bb88e3d..d1e9db0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -25,6 +25,8 @@
 #include 
 #include 

+#define DEFAULT_FBDEFIO_DELAY_MS 50
+
 struct drm_fb_cma {
struct drm_framebuffer  fb;
struct drm_gem_cma_object   *obj[4];
@@ -35,6 +37,61 @@ struct drm_fbdev_cma {
struct drm_fb_cma   *fb;
 };

+/**
+ * DOC: framebuffer cma helper functions
+ *
+ * Provides helper functions for creating a cma (contiguous memory allocator)
+ * backed framebuffer.
+ *
+ * drm_fb_cma_create() is used in the
+ * (struct drm_mode_config_funcs *)->fb_create callback function to create the
+ * cma backed framebuffer.
+ *
+ * An fbdev framebuffer backed by cma is also available by calling
+ * drm_fbdev_cma_init(). drm_fbdev_cma_fini() tears it down.
+ * If CONFIG_FB_DEFERRED_IO is enabled and the callback
+ * (struct drm_framebuffer_funcs)->dirty is set, fb_deferred_io
+ * will be set up automatically. dirty() is called by
+ * drm_fb_helper_deferred_io() in process context (struct delayed_work).
+ *
+ * Example fbdev deferred io code:
+ *
+ * static int driver_fbdev_fb_dirty(struct drm_framebuffer *fb,
+ *  struct drm_file *file_priv,
+ *  unsigned flags, unsigned color,
+ *  struct drm_clip_rect *clips,
+ *  unsigned num_clips)
+ * {
+ * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
+ * ... push changes ...
+ * return 0;
+ * }
+ *
+ * static struct drm_framebuffer_funcs driver_fbdev_fb_funcs = {
+ * .destroy   = drm_fb_cma_destroy,
+ * .create_handle = drm_fb_cma_create_handle,
+ * .dirty = driver_fbdev_fb_dirty,
+ * };
+ *
+ * static int driver_fbdev_create(struct drm_fb_helper *helper,
+ * struct drm_fb_helper_surface_size *sizes)
+ * {
+ * return drm_fbdev_cma_create_with_funcs(helper, sizes,
+ *&driver_fbdev_fb_funcs);
+ * }
+ *
+ * static const struct drm_fb_helper_funcs driver_fb_helper_funcs = {
+ * .fb_probe = driver_fbdev_create,
+ * };
+ *
+ * Initialize:
+ * fbdev = drm_fbdev_cma_init_with_funcs(dev, 16,
+ *   dev->mode_config.num_crtc,
+ *   dev->mode_config.num_connector,
+ *   &driver_fb_helper_funcs);
+ *
+ */
+
 static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
 {
return container_of(helper, struct drm_fbdev_cma, fb_helper);
@@ -45,7 +102,7 @@ static inline struct drm_fb_cma *to_fb_cma(struct 
drm_framebuffer *fb)
return container_of(fb, struct drm_fb_cma, fb);
 }

-static void drm_fb_cma_destroy(struct drm_framebuffer *fb)
+void drm_fb_cma_destroy(struct drm_framebuffer *fb)
 {
struct drm_fb_cma *fb_cma = to_fb_cma(fb);
int i;
@@ -58,8 +115,9 @@ static void drm_fb_cma_destroy(struct drm_framebuffer *fb)
drm_framebuffer_cleanup(fb);
kfree(fb_cma);
 }
+EXPORT_SYMBOL(drm_fb_cma_destroy);

-static int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
+int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
struct drm_file *file_priv, unsigned int *handle)
 {
struct drm_fb_cma *fb_cma = to_fb_cma(fb);
@@ -67,6 +125,7 @@ static int drm_fb_cma_create_handle(struct drm_framebuffer 
*fb,
return drm_gem_handle_create(file_priv,
&fb_cma->obj[0]->base, handle);
 }
+EXPORT_SYMBOL(drm_fb_cma_create_handle);

 static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
.destroy= drm_fb_cma_destroy,
@@ -76,7 +135,7 @@ static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
 static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,
const struct drm_mode_fb_cmd2 

[PATCH 5/8] fbdev: fb_defio: Export fb_deferred_io_mmap

2016-04-20 Thread Noralf Trønnes
Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
When the framebuffer memory is allocated using dma_alloc_writecombine()
instead of vmalloc(), I get cache syncing problems.
This solves it:

static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
  struct vm_area_struct *vma)
{
fb_deferred_io_mmap(info, vma);
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);

return 0;
}

Signed-off-by: Noralf Trønnes 
---
 drivers/video/fbdev/core/fb_defio.c | 3 ++-
 include/linux/fb.h  | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fb_defio.c 
b/drivers/video/fbdev/core/fb_defio.c
index 57721c7..74b5bca 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -164,7 +164,7 @@ static const struct address_space_operations 
fb_deferred_io_aops = {
.set_page_dirty = fb_deferred_io_set_page_dirty,
 };

-static int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct 
*vma)
+int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
 {
vma->vm_ops = &fb_deferred_io_vm_ops;
vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
@@ -173,6 +173,7 @@ static int fb_deferred_io_mmap(struct fb_info *info, struct 
vm_area_struct *vma)
vma->vm_private_data = info;
return 0;
 }
+EXPORT_SYMBOL(fb_deferred_io_mmap);

 /* workqueue callback */
 static void fb_deferred_io_work(struct work_struct *work)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index dfe8835..a964d07 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -673,6 +673,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
d_pitch,
 }

 /* drivers/video/fb_defio.c */
+int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
 extern void fb_deferred_io_init(struct fb_info *info);
 extern void fb_deferred_io_open(struct fb_info *info,
struct inode *inode,
-- 
2.2.2



[PATCH 4/8] drm/fb-helper: Add fb_deferred_io support

2016-04-20 Thread Noralf Trønnes
This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
Accumulated fbdev framebuffer changes are signaled using the callback
(struct drm_framebuffer_funcs *)->dirty()

The drm_fb_helper_sys_*() functions will accumulate changes and
schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
This worker is used by the deferred io mmap code to signal that it
has been collecting page faults. The page faults and/or other changes
are then merged into a drm_clip_rect and passed to the framebuffer
dirty() function.

The driver is responsible for setting up the fb_info.fbdefio structure
and calling fb_deferred_io_init() using the provided callback:
(struct fb_deferred_io).deferred_io = drm_fb_helper_deferred_io;

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 119 +++-
 include/drm/drm_fb_helper.h |  15 +
 2 files changed, 133 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 855108e..79c974a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 

 static bool drm_fbdev_emulation = true;
 module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
@@ -48,6 +49,9 @@ MODULE_PARM_DESC(fbdev_emulation,

 static LIST_HEAD(kernel_fb_helper_list);

+static void drm_fb_helper_defer_dirty(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height);
+
 /**
  * DOC: fbdev helpers
  *
@@ -84,6 +88,13 @@ static LIST_HEAD(kernel_fb_helper_list);
  * and set up an initial configuration using the detected hardware, drivers
  * should call drm_fb_helper_single_add_all_connectors() followed by
  * drm_fb_helper_initial_config().
+ *
+ * If CONFIG_FB_DEFERRED_IO is enabled and (struct fb_info).fbdefio is set,
+ * the drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functions
+ * will accumulate changes and schedule (struct fb_info).deferred_work to run.
+ * This is the same worker used by the mmap deferred io code path.
+ * drm_fb_helper_deferred_io() will call
+ * (struct drm_framebuffer_funcs)->dirty().
  */

 /**
@@ -401,11 +412,14 @@ backoff:
 static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
 {
struct drm_device *dev = fb_helper->dev;
+   struct fb_info *info = fb_helper->fbdev;
struct drm_plane *plane;
int i;

drm_warn_on_modeset_not_all_locked(dev);

+   drm_fb_helper_defer_dirty(info, 0, 0, info->var.xres, info->var.yres);
+
if (fb_helper->atomic)
return restore_fbdev_mode_atomic(fb_helper);

@@ -650,6 +664,9 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct 
drm_fb_helper *helper,
   const struct drm_fb_helper_funcs *funcs)
 {
INIT_LIST_HEAD(&helper->kernel_fb_list);
+#ifdef CONFIG_FB_DEFERRED_IO
+   spin_lock_init(&helper->dirty_lock);
+#endif
helper->funcs = funcs;
helper->dev = dev;
 }
@@ -834,6 +851,87 @@ void drm_fb_helper_unlink_fbi(struct drm_fb_helper 
*fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_unlink_fbi);

+#ifdef CONFIG_FB_DEFERRED_IO
+/**
+ * drm_fb_helper_deferred_io() - (struct fb_deferred_io *)->deferred_io 
callback
+ *   function
+ *
+ * This function always runs in process context (struct delayed_work) and calls
+ * the (struct drm_framebuffer_funcs)->dirty function with the collected
+ * damage. There's no need to worry about the possibility that the fb_sys_*()
+ * functions could be running in atomic context. They only schedule the
+ * delayed worker which then calls this deferred_io callback.
+ */
+void drm_fb_helper_deferred_io(struct fb_info *info,
+  struct list_head *pagelist)
+{
+   struct drm_fb_helper *helper = info->par;
+   unsigned long start, end, min, max;
+   struct drm_clip_rect clip;
+   unsigned long flags;
+   struct page *page;
+
+   if (!helper->fb->funcs->dirty)
+   return;
+
+   spin_lock_irqsave(&helper->dirty_lock, flags);
+   clip = helper->dirty_clip;
+   drm_clip_rect_reset(&helper->dirty_clip);
+   spin_unlock_irqrestore(&helper->dirty_lock, flags);
+
+   min = ULONG_MAX;
+   max = 0;
+   list_for_each_entry(page, pagelist, lru) {
+   start = page->index << PAGE_SHIFT;
+   end = start + PAGE_SIZE - 1;
+   min = min(min, start);
+   max = max(max, end);
+   }
+
+   if (min < max) {
+   struct drm_clip_rect mmap_clip;
+
+   mmap_clip.x1 = 0;
+   mmap_clip.x2 = info->var.xres;
+   mmap_clip.y1 = min / info->fix.line_length;
+   mmap_clip.y2 = min_t(u32, max / info->fix.line_length,
+info->var.yres);
+   drm_clip_rect_merge(&clip, &mmap_clip, 1, 0, 0, 0);
+   }
+
+   if

[PATCH 3/8] drm/qxl: Change drm_fb_helper_sys_*() calls to sys_*()

2016-04-20 Thread Noralf Trønnes
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
the worker that calls the deferred_io callback. This will break this
driver so use the sys_{fillrect,copyarea,imageblit} functions directly.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/qxl/qxl_fb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 7136e52..06f032d 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -199,7 +199,7 @@ static void qxl_fb_fillrect(struct fb_info *info,
 {
struct qxl_fbdev *qfbdev = info->par;

-   drm_fb_helper_sys_fillrect(info, rect);
+   sys_fillrect(info, rect);
qxl_dirty_update(qfbdev, rect->dx, rect->dy, rect->width,
 rect->height);
 }
@@ -209,7 +209,7 @@ static void qxl_fb_copyarea(struct fb_info *info,
 {
struct qxl_fbdev *qfbdev = info->par;

-   drm_fb_helper_sys_copyarea(info, area);
+   sys_copyarea(info, area);
qxl_dirty_update(qfbdev, area->dx, area->dy, area->width,
 area->height);
 }
@@ -219,7 +219,7 @@ static void qxl_fb_imageblit(struct fb_info *info,
 {
struct qxl_fbdev *qfbdev = info->par;

-   drm_fb_helper_sys_imageblit(info, image);
+   sys_imageblit(info, image);
qxl_dirty_update(qfbdev, image->dx, image->dy, image->width,
 image->height);
 }
-- 
2.2.2



[PATCH 2/8] drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()

2016-04-20 Thread Noralf Trønnes
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
the worker that calls the deferred_io callback. This will break this
driver so use the sys_{fillrect,copyarea,imageblit} functions directly.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/udl/udl_fb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index fd1eb9d..a52de2f 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -287,7 +287,7 @@ static void udl_fb_fillrect(struct fb_info *info, const 
struct fb_fillrect *rect
 {
struct udl_fbdev *ufbdev = info->par;

-   drm_fb_helper_sys_fillrect(info, rect);
+   sys_fillrect(info, rect);

udl_handle_damage(&ufbdev->ufb, rect->dx, rect->dy, rect->width,
  rect->height);
@@ -297,7 +297,7 @@ static void udl_fb_copyarea(struct fb_info *info, const 
struct fb_copyarea *regi
 {
struct udl_fbdev *ufbdev = info->par;

-   drm_fb_helper_sys_copyarea(info, region);
+   sys_copyarea(info, region);

udl_handle_damage(&ufbdev->ufb, region->dx, region->dy, region->width,
  region->height);
@@ -307,7 +307,7 @@ static void udl_fb_imageblit(struct fb_info *info, const 
struct fb_image *image)
 {
struct udl_fbdev *ufbdev = info->par;

-   drm_fb_helper_sys_imageblit(info, image);
+   sys_imageblit(info, image);

udl_handle_damage(&ufbdev->ufb, image->dx, image->dy, image->width,
  image->height);
-- 
2.2.2



[PATCH 1/8] drm/rect: Add some drm_clip_rect utility functions

2016-04-20 Thread Noralf Trønnes
Add some utility functions for struct drm_clip_rect.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_rect.c | 67 
 include/drm/drm_rect.h | 69 ++
 2 files changed, 136 insertions(+)

diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index a8e2c86..a9fb1a8 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -434,3 +434,70 @@ void drm_rect_rotate_inv(struct drm_rect *r,
}
 }
 EXPORT_SYMBOL(drm_rect_rotate_inv);
+
+/**
+ * drm_clip_rect_intersect - intersect two clip rectangles
+ * @r1: first clip rectangle
+ * @r2: second clip rectangle
+ *
+ * Calculate the intersection of clip rectangles @r1 and @r2.
+ * @r1 will be overwritten with the intersection.
+ *
+ * RETURNS:
+ * %true if rectangle @r1 is still visible after the operation,
+ * %false otherwise.
+ */
+bool drm_clip_rect_intersect(struct drm_clip_rect *r1,
+const struct drm_clip_rect *r2)
+{
+   r1->x1 = max(r1->x1, r2->x1);
+   r1->y1 = max(r1->y1, r2->y1);
+   r1->x2 = min(r1->x2, r2->x2);
+   r1->y2 = min(r1->y2, r2->y2);
+
+   return drm_clip_rect_visible(r1);
+}
+EXPORT_SYMBOL(drm_clip_rect_intersect);
+
+/**
+ * drm_clip_rect_merge - Merge clip rectangles
+ * @dst: destination clip rectangle
+ * @src: source clip rectangle(s), can be NULL
+ * @num_clips: number of source clip rectangles
+ * @flags: drm_mode_fb_dirty_cmd flags (DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
+ * @width: width of clip rectangle if @src is NULL
+ * @height: height of clip rectangle if @src is NULL
+ *
+ * The dirtyfb ioctl allows for a NULL clip rectangle to be passed in,
+ * so if @src is NULL, width and height is used to set a full clip rectangle.
+ * @dst takes part in the merge unless it is empty {0,0,0,0}.
+ */
+void drm_clip_rect_merge(struct drm_clip_rect *dst,
+struct drm_clip_rect *src, unsigned num_clips,
+unsigned flags, u32 width, u32 height)
+{
+   int i;
+
+   if (!src || !num_clips) {
+   dst->x1 = 0;
+   dst->x2 = width;
+   dst->y1 = 0;
+   dst->y2 = height;
+   return;
+   }
+
+   if (drm_clip_rect_is_empty(dst)) {
+   dst->x1 = ~0;
+   dst->y1 = ~0;
+   }
+
+   for (i = 0; i < num_clips; i++) {
+   if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
+   i++;
+   dst->x1 = min(dst->x1, src[i].x1);
+   dst->x2 = max(dst->x2, src[i].x2);
+   dst->y1 = min(dst->y1, src[i].y1);
+   dst->y2 = max(dst->y2, src[i].y2);
+   }
+}
+EXPORT_SYMBOL(drm_clip_rect_merge);
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 83bb156..936ad8d 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -24,6 +24,8 @@
 #ifndef DRM_RECT_H
 #define DRM_RECT_H

+#include 
+
 /**
  * DOC: rect utils
  *
@@ -171,4 +173,71 @@ void drm_rect_rotate_inv(struct drm_rect *r,
 int width, int height,
 unsigned int rotation);

+/**
+ * drm_clip_rect_width - determine the clip rectangle width
+ * @r: clip rectangle whose width is returned
+ *
+ * RETURNS:
+ * The width of the clip rectangle.
+ */
+static inline int drm_clip_rect_width(const struct drm_clip_rect *r)
+{
+   return r->x2 - r->x1;
+}
+
+/**
+ * drm_clip_rect_height - determine the clip rectangle height
+ * @r: clip rectangle whose height is returned
+ *
+ * RETURNS:
+ * The height of the clip rectangle.
+ */
+static inline int drm_clip_rect_height(const struct drm_clip_rect *r)
+{
+   return r->y2 - r->y1;
+}
+
+/**
+ * drm_clip_rect_visible - determine if the the clip rectangle is visible
+ * @r: clip rectangle whose visibility is returned
+ *
+ * RETURNS:
+ * %true if the clip rectangle is visible, %false otherwise.
+ */
+static inline bool drm_clip_rect_visible(const struct drm_clip_rect *r)
+{
+   return drm_clip_rect_width(r) > 0 && drm_clip_rect_height(r) > 0;
+}
+
+/**
+ * drm_clip_rect_reset - Reset clip rectangle
+ * @clip: clip rectangle
+ *
+ * Sets clip rectangle to {0,0,0,0}.
+ */
+static inline void drm_clip_rect_reset(struct drm_clip_rect *clip)
+{
+   clip->x1 = 0;
+   clip->x2 = 0;
+   clip->y1 = 0;
+   clip->y2 = 0;
+}
+
+/**
+ * drm_clip_rect_is_empty - Is clip rectangle empty?
+ * @clip: clip rectangle
+ *
+ * Returns true if clip rectangle is {0,0,0,0}.
+ */
+static inline bool drm_clip_rect_is_empty(struct drm_clip_rect *clip)
+{
+   return (!clip->x1 && !clip->x2 && !clip->y1 && !clip->y2);
+}
+
+bool drm_clip_rect_intersect(struct drm_clip_rect *r1,
+const struct drm_clip_rect *r2);
+void drm_clip_rect_merge(struct drm_clip_rect *dst,
+struct drm_clip_rect *src, unsigned num_clips,
+unsigned flags, u32 width

[PATCH 0/8] drm: Add fbdev deferred io support to helpers

2016-04-20 Thread Noralf Trønnes
This patchset adds fbdev deferred io support to drm_fb_helper and
drm_fb_cma_helper.

It defers fbdev mmap and fb_{write,fillrect,copyarea,imageblit} damage and
channels it through the (struct drm_framebuffer_funcs)->dirty callback on
the fb_helper framebuffer which will always run in process context.

I have also added patches that converts qxl and udl to use this
deferred io support. I have only compile tested it, no functional testing.
I know that qxl is purely a software thing so I could actually test it, but
I have never used qemu so I'm not keen on spending a lot of time on that.

This was originally part of the tinydrm patchset.

Changes since RFC:
- Fix drm_clip_rect use to be exclusive on x2/y2
- Put drm_clip_rect functions in drm_rect.{h,c}
- Take into account that (struct fb_ops *)->fb_{write,...}() can be called
  from atomic context (spin_lock_irqsave)
- Export fb_deferred_io_mmap()
- Add some more documentation
- Add qxl and udl patches

Noralf Trønnes (8):
  drm/rect: Add some drm_clip_rect utility functions
  drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()
  drm/qxl: Change drm_fb_helper_sys_*() calls to sys_*()
  drm/fb-helper: Add fb_deferred_io support
  fbdev: fb_defio: Export fb_deferred_io_mmap
  drm/fb-cma-helper: Add fb_deferred_io support
  drm/qxl: Use drm_fb_helper deferred_io support
  drm/udl: Use drm_fb_helper deferred_io support

 drivers/gpu/drm/drm_fb_cma_helper.c | 190 +--
 drivers/gpu/drm/drm_fb_helper.c | 119 ++-
 drivers/gpu/drm/drm_rect.c  |  67 +++
 drivers/gpu/drm/qxl/qxl_display.c   |   9 +-
 drivers/gpu/drm/qxl/qxl_drv.h   |   7 +-
 drivers/gpu/drm/qxl/qxl_fb.c| 220 +---
 drivers/gpu/drm/qxl/qxl_kms.c   |   4 -
 drivers/gpu/drm/udl/udl_drv.h   |   2 -
 drivers/gpu/drm/udl/udl_fb.c| 152 ++---
 drivers/video/fbdev/core/fb_defio.c |   3 +-
 include/drm/drm_fb_cma_helper.h |  14 +++
 include/drm/drm_fb_helper.h |  15 +++
 include/drm/drm_rect.h  |  69 +++
 include/linux/fb.h  |   1 +
 14 files changed, 538 insertions(+), 334 deletions(-)

--
2.2.2



[PATCH] drm: Fix compilation on systems that don't provide O_CLOEXEC

2016-04-20 Thread Stefan Dirsch
On Wed, Apr 20, 2016 at 04:47:20PM +0200, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 4:39 PM, Stefan Dirsch  wrote:
> > Patch suggestion by Thomas Klausner. See also
> > http://mail-index.netbsd.org/pkgsrc-changes/2012/08/13/msg076887.html
> >
> > Signed-off-by: Stefan Dirsch 
> 
> Fix your OS to have O_CLOEXEC semantics I think is what should happen
> here. It's an obvious race in multi-threaded apps, and you need a fix
> for it anyway.
> -Daniel

Indeed I figured out the patch is no longer needed and finally removed it. ;-)

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---


[RFC v2 1/8] drm/fb-helper: Add fb_deferred_io support

2016-04-20 Thread Noralf Trønnes

Den 20.04.2016 13:12, skrev Daniel Vetter:
> On Mon, Apr 18, 2016 at 05:15:03PM +0200, Noralf Trønnes wrote:
>> Den 13.04.2016 13:09, skrev Daniel Vetter:
>>> On Fri, Apr 08, 2016 at 07:05:03PM +0200, Noralf Trønnes wrote:
 This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
 Accumulated fbdev framebuffer changes are signaled using the callback
 (struct drm_framebuffer_funcs *)->dirty()

 The drm_fb_helper_sys_*() functions will accumulate changes and
 schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
 This worker is used by the deferred io mmap code to signal that it
 has been collecting page faults. The page faults and/or other changes
 are then merged into a drm_clip_rect and passed to the framebuffer
 dirty() function.

 The driver is responsible for setting up the fb_info.fbdefio structure
 and calling fb_deferred_io_init() using the provided callback:
 (struct fb_info *)->fbdefio->deferred_io = drm_fb_helper_deferred_io;

 Signed-off-by: Noralf Trønnes 
>>> For this one it'd be awesome to throw patches for qxl/udl on top to remove
>>> their own hand-rolled implementations. Just to maximize the testing
>>> coverage of this new code. Should be doable to set up a qxl virtual
>>> machine quickly, but even without that we should be able to pull it in
>>> (since it's mostly just about removing code from these two drivers).
>> There are three fb_deferred_io users in drivers/gpu/drm: qxl, udl and
>> vmwgfx.
>>
>> drivers/gpu/drm/vmwgfx
>> It doesn't use drm_fb_helper (uses the cfb_{fillrect,copyarea,imageblit}
>> functions directly). This made me think that I should probably add
>> fb_deferred_io support to drm_fb_helper_cfb_*() as well.
> Yup, that one is special and can be ignored.
>
>> drivers/gpu/drm/udl
>> First of all it has had deferred io disabled by default since 2013
>> (commit 677d23b). Secondly it handles damage directly in it's
>> fb_{fillrect,copyarea,imageblit} functions, but defers to the next call if
>> it is in atomic context. My patch always defers those function to a worker.
>> The driver uses the drm_fb_helper_sys_* functions, so my patch would mess
>> it up if someone would enable deferred io (module_param: fb_defio).
>> So this driver isn't a good candidate for easy conversion also because it
>> has different code paths for fbdev mmap damage and the other damages
>> (although the code is similar). But it needs a patch to use the sys_*()
>> functions directly.
> Since it's disabled by default I'd just do a conversion. It should result
> largely in deleting code and just using the fb helpers. What's special
> with the mmap handling, and do we care?

The git log mentions page list corruption, but I realised that I can
just disable the deferred mmap code and keep the rest.



[GIT PULL] MT8173 DRM support

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 03:36:16PM +0200, Matthias Brugger wrote:
> 
> 
> On 19/04/16 15:42, Philipp Zabel wrote:
> >Hi Dave,
> >
> >please consider pulling this tag with initial MediaTek MT8173 DRM
> >support, corresponding to v14 of the patch series. These patches have
> >been mostly stable for the last few rounds. I'll follow up with the HDMI
> >encoder support pending review of the latest version.
> >
> 
> Please don't pull
> e34ba70de8c4 ("arm64: dts: mt8173: Add display subsystem related nodes")
> If you pull the rest, this patch will go through my branch.

So not on top of this at all, but do we have to split up arm drm drivers
so much? Generally this stuff goes in through one tree with the driver,
with acks from other subsystem as needed. That ack seems to be missing,
but imo better to supply it and just get this pull req through. Or double
merge a patch, we do that fairly often.

Anyway just a comment, but sitting outside watching I think arm has a
pretty serious problem with tree proliferation. And it's not helping to
get fairly simple drivers like this one merged ...

Cheers, Daniel


> 
> Regards,
> Matthias
> 
> >regards
> >Philipp
> >
> >The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9:
> >
> >   Linux 4.6-rc2 (2016-04-03 09:09:40 -0500)
> >
> >are available in the git repository at:
> >
> >   git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-04-19
> >
> >for you to fetch changes up to e34ba70de8c46a460328a362eece4db6e9b63ec7:
> >
> >   arm64: dts: mt8173: Add display subsystem related nodes (2016-04-19 
> > 14:54:42 +0200)
> >
> >
> >MT8173 DRM support
> >
> >- device tree bindings for all MT8173 display subsystem
> >   components
> >- basic mediatek drm driver for MT8173 with two optional,
> >   currently fixed output paths:
> >- DSI encoder support for DSI and (via bridge) eDP panels
> >- DPI encoder support for output to HDMI bridge
> >- necessary clock tree changes for the DPI->HDMI path
> >
> >
> >CK Hu (4):
> >   dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
> >   drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
> >   drm/mediatek: Add DSI sub driver
> >   arm64: dts: mt8173: Add display subsystem related nodes
> >
> >Jie Qiu (1):
> >   drm/mediatek: Add DPI sub driver
> >
> >Philipp Zabel (3):
> >   clk: mediatek: make dpi0_sel propagate rate changes
> >   clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output
> >   clk: mediatek: remove hdmitx_dig_cts from TOP clocks
> >
> >  .../bindings/display/mediatek/mediatek,disp.txt| 203 +
> >  .../bindings/display/mediatek/mediatek,dpi.txt |  35 +
> >  .../bindings/display/mediatek/mediatek,dsi.txt |  60 ++
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi   | 223 +
> >  drivers/clk/mediatek/clk-mt8173.c  |  12 +-
> >  drivers/clk/mediatek/clk-mtk.h |  15 +-
> >  drivers/gpu/drm/Kconfig|   2 +
> >  drivers/gpu/drm/Makefile   |   1 +
> >  drivers/gpu/drm/mediatek/Kconfig   |  14 +
> >  drivers/gpu/drm/mediatek/Makefile  |  14 +
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 302 +++
> >  drivers/gpu/drm/mediatek/mtk_disp_rdma.c   | 240 ++
> >  drivers/gpu/drm/mediatek/mtk_dpi.c | 769 +
> >  drivers/gpu/drm/mediatek/mtk_dpi_regs.h| 228 +
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 582 +
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h|  32 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 355 
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp.h |  41 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 225 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 150 
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 567 +
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.h |  59 ++
> >  drivers/gpu/drm/mediatek/mtk_drm_fb.c  | 165 
> >  drivers/gpu/drm/mediatek/mtk_drm_fb.h  |  23 +
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 269 ++
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.h |  59 ++
> >  drivers/gpu/drm/mediatek/mtk_drm_plane.c   | 240 ++
> >  drivers/gpu/drm/mediatek/mtk_drm_plane.h   |  59 ++
> >  drivers/gpu/drm/mediatek/mtk_dsi.c | 927 
> > +
> >  drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 463 ++
> >  include/dt-bindings/clock/mt8173-clk.h |   3 +-
> >  31 files changed, 6332 insertions(+), 5 deletions(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> >  create mode 100644 
> > Documentation/devicet

[Bug 44647] [wine regression] Call of Duty 4: Intro videos renders garbage

2016-04-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=44647

Nicolai H�hnle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #7 from Nicolai H�hnle  ---
This is an application bug (though I don't know whether the fault lies with
Wine or with CoD4): there is insufficient synchronization between different
contexts.

If you look e.g. at Frame 5, there is a sequence of glTexSubImage2D calls for
textures 64 to 66 running in context 3.

The command sequence switches to context 2 in call 75827, and the textures are
used in call 76024, still on context 2 and without any flush or fence command
in between to ensure that the TexSubImage commands are actually executed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/824e2667/attachment.html>


[PATCH 02/13] drm/omapdrm: Use unlocked gem unreferencing

2016-04-20 Thread Laurent Pinchart
Hi Daniel,

Thank you for the patch.

On Wednesday 30 Mar 2016 11:40:41 Daniel Vetter wrote:
> For drm_gem_object_unreference callers are required to hold
> dev->struct_mutex, which these paths don't. Enforcing this requirement
> has become a bit more strict with
> 
> commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
> Author: Daniel Vetter 
> Date:   Thu Oct 15 09:36:25 2015 +0200
> 
> drm/gem: Check locking in drm_gem_object_unreference
> 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c index 3cb16f0cf381..89da41ac64d2
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -153,7 +153,7 @@ static int omap_fbdev_create(struct drm_fb_helper
> *helper, /* note: if fb creation failed, we can't rely on fb destroy
>* to unref the bo:
>*/
> - drm_gem_object_unreference(fbdev->bo);
> + drm_gem_object_unreference_unlocked(fbdev->bo);
>   ret = PTR_ERR(fb);
>   goto fail;
>   }

-- 
Regards,

Laurent Pinchart



[PATCH] drm: Fix compilation on systems that don't provide O_CLOEXEC

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 4:39 PM, Stefan Dirsch  wrote:
> Patch suggestion by Thomas Klausner. See also
> http://mail-index.netbsd.org/pkgsrc-changes/2012/08/13/msg076887.html
>
> Signed-off-by: Stefan Dirsch 

Fix your OS to have O_CLOEXEC semantics I think is what should happen
here. It's an obvious race in multi-threaded apps, and you need a fix
for it anyway.
-Daniel

> ---
>  include/drm/drm.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index b4ebaa9..739df01 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -674,7 +674,11 @@ struct drm_set_client_cap {
>  };
>
>  #define DRM_RDWR O_RDWR
> +#ifdef O_CLOEXEC
>  #define DRM_CLOEXEC O_CLOEXEC
> +#else
> +#define DRM_CLOEXEC 0
> +#endif
>  struct drm_prime_handle {
> __u32 handle;
>
> --
> 2.6.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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


[PATCH] drm: Fix compilation on systems that don't provide O_CLOEXEC

2016-04-20 Thread Stefan Dirsch
Patch suggestion by Thomas Klausner. See also
http://mail-index.netbsd.org/pkgsrc-changes/2012/08/13/msg076887.html

Signed-off-by: Stefan Dirsch 
---
 include/drm/drm.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index b4ebaa9..739df01 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -674,7 +674,11 @@ struct drm_set_client_cap {
 };

 #define DRM_RDWR O_RDWR
+#ifdef O_CLOEXEC
 #define DRM_CLOEXEC O_CLOEXEC
+#else
+#define DRM_CLOEXEC 0
+#endif
 struct drm_prime_handle {
__u32 handle;

-- 
2.6.2



[Bug 44647] [wine regression] Call of Duty 4: Intro videos renders garbage

2016-04-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=44647

--- Comment #6 from Sven Arvidsson  ---
I just tried Wine Staging with the CSMT (Command stream multithreading)
patches, and the videos play fine there, so I think it really is a problem with
Wine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/7fe0c4f1/attachment.html>


[PATCH 1/3] staging/android: remove redundant comments on sync_merge_data

2016-04-20 Thread Gustavo Padovan
I messed up with the subject prefix, but this is v11, adds typecheck()
to patch 2.

2016-04-20 Gustavo Padovan :

> From: Gustavo Padovan 
> 
> struct sync_merge_data already have documentation on top of the
> struct definition. No need to duplicate it.
> 
> Signed-off-by: Gustavo Padovan 
> Reviewed-by: Maarten Lankhorst 
> ---
>  drivers/staging/android/uapi/sync.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/android/uapi/sync.h 
> b/drivers/staging/android/uapi/sync.h
> index a0cf357..4467c76 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -21,9 +21,9 @@
>   * @fence:   returns the fd of the new fence to userspace
>   */
>  struct sync_merge_data {
> - __s32   fd2; /* fd of second fence */
> - charname[32]; /* name of new fence */
> - __s32   fence; /* fd on newly created fence */
> + __s32   fd2;
> + charname[32];
> + __s32   fence;
>  };
>  
>  /**
> -- 
> 2.5.5
> 

Gustavo


[PATCH 1/2] drm/rockchip: vop: Do check if an update is pending during disable

2016-04-20 Thread Tomeu Vizoso
On 11 April 2016 at 03:15, Mark yao  wrote:
> On 2016年04月08日 18:54, Tomeu Vizoso wrote:
>>
>> On 8 April 2016 at 03:07, Mark yao  wrote:
>>>
>>> On 2016年04月06日 18:14, Tomeu Vizoso wrote:
>>>
>>> When a plane is being disabled but it's still enabled, do check if the
>>> previous update has been completed by reading yrgb_mst back.
>>>
>>> Otherwise, pending pageflips would remain pending after a CRTC is
>>> disabled.
>>>
>>> Signed-off-by: Tomeu Vizoso 
>>> ---
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +++--
>>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> index a9b1e8b5ac85..f46b1fd1887b 100644
>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> @@ -1064,8 +1064,9 @@ static bool vop_win_pending_is_complete(struct
>>> vop_win
>>> *vop_win)
>>>struct vop_plane_state *state = to_vop_plane_state(plane->state);
>>>dma_addr_t yrgb_mst;
>>>
>>> - if (!state->enable)
>>> - return VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0;
>>> + if (!state->enable &&
>>> +VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0)
>>> + return true;
>>>
>>>
>>> It is wrong, the patch would cause a bug.
>>>
>>> when state->enable is 0, check yrgb_mst == state->yrgb_mst always be
>>> true,
>>> because state->yrgb_mst not update on plane disabled funtion, that would
>>> cause iommu crash.
>>
>> Sorry, but I don't understand where's the bug and what could cause
>> that crash. What the existing code was doing is saying that a pageflip
>> event is still pending if we have told the plane to disable but for
>> some reason it hasn't yet.
>>
>> With this modification, if we read back that it's already disabled, we
>> return true as before. But if we read back that it isn't disabled yet,
>> then we still check the fb pointers and compare them.
>>
>> The iommu mapping is removed when the _CRTC_ is disabled, and what
>> this series does is to wait for the pending pageflip to finish before
>> conitnuing with CRTC disablement.
>
>
> the iommu mapping will unmap after plane disabled, we need sure that the
> plane really disabled before unmap, if not, the unmap may call before plane
> really disable, vop may access unmap address, then would get iommu page
> fault.

Sorry, but I still don't see the error condition that you are
describing. AFAICS, the unmap will happen after the last pageflip has
completed.

>>> About pending pageflips would remain pending, can you  describe more info
>>> about it? I think those pending pageflips should be ignore when CRTC is
>>> disabled.
>>
>> Well, right now in rockchip-drm pending pageflips won't be ignored
>> when a CRTC is disabled, but will be delivered when it's re-enabled.
>>
>> If they would be to be ignored (understanding that as dropped), that
>> would require modifications to clients so they keep track of which fbs
>> were used in a particular crtc and destroy them when the crtc is
>> disabled, but that would be incorrect when using the i915 DRM driver
>> (I also assume others do the same). Given that the pageflip ioctl
>> isn't driver-specific, I think there cannot be such a difference in
>> behavior between drivers.
>>
>> With the current behavior (pending pageflip events being delayed until
>> the CRTC is enabled again), compositors and other clients will be
>> holding on to the fb in the pending pageflip until an arbitrary point
>> in the future that may not ever come. To me that sounds like a serious
>> modification of the assumptions on fb lifecycle that might not be
>> warranted.
>>
>> So in summary, even if I haven't found any explicit documentation on
>> this, I think the ABI is that any pending pageflips are to be
>> delivered when that CRTC is being disabled and not later.
>
>
> on drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>
> drm_atomic_helper_commit_planes(dev, state, true);
> rockchip_atomic_wait_for_complete(dev, state);
>
> We set active_only = true, I think planes can only update when crtc is
> active. and rockchip_atomic_wait_for_complete only wait when crtc is active.

That's fine, but if a pageflip is pending when the client requests the
CRTC to be disabled, we need to wait for the event to be emitted
before we actually disable the HW.

Regards,

Tomeu

> Thanks.
>
>> Thanks,
>>
>> Tomeu
>>
>>> Thanks.
>>>
>>>
>>>yrgb_mst = VOP_WIN_GET_YRGBADDR(vop_win->vop, vop_win->data);
>>>
>>>
>>>
>>> --
>>> ï¼­ark Yao
>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>>
>
>
> --
> ï¼­ark Yao
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] staging/android: refactor SYNC IOCTLs

2016-04-20 Thread Gustavo Padovan
From: Gustavo Padovan 

Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.

Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.

However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.

Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.

Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.

info->sync_fence_info was converted to __u64 pointer to prevent 32bit
compatibility issues. And a flags member was added.

An example userspace code for the later would be:

struct sync_file_info *info;
int err, size, num_fences;

info = malloc(sizeof(*info));

info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;

if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
  sizeof(struct 
sync_fence_info));

err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}

Finally the IOCTLs numbers were changed to avoid any potential old
userspace running the old API to get weird errors. Changing the opcodes
will make them fail right away. This is just a precaution, there no
upstream users of these interfaces yet and the only user is Android, but
we don't expect anyone trying to run android userspace and all it
dependencies on top of upstream kernels.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
Acked-by: Greg Hackmann 
Acked-by: Rob Clark 
Acked-by: Daniel Vetter 

---
v2: fix fence_info memory leak

v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()

Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size

Comments from Dan Carpenter
- fix info->sync_fence_info documentation

v4: remove allocated struct sync_file_info (comment from Maarten)

v5: merge all commits that were changing the ABI

v6: fix -Wint-to-pointer-cast error on info.sync_fence_info
---
 drivers/staging/android/sync.c  | 76 -
 drivers/staging/android/uapi/sync.h | 36 +-
 2 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..f9c6094 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
goto err_put_fd;
}

+   if (data.flags || data.pad) {
+   err = -EINVAL;
+   goto err_put_fd;
+   }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -479,13 +484,9 @@ err_put_fd:
return err;
 }

-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+   struct sync_fence_info *info)
 {
-   struct sync_fence_info *info = data;
-
-   if (size < sizeof(*info))
-   return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,58 +496,63 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
-   return sizeof(*info);
 }

 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
 {
-   struct sync_file_info *info;
+   struct sync_file_info info;
+   struct sync_fence_info *fence_info = NULL;
__u32 size;
-   __u32 len = 0;
int ret, i;

-   if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+   if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;

-   if (size < sizeof(struct sync_file_info))
+   if (info.flags || info.pad)
return -EINVAL;

-   if (size > 4096)
-   

[PATCH 2/3] kernel.h: add u64_to_user_ptr()

2016-04-20 Thread Gustavo Padovan
From: Gustavo Padovan 

This function had copies in 3 different files. Unify them in kernel.h.

Cc: Joe Perches 
Cc: Andrew Morton 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Rob Clark 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 11 +++
 drivers/gpu/drm/i915/i915_drv.h  |  5 -
 drivers/gpu/drm/i915/i915_gem.c  | 14 +++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 14 +++---
 drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
 include/linux/kernel.h   |  6 ++
 6 files changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 236ada9..afdd55d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -28,11 +28,6 @@
 #define BO_LOCKED   0x4000
 #define BO_PINNED   0x2000

-static inline void __user *to_user_ptr(u64 address)
-{
-   return (void __user *)(uintptr_t)address;
-}
-
 static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
struct etnaviv_gpu *gpu, size_t nr)
 {
@@ -347,21 +342,21 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
cmdbuf->exec_state = args->exec_state;
cmdbuf->ctx = file->driver_priv;

-   ret = copy_from_user(bos, to_user_ptr(args->bos),
+   ret = copy_from_user(bos, u64_to_user_ptr(args->bos),
 args->nr_bos * sizeof(*bos));
if (ret) {
ret = -EFAULT;
goto err_submit_cmds;
}

-   ret = copy_from_user(relocs, to_user_ptr(args->relocs),
+   ret = copy_from_user(relocs, u64_to_user_ptr(args->relocs),
 args->nr_relocs * sizeof(*relocs));
if (ret) {
ret = -EFAULT;
goto err_submit_cmds;
}

-   ret = copy_from_user(stream, to_user_ptr(args->stream),
+   ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
 args->stream_size);
if (ret) {
ret = -EFAULT;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1048093..bb624cc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3576,11 +3576,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct 
drm_device *dev)
return VGACNTRL;
 }

-static inline void __user *to_user_ptr(u64 address)
-{
-   return (void __user *)(uintptr_t)address;
-}
-
 static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
 {
unsigned long j = msecs_to_jiffies(m);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dabc089..2889716 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -324,7 +324,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
 {
struct drm_device *dev = obj->base.dev;
void *vaddr = obj->phys_handle->vaddr + args->offset;
-   char __user *user_data = to_user_ptr(args->data_ptr);
+   char __user *user_data = u64_to_user_ptr(args->data_ptr);
int ret = 0;

/* We manually control the domain here and pretend that it
@@ -605,7 +605,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int needs_clflush = 0;
struct sg_page_iter sg_iter;

-   user_data = to_user_ptr(args->data_ptr);
+   user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;

obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
@@ -692,7 +692,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
return 0;

if (!access_ok(VERIFY_WRITE,
-  to_user_ptr(args->data_ptr),
+  u64_to_user_ptr(args->data_ptr),
   args->size))
return -EFAULT;

@@ -783,7 +783,7 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
if (ret)
goto out_unpin;

-   user_data = to_user_ptr(args->data_ptr);
+   user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;

offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
@@ -907,7 +907,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
int needs_clflush_before = 0;
struct sg_page_iter sg_iter;

-   user_data = to_user_ptr(args->data_ptr);
+   user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;

obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
@@ -1036,12 +1036,12 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
return 0;

if (!access_ok(VERIFY_READ,
-  to_user_ptr(args->data_ptr),
+  u64_to_user_ptr(args->data_ptr),
   args->size))
return -EFAULT;

if (likely(!i915.prefault_

[PATCH 1/3] staging/android: remove redundant comments on sync_merge_data

2016-04-20 Thread Gustavo Padovan
From: Gustavo Padovan 

struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
---
 drivers/staging/android/uapi/sync.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index a0cf357..4467c76 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
  * @fence: returns the fd of the new fence to userspace
  */
 struct sync_merge_data {
-   __s32   fd2; /* fd of second fence */
-   charname[32]; /* name of new fence */
-   __s32   fence; /* fd on newly created fence */
+   __s32   fd2;
+   charname[32];
+   __s32   fence;
 };

 /**
-- 
2.5.5



[PATCH v10 RESEND 2/3] kernel.h: add u64_to_user_ptr()

2016-04-20 Thread Gustavo Padovan
2016-04-20 Maarten Lankhorst :

> Op 19-04-16 om 22:42 schreef Gustavo Padovan:
> > From: Gustavo Padovan 
> >
> > This function had copies in 3 different files. Unify them in kernel.h.
> >
> > Cc: Joe Perches 
> > Cc: Andrew Morton 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Rob Clark 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 11 +++
> >  drivers/gpu/drm/i915/i915_drv.h  |  5 -
> >  drivers/gpu/drm/i915/i915_gem.c  | 14 +++---
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 14 +++---
> >  drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
> >  include/linux/kernel.h   |  5 +
> >  6 files changed, 25 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > index 236ada9..afdd55d 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > @@ -28,11 +28,6 @@
> >  #define BO_LOCKED   0x4000
> >  #define BO_PINNED   0x2000
> >  
> > -static inline void __user *to_user_ptr(u64 address)
> > -{
> > -   return (void __user *)(uintptr_t)address;
> > -}
> > -
> >  static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
> > struct etnaviv_gpu *gpu, size_t nr)
> >  {
> > @@ -347,21 +342,21 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> > void *data,
> > cmdbuf->exec_state = args->exec_state;
> > cmdbuf->ctx = file->driver_priv;
> >  
> > -   ret = copy_from_user(bos, to_user_ptr(args->bos),
> > +   ret = copy_from_user(bos, u64_to_user_ptr(args->bos),
> >  args->nr_bos * sizeof(*bos));
> > if (ret) {
> > ret = -EFAULT;
> > goto err_submit_cmds;
> > }
> >  
> > -   ret = copy_from_user(relocs, to_user_ptr(args->relocs),
> > +   ret = copy_from_user(relocs, u64_to_user_ptr(args->relocs),
> >  args->nr_relocs * sizeof(*relocs));
> > if (ret) {
> > ret = -EFAULT;
> > goto err_submit_cmds;
> > }
> >  
> > -   ret = copy_from_user(stream, to_user_ptr(args->stream),
> > +   ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
> >  args->stream_size);
> > if (ret) {
> > ret = -EFAULT;
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 1048093..bb624cc 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3576,11 +3576,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct 
> > drm_device *dev)
> > return VGACNTRL;
> >  }
> >  
> > -static inline void __user *to_user_ptr(u64 address)
> > -{
> > -   return (void __user *)(uintptr_t)address;
> > -}
> > -
> >  static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
> >  {
> > unsigned long j = msecs_to_jiffies(m);
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index dabc089..2889716 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -324,7 +324,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
> >  {
> > struct drm_device *dev = obj->base.dev;
> > void *vaddr = obj->phys_handle->vaddr + args->offset;
> > -   char __user *user_data = to_user_ptr(args->data_ptr);
> > +   char __user *user_data = u64_to_user_ptr(args->data_ptr);
> > int ret = 0;
> >  
> > /* We manually control the domain here and pretend that it
> > @@ -605,7 +605,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
> > int needs_clflush = 0;
> > struct sg_page_iter sg_iter;
> >  
> > -   user_data = to_user_ptr(args->data_ptr);
> > +   user_data = u64_to_user_ptr(args->data_ptr);
> > remain = args->size;
> >  
> > obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
> > @@ -692,7 +692,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
> > return 0;
> >  
> > if (!access_ok(VERIFY_WRITE,
> > -  to_user_ptr(args->data_ptr),
> > +  u64_to_user_ptr(args->data_ptr),
> >args->size))
> > return -EFAULT;
> >  
> > @@ -783,7 +783,7 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
> > if (ret)
> > goto out_unpin;
> >  
> > -   user_data = to_user_ptr(args->data_ptr);
> > +   user_data = u64_to_user_ptr(args->data_ptr);
> > remain = args->size;
> >  
> > offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
> > @@ -907,7 +907,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
> > int needs_clflush_before = 0;
> > struct sg_page_iter sg_iter;
> >  
> > -   user_data = to_user_ptr(args->data_ptr);
> > +   user_data = u64_to_user_ptr(args->data_ptr);
> > remain = args->size;
> >  
> > obj_do_bit17_swizzling = i915_gem_ob

[PATCH] drm/layerscape: reduce excessive stack usage

2016-04-20 Thread Stefan Agner
On 2016-02-22 13:33, Arnd Bergmann wrote:
> The fsl-dcu driver copies a drm_mode_config object to its
> stack but then only accesses a single member (dpms_property)
> once. The data structure is large enough to trigger a warning
> about the amount of kernel stack being used:
> 
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c: In function
> 'fsl_dcu_drm_connector_create':
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:182:1: error: the frame size
> of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> 
> This changes the fsl_dcu_drm_connector_create() function to
> only access the drm_mode_config by reference, which is also
> more efficient.

Applied to my tree:
http://git.agner.ch/gitweb/?p=linux-drm-fsl-dcu.git;a=summary

--
Stefan

> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 109eee2f2a18 ("drm/layerscape: Add Freescale DCU DRM driver")
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> index 8780deba5e8a..92149152db44 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -131,7 +131,7 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
>struct drm_encoder *encoder)
>  {
>   struct drm_connector *connector = &fsl_dev->connector.base;
> - struct drm_mode_config mode_config = fsl_dev->drm->mode_config;
> + struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;
>   struct device_node *panel_node;
>   int ret;
>  
> @@ -153,7 +153,7 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
>   goto err_sysfs;
>  
>   drm_object_property_set_value(&connector->base,
> -   mode_config.dpms_property,
> +   mode_config->dpms_property,
> DRM_MODE_DPMS_OFF);
>  
>   panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);


[PATCH 0/9] Enable Gen 7 Observation Architecture

2016-04-20 Thread Robert Bragg
Ah, something I forgot to highlight in the cover letter is an issue with
the "drm/i915: don't whitelist oacontrol in cmd parser" patch in this
series...

I was hoping that I could get away with this without breaking any existing
userspace, since the only userspace I know that attempts to configure
OACONTROL via LRIs is Mesa which attempts to verify that it can
successfully write to OACONTROL before exposing its current
INTEL_performance_query implementation, and it seems like it should
gracefully handle a failure here as if the command parser where disabled.

Something curious here is that this patch seemed to work as expected when
my series was recently based on a v4.5 kernel, but since rebasing last week
on a couple of different recent nightlies I'm now seeing gnome-shell
failing to run.

Incidentally, entirely disabling the command parser seems to work; but
removing just OACONTROL seems to cause trouble.

Hopefully I can get a better understanding of what's going on here, though
I can at least confirm the problem is triggered via the
intel_extensions.c:can_write_oacontrol() check in Mesa. Bypassing this
check (with a true or false status) is enough to get gnome-shell running
again.

This could be a fiddly compatibility issue if it turns out to not be
possible to remove OACONTROL from the cmd parser white list. One basic
problem that stems from here is that whenever a GL application starts and
this OACONTROL check is done it ends up resetting OACONTROL to zero which
disables the OA unit which may be in use via the i915 perf interface.

Regards,
- Robert


On Wed, Apr 20, 2016 at 3:23 PM, Robert Bragg  wrote:

> I've been working on some i-g-t tests for this new interface and while I
> still
> have some more tests to write, it still seemed worth sending out another
> updated
> series in the mean time.
>
>
> Firstly this includes updates based on Emil's previous comments.
>
> Then there have been a few issue hit while writing tests:
>
> * It seems it can take a fairly long time for the MUX config to apply after
>   the register writes have finished, and now the driver inserts a delay
> after
>   configuration, before enabling periodic sampling.
> * I've found that sometimes the HW tail pointer can get ahead of OA buffer
>   writes, especially with higher sampling frequencies, and so now the
> driver
>   maintains a margin behind the HW tail pointer to ensure the most recent
>   reports have some time to land before attempting to copy them to
> userspace.
> * As a sanity check that a report is valid before it's copied to userspace
> the
>   driver checks the report-id field != 0
> * The _BUFFER_OVERFLOW record has been replaced with a _BUFFER_LOST record
> with
>   more specific semantics.
> * Since we can't clear the overflow status on Haswell while periodic
> sampling
>   is enabled, if an overflow occurs we now restart the unit.
> * The maximum OA periodic sampling exponent is now 31
> * We verify the head/tail pointers read back from HW look sane before
> using as
>   offsets to read reports from the OA buffer. We reset the HW if they look
> bad.
>
>
> For reference the work-in-progress i-g-t tests can be found here:
>
> https://github.com/rib/intel-gpu-tools
> branch = wip/rib/i915-perf-tests
>
> or browsed here:
> https://github.com/rib/intel-gpu-tools/commits/wip/rib/i915-perf-tests
>
> Also for reference these patches can be fetched from here:
>
> https://github.com/rib/linux
> branch = wip/rib/oa-2016-04-19-nightly
>
> Regards,
> - Robert
>
>
> Robert Bragg (9):
>   drm/i915: Add i915 perf infrastructure
>   drm/i915: rename OACONTROL GEN7_OACONTROL
>   drm/i915: don't whitelist oacontrol in cmd parser
>   drm/i915: Add 'render basic' Haswell OA unit config
>   drm/i915: Enable i915 perf stream for Haswell OA unit
>   drm/i915: advertise available metrics via sysfs
>   drm/i915: Add dev.i915.perf_event_paranoid sysctl option
>   drm/i915: add oa_event_min_timer_exponent sysctl
>   drm/i915: Add more Haswell OA metric sets
>
>  drivers/gpu/drm/i915/Makefile   |4 +
>  drivers/gpu/drm/i915/i915_cmd_parser.c  |   33 +-
>  drivers/gpu/drm/i915/i915_dma.c |8 +
>  drivers/gpu/drm/i915/i915_drv.h |  155 
>  drivers/gpu/drm/i915/i915_gem_context.c |   24 +-
>  drivers/gpu/drm/i915/i915_oa_hsw.c  |  658 ++
>  drivers/gpu/drm/i915/i915_oa_hsw.h  |   38 +
>  drivers/gpu/drm/i915/i915_perf.c| 1439
> +++
>  drivers/gpu/drm/i915/i915_reg.h |  340 +++-
>  include/uapi/drm/i915_drm.h |  133 +++
>  10 files changed, 2795 insertions(+), 37 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/i915_o

[Bug 44647] [wine regression] Call of Duty 4: Intro videos renders garbage

2016-04-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=44647

--- Comment #5 from Nicolai H�hnle  ---
Hi Sven, thanks for the apitrace. I can confirm that there is garbage in some
of the first frames of the apitrace, e.g. Frame 11 @77450. I'm going to look in
more detail, though the many error messages do hint at an application bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/101dc2a2/attachment.html>


[PATCH v3] drm/dsi: Implement set tear scanline compile fix

2016-04-20 Thread Vinay Simha BN
Provide a small convenience wrapper that transmits
a set_tear_scanline command.
compilation fix

Signed-off-by: Vinay Simha BN 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 26aba75..bba6db2 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -1003,7 +1003,7 @@ int mipi_dsi_set_tear_scanline(struct mipi_dsi_device 
*dsi,

 return 0;
 }
-EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_scanline);
+EXPORT_SYMBOL(mipi_dsi_set_tear_scanline);
 /**
  * mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
  *data used by the interface
-- 
2.1.2



[PATCH] drm: Loongson-3 doesn't fully support wc memory

2016-04-20 Thread Greg KH
On Wed, Apr 20, 2016 at 02:18:20PM +0800, Huacai Chen wrote:
> Cc: stable at vger.kernel.org



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.




[PATCH] drm: Fix compilation on systems that don't provide O_CLOEXEC

2016-04-20 Thread Stefan Dirsch
Patch suggestion by Thomas Klausner . See
also http://mail-index.netbsd.org/pkgsrc-changes/2012/08/13/msg076887.html

Signed-off-by: Stefan Dirsch 
---
 include/drm/drm.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index b4ebaa9..739df01 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -674,7 +674,11 @@ struct drm_set_client_cap {
 };

 #define DRM_RDWR O_RDWR
+#ifdef O_CLOEXEC
 #define DRM_CLOEXEC O_CLOEXEC
+#else
+#define DRM_CLOEXEC 0
+#endif
 struct drm_prime_handle {
__u32 handle;

-- 
2.6.2



[PATCH] Fix compilation on systems that don't provide O_CLOEXEC

2016-04-20 Thread Stefan Dirsch
Patch suggestion by Thomas Klausner . See
also http://mail-index.netbsd.org/pkgsrc-changes/2012/08/13/msg076887.html

Signed-off-by: Stefan Dirsch 
---
 include/drm/drm.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index b4ebaa9..739df01 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -674,7 +674,11 @@ struct drm_set_client_cap {
 };

 #define DRM_RDWR O_RDWR
+#ifdef O_CLOEXEC
 #define DRM_CLOEXEC O_CLOEXEC
+#else
+#define DRM_CLOEXEC 0
+#endif
 struct drm_prime_handle {
__u32 handle;

-- 
2.6.2



[PATCH v2] drm/panel: simple: Add support for Innolux AT070TN92

2016-04-20 Thread Thierry Reding
On Wed, Apr 20, 2016 at 03:37:15PM +0200, Boris Brezillon wrote:
> From: Riccardo Bortolato 
> 
> Add support for the Innolux AT070TN92 panel.
> 
> Signed-off-by: Riccardo Bortolato 
> Signed-off-by: Boris Brezillon 
> 
> ---
> Changes since v1:
> - Add missing SoB
> ---
>  .../bindings/display/panel/innolux,at070tn92.txt   |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/f4e71d52/attachment.sig>


[PATCH v2] drm/panel: simple: Add support for Innolux AT070TN92

2016-04-20 Thread Boris Brezillon
From: Riccardo Bortolato 

Add support for the Innolux AT070TN92 panel.

Signed-off-by: Riccardo Bortolato 
Signed-off-by: Boris Brezillon 

---
Changes since v1:
- Add missing SoB
---
 .../bindings/display/panel/innolux,at070tn92.txt   |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt
new file mode 100644
index 000..3e10cd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt
@@ -0,0 +1,7 @@
+Innolux AT070TN92 7.0" WQVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,at070tn92"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3649eb0..d321c57 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -822,6 +822,29 @@ static const struct panel_desc innolux_at043tn24 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

+static const struct drm_display_mode innolux_at070tn92_mode = {
+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 210,
+   .hsync_end = 800 + 210 + 20,
+   .htotal = 800 + 210 + 20 + 46,
+   .vdisplay = 480,
+   .vsync_start = 480 + 22,
+   .vsync_end = 480 + 22 + 10,
+   .vtotal = 480 + 22 + 23 + 10,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc innolux_at070tn92 = {
+   .modes = &innolux_at070tn92_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct drm_display_mode innolux_g121i1_l01_mode = {
.clock = 71000,
.hdisplay = 1280,
@@ -1362,6 +1385,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,at043tn24",
.data = &innolux_at043tn24,
}, {
+   .compatible = "innolux,at070tn92",
+   .data = &innolux_at070tn92,
+   }, {
.compatible ="innolux,g121i1-l01",
.data = &innolux_g121i1_l01
}, {
-- 
2.5.0



[GIT PULL] MT8173 DRM support

2016-04-20 Thread Matthias Brugger


On 19/04/16 15:42, Philipp Zabel wrote:
> Hi Dave,
>
> please consider pulling this tag with initial MediaTek MT8173 DRM
> support, corresponding to v14 of the patch series. These patches have
> been mostly stable for the last few rounds. I'll follow up with the HDMI
> encoder support pending review of the latest version.
>

Please don't pull
e34ba70de8c4 ("arm64: dts: mt8173: Add display subsystem related nodes")
If you pull the rest, this patch will go through my branch.

Regards,
Matthias

> regards
> Philipp
>
> The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9:
>
>Linux 4.6-rc2 (2016-04-03 09:09:40 -0500)
>
> are available in the git repository at:
>
>git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-04-19
>
> for you to fetch changes up to e34ba70de8c46a460328a362eece4db6e9b63ec7:
>
>arm64: dts: mt8173: Add display subsystem related nodes (2016-04-19 
> 14:54:42 +0200)
>
> 
> MT8173 DRM support
>
> - device tree bindings for all MT8173 display subsystem
>components
> - basic mediatek drm driver for MT8173 with two optional,
>currently fixed output paths:
> - DSI encoder support for DSI and (via bridge) eDP panels
> - DPI encoder support for output to HDMI bridge
> - necessary clock tree changes for the DPI->HDMI path
>
> 
> CK Hu (4):
>dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
>drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
>drm/mediatek: Add DSI sub driver
>arm64: dts: mt8173: Add display subsystem related nodes
>
> Jie Qiu (1):
>drm/mediatek: Add DPI sub driver
>
> Philipp Zabel (3):
>clk: mediatek: make dpi0_sel propagate rate changes
>clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output
>clk: mediatek: remove hdmitx_dig_cts from TOP clocks
>
>   .../bindings/display/mediatek/mediatek,disp.txt| 203 +
>   .../bindings/display/mediatek/mediatek,dpi.txt |  35 +
>   .../bindings/display/mediatek/mediatek,dsi.txt |  60 ++
>   arch/arm64/boot/dts/mediatek/mt8173.dtsi   | 223 +
>   drivers/clk/mediatek/clk-mt8173.c  |  12 +-
>   drivers/clk/mediatek/clk-mtk.h |  15 +-
>   drivers/gpu/drm/Kconfig|   2 +
>   drivers/gpu/drm/Makefile   |   1 +
>   drivers/gpu/drm/mediatek/Kconfig   |  14 +
>   drivers/gpu/drm/mediatek/Makefile  |  14 +
>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 302 +++
>   drivers/gpu/drm/mediatek/mtk_disp_rdma.c   | 240 ++
>   drivers/gpu/drm/mediatek/mtk_dpi.c | 769 +
>   drivers/gpu/drm/mediatek/mtk_dpi_regs.h| 228 +
>   drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 582 +
>   drivers/gpu/drm/mediatek/mtk_drm_crtc.h|  32 +
>   drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 355 
>   drivers/gpu/drm/mediatek/mtk_drm_ddp.h |  41 +
>   drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 225 +
>   drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 150 
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c | 567 +
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h |  59 ++
>   drivers/gpu/drm/mediatek/mtk_drm_fb.c  | 165 
>   drivers/gpu/drm/mediatek/mtk_drm_fb.h  |  23 +
>   drivers/gpu/drm/mediatek/mtk_drm_gem.c | 269 ++
>   drivers/gpu/drm/mediatek/mtk_drm_gem.h |  59 ++
>   drivers/gpu/drm/mediatek/mtk_drm_plane.c   | 240 ++
>   drivers/gpu/drm/mediatek/mtk_drm_plane.h   |  59 ++
>   drivers/gpu/drm/mediatek/mtk_dsi.c | 927 
> +
>   drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 463 ++
>   include/dt-bindings/clock/mt8173-clk.h |   3 +-
>   31 files changed, 6332 insertions(+), 5 deletions(-)
>   create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
>   create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
>   create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
>   create mode 100644 drivers/gpu/drm/mediatek/Kconfig
>   create mode 100644 drivers/gpu/drm/mediatek/Makefile
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_rdma.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi_regs.h
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c
>   create mode 100644 drivers/gpu/drm/mediate

[PATCH] drm/panel: simple: Add support for Innolux AT070TN92

2016-04-20 Thread Thierry Reding
On Wed, Apr 20, 2016 at 02:17:59PM +0200, Boris Brezillon wrote:
> From: Riccardo Bortolato 
> 
> Add support for the Innolux AT070TN92 panel.
> 
> Signed-off-by: Riccardo Bortolato 

Hi Boris,

This needs your Signed-off-by: as well.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/8efe027b/attachment.sig>


[PATCH 1/2] drm/radeon: forbid mapping of userptr bo through radeon device file

2016-04-20 Thread Christian König
There are also checks in (amdgpu|radeon)_gem_mmap_ioctl() to prevent 
this as well.

But it shouldn't hurt us to check that here as well. So both patches are 
Reviewed-by: Christian König 

Regards,
Christian.

Am 19.04.2016 um 15:07 schrieb Jérôme Glisse:
> Allowing userptr bo which are basicly a list of page from some vma
> (so either anonymous page or file backed page) would lead to serious
> corruption of kernel structures and counters (because we overwrite
> the page->mapping field when mapping buffer).
>
> This will already block if the buffer was populated before anyone does
> try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
> ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
> vm fault handler.
>
> So to be safe just add a check to verify_access() callback.
>
> Signed-off-by: Jérôme Glisse 
> Cc: 
> ---
>   drivers/gpu/drm/radeon/radeon_ttm.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 7dddfdc..90f7394 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -235,6 +235,8 @@ static int radeon_verify_access(struct ttm_buffer_object 
> *bo, struct file *filp)
>   {
>   struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
>   
> + if (radeon_ttm_tt_has_userptr(bo->ttm))
> + return -EPERM;
>   return drm_vma_node_verify_access(&rbo->gem_base.vma_node, filp);
>   }
>   



[PATCH 9/9] drm/i915: Add more Haswell OA metric sets

2016-04-20 Thread Robert Bragg
This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_oa_hsw.c | 483 -
 1 file changed, 482 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 3aa22eb..4a2de8a 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -30,9 +30,14 @@

 enum metric_set_id {
METRIC_SET_ID_RENDER_BASIC = 1,
+   METRIC_SET_ID_COMPUTE_BASIC,
+   METRIC_SET_ID_COMPUTE_EXTENDED,
+   METRIC_SET_ID_MEMORY_READS,
+   METRIC_SET_ID_MEMORY_WRITES,
+   METRIC_SET_ID_SAMPLER_BALANCE,
 };

-int i915_oa_n_builtin_metric_sets_hsw = 1;
+int i915_oa_n_builtin_metric_sets_hsw = 6;

 static const struct i915_oa_reg b_counter_config_render_basic[] = {
{ _MMIO(0x2724), 0x0080 },
@@ -118,6 +123,332 @@ static int select_render_basic_config(struct 
drm_i915_private *dev_priv)
return 0;
 }

+static const struct i915_oa_reg b_counter_config_compute_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2718), 0x },
+   { _MMIO(0x271C), 0x },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2728), 0x },
+   { _MMIO(0x272C), 0x },
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2744), 0x },
+   { _MMIO(0x2748), 0x },
+   { _MMIO(0x274C), 0x },
+   { _MMIO(0x2750), 0x },
+   { _MMIO(0x2754), 0x },
+   { _MMIO(0x2758), 0x },
+   { _MMIO(0x275C), 0x },
+};
+
+static const struct i915_oa_reg mux_config_compute_basic[] = {
+   { _MMIO(0x253A4), 0x },
+   { _MMIO(0x2681C), 0x01F00800 },
+   { _MMIO(0x26820), 0x1000 },
+   { _MMIO(0x2781C), 0x01F00800 },
+   { _MMIO(0x26520), 0x0007 },
+   { _MMIO(0x265A0), 0x0007 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538C), 0x0030 },
+   { _MMIO(0x25384), 0xAA8A },
+   { _MMIO(0x25404), 0x },
+   { _MMIO(0x26800), 0x4202 },
+   { _MMIO(0x26808), 0x00605817 },
+   { _MMIO(0x2680C), 0x10001005 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x27800), 0x0102 },
+   { _MMIO(0x27808), 0x0C0701E0 },
+   { _MMIO(0x2780C), 0x000200A0 },
+   { _MMIO(0x27804), 0x },
+   { _MMIO(0x26484), 0x4400 },
+   { _MMIO(0x26704), 0x4400 },
+   { _MMIO(0x26500), 0x0006 },
+   { _MMIO(0x26510), 0x0001 },
+   { _MMIO(0x26504), 0x8800 },
+   { _MMIO(0x26580), 0x0006 },
+   { _MMIO(0x26590), 0x0020 },
+   { _MMIO(0x26584), 0x },
+   { _MMIO(0x26104), 0x5582 },
+   { _MMIO(0x26184), 0xAA86 },
+   { _MMIO(0x25420), 0x08320C83 },
+   { _MMIO(0x25424), 0x06820C83 },
+   { _MMIO(0x2541C), 0x },
+   { _MMIO(0x25428), 0x0C03 },
+};
+
+static int select_compute_basic_config(struct drm_i915_private *dev_priv)
+{
+   dev_priv->perf.oa.mux_regs =
+   mux_config_compute_basic;
+   dev_priv->perf.oa.mux_regs_len =
+   ARRAY_SIZE(mux_config_compute_basic);
+
+   dev_priv->perf.oa.b_counter_regs =
+   b_counter_config_compute_basic;
+   dev_priv->perf.oa.b_counter_regs_len =
+   ARRAY_SIZE(b_counter_config_compute_basic);
+
+   return 0;
+}
+
+static const struct i915_oa_reg b_counter_config_compute_extended[] = {
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2770), 0x0007fe2a },
+   { _MMIO(0x2774), 0xff00 },
+   { _MMIO(0x2778), 0x0007fe6a },
+   { _MMIO(0x277c), 0xff00 },
+   { _MMIO(0x2780), 0x0007fe92 },
+   { _MMIO(0x2784), 0xff00 },
+   { _MMIO(0x2788), 0x0007fea2 },
+   { _MMIO(0x278c), 0xff00 },
+   { _MMIO(0x2790), 0x0007fe32 },
+   { _MMIO(0x2794), 0xff00 },
+   { _MMIO(0x2798), 0x0007fe9a },
+   { _MMIO(0x279c), 0xff00 },
+   { _MMIO(0x27a0), 0x0007ff23 },
+   { _MMIO(0x27a4), 0xff00 },
+   { _MMIO(0x27a8), 0x0007fff3 },
+   { _MMIO(0x27ac), 0xfffe },
+};
+
+static const struct i915_oa_reg mux_config_compute_extended[] = {
+   { _MMIO(0x2681C), 0x3EB00800 },
+   { _MMIO(0x26820), 0x0090 },
+   { _MMIO(0x25384), 0x02AA },
+   { _MMIO(0x25404), 0x03FF },
+   { _MMIO(0x26800), 0x00142284 },
+   { _MMIO(0x26808), 0x0E629062 },
+   { _MMIO(0x2680C), 0x3F6F55CB },
+   { _MMIO(0x26810), 0x0014 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x26104), 0x02AA },
+   { _MMIO(0x26184), 0x02AA },
+   { _MMIO(0x25420), 0x

[PATCH 8/9] drm/i915: add oa_event_min_timer_exponent sysctl

2016-04-20 Thread Robert Bragg
The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.

Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 42 
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c2ba16a..cc1cd52 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -71,6 +71,23 @@ static u32 i915_perf_stream_paranoid = true;
  */
 #define OA_EXPONENT_MAX 31

+/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
+static int zero;
+static int oa_exponent_max = OA_EXPONENT_MAX;
+
+/* Theoretically we can program the OA unit to sample every 160ns but don't
+ * allow that by default unless root...
+ *
+ * The period is derived from the exponent as:
+ *
+ *   period = 80ns * 2^(exponent + 1)
+ *
+ * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
+ * (10 by default); with an OA exponent of 6 we get a period of 10.240
+ * microseconds - just under 10Hz
+ */
+static u32 i915_oa_min_timer_exponent = 6;
+
 /* XXX: beware if future OA HW adds new report formats that the current
  * code assumes all reports have a power-of-two size and ~(size - 1) can
  * be used as a mask to align the OA tail pointer.
@@ -1250,21 +1267,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
return -EINVAL;
}

-   /* NB: The exponent represents a period as follows:
-*
-*   80ns * 2^(period_exponent + 1)
-*
-* Theoretically we can program the OA unit to sample
+   /* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* Referring to perf's
-* kernel.perf_event_max_sample_rate for a precedent
-* (10 by default); with an OA exponent of 6 we get
-* a period of 10.240 microseconds -just under 10Hz
 */
-   if (value < 6 && !capable(CAP_SYS_ADMIN)) {
-   DRM_ERROR("Sampling period too high without 
root privileges\n");
+   if (value < i915_oa_min_timer_exponent &&
+   !capable(CAP_SYS_ADMIN)) {
+   DRM_ERROR("OA timer exponent too low without 
root privileges\n");
return -EACCES;
}

@@ -1326,6 +1335,15 @@ static struct ctl_table oa_table[] = {
 .mode = 0644,
 .proc_handler = proc_dointvec,
 },
+   {
+.procname = "oa_min_timer_exponent",
+.data = &i915_oa_min_timer_exponent,
+.maxlen = sizeof(i915_oa_min_timer_exponent),
+.mode = 0644,
+.proc_handler = proc_dointvec_minmax,
+.extra1 = &zero,
+.extra2 = &oa_exponent_max,
+},
{}
 };

-- 
2.7.1



[PATCH 7/9] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

2016-04-20 Thread Robert Bragg
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 46 +++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1406b93..2ac32b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2081,6 +2081,7 @@ struct drm_i915_private {
bool initialized;

struct kobject *metrics_kobj;
+   struct ctl_table_header *sysctl_header;

struct mutex lock;
struct list_head streams;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index f2db3de..c2ba16a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -59,6 +59,8 @@
 #define POLL_FREQUENCY 200
 #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)

+static u32 i915_perf_stream_paranoid = true;
+
 /* The maximum exponent the hardware accepts is 63 (essentially it selects one
  * of the 64bit timestamp bits to trigger reports from) but there's currently
  * no known use case for sampling as infrequently as once per 47 thousand 
years.
@@ -1105,7 +1107,13 @@ int i915_perf_open_ioctl_locked(struct drm_device *dev,
}
}

-   if (!specific_ctx && !capable(CAP_SYS_ADMIN)) {
+   /* Similar to perf's kernel.perf_paranoid_cpu sysctl option
+* we check a dev.i915.perf_stream_paranoid sysctl option
+* to determine if it's ok to access system wide OA counters
+* without CAP_SYS_ADMIN privileges.
+*/
+   if (!specific_ctx &&
+   i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
DRM_ERROR("Insufficient privileges to open system-wide i915 
perf stream\n");
ret = -EACCES;
goto err_ctx;
@@ -1309,6 +1317,38 @@ int i915_perf_open_ioctl(struct drm_device *dev, void 
*data,
return ret;
 }

+
+static struct ctl_table oa_table[] = {
+   {
+.procname = "perf_stream_paranoid",
+.data = &i915_perf_stream_paranoid,
+.maxlen = sizeof(i915_perf_stream_paranoid),
+.mode = 0644,
+.proc_handler = proc_dointvec,
+},
+   {}
+};
+
+static struct ctl_table i915_root[] = {
+   {
+.procname = "i915",
+.maxlen = 0,
+.mode = 0555,
+.child = oa_table,
+},
+   {}
+};
+
+static struct ctl_table dev_root[] = {
+   {
+.procname = "dev",
+.maxlen = 0,
+.mode = 0555,
+.child = i915_root,
+},
+   {}
+};
+
 void i915_perf_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -1354,6 +1394,8 @@ void i915_perf_init(struct drm_device *dev)
return;
}

+   dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
+
dev_priv->perf.initialized = true;

return;
@@ -1366,6 +1408,8 @@ void i915_perf_fini(struct drm_device *dev)
if (!dev_priv->perf.initialized)
return;

+   unregister_sysctl_table(dev_priv->perf.sysctl_header);
+
i915_perf_deinit_sysfs_hsw(dev_priv);

kobject_put(dev_priv->perf.metrics_kobj);
-- 
2.7.1



[PATCH 6/9] drm/i915: advertise available metrics via sysfs

2016-04-20 Thread Robert Bragg
Each metric set is given a sysfs entry like:

/sys/class/drm/card0/metrics//id

This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN. The  is a globally unique ID for a
specific OA unit configuration that can be reliably used as a key to
lookup corresponding counter meta data and normalization equations.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/i915_oa_hsw.c | 45 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h |  4 
 drivers/gpu/drm/i915/i915_perf.c   | 18 ++-
 4 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 972ae6c..1406b93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2080,6 +2080,8 @@ struct drm_i915_private {
struct {
bool initialized;

+   struct kobject *metrics_kobj;
+
struct mutex lock;
struct list_head streams;

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 5472aa0..3aa22eb 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -24,6 +24,8 @@
  *
  */

+#include 
+
 #include "i915_drv.h"

 enum metric_set_id {
@@ -130,3 +132,46 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
}
 }
+
+static ssize_t
+show_render_basic_id(struct device *kdev, struct device_attribute *attr, char 
*buf)
+{
+   return sprintf(buf, "%d\n", METRIC_SET_ID_RENDER_BASIC);
+}
+
+static struct device_attribute dev_attr_render_basic_id = {
+   .attr = { .name = "id", .mode = S_IRUGO },
+   .show = show_render_basic_id,
+   .store = NULL,
+};
+
+static struct attribute *attrs_render_basic[] = {
+   &dev_attr_render_basic_id.attr,
+   NULL,
+};
+
+static struct attribute_group group_render_basic = {
+   .name = "403d8832-1a27-4aa6-a64e-f5389ce7b212",
+   .attrs =  attrs_render_basic,
+};
+
+int
+i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int ret;
+
+   ret = sysfs_create_group(dev_priv->perf.metrics_kobj, 
&group_render_basic);
+   if (ret)
+   goto error_render_basic;
+
+   return 0;
+
+error_render_basic:
+   return ret;
+}
+
+void
+i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   sysfs_remove_group(dev_priv->perf.metrics_kobj, &group_render_basic);
+}
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.h 
b/drivers/gpu/drm/i915/i915_oa_hsw.h
index b618a1f..e4ba89d 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.h
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.h
@@ -31,4 +31,8 @@ extern int i915_oa_n_builtin_metric_sets_hsw;

 extern int i915_oa_select_metric_set_hsw(struct drm_i915_private *dev_priv);

+extern int i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv);
+
+extern void i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv);
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 5e58520..f2db3de 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1316,6 +1316,11 @@ void i915_perf_init(struct drm_device *dev)
if (!IS_HASWELL(dev))
return;

+   dev_priv->perf.metrics_kobj =
+   kobject_create_and_add("metrics", &dev->primary->kdev->kobj);
+   if (!dev_priv->perf.metrics_kobj)
+   return;
+
hrtimer_init(&dev_priv->perf.oa.poll_check_timer,
 CLOCK_MONOTONIC, HRTIMER_MODE_REL);
dev_priv->perf.oa.poll_check_timer.function = oa_poll_check_timer_cb;
@@ -1343,9 +1348,15 @@ void i915_perf_init(struct drm_device *dev)
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_hsw;

-   dev_priv->perf.oa.oa_formats = hsw_oa_formats;
+   if (i915_perf_init_sysfs_hsw(dev_priv)) {
+   kobject_put(dev_priv->perf.metrics_kobj);
+   dev_priv->perf.metrics_kobj = NULL;
+   return;
+   }

dev_priv->perf.initialized = true;
+
+   return;
 }

 void i915_perf_fini(struct drm_device *dev)
@@ -1355,6 +1366,11 @@ void i915_perf_fini(struct drm_device *dev)
if (!dev_priv->perf.initialized)
return;

+   i915_perf_deinit_sysfs_hsw(dev_priv);
+
+   kobject_put(dev_priv->perf.metrics_kobj);
+   dev_priv->perf.metrics_kobj = NULL;
+
dev_priv->perf.oa.ops.init_oa_buffer = NULL;

dev_priv->perf.initialized = false;
-- 
2.7.1



[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-20 Thread Robert Bragg
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  56 +-
 drivers/gpu/drm/i915/i915_gem_context.c |  24 +-
 drivers/gpu/drm/i915/i915_perf.c| 940 +++-
 drivers/gpu/drm/i915/i915_reg.h | 338 
 include/uapi/drm/i915_drm.h |  70 ++-
 5 files changed, 1408 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5e959f3..972ae6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1708,8 +1708,13 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_oa_format {
+   u32 format;
+   int size;
+};
+
 struct i915_oa_reg {
-   u32 addr;
+   i915_reg_t addr;
u32 value;
 };

@@ -1725,6 +1730,7 @@ struct i915_perf_stream {
struct list_head link;

u32 sample_flags;
+   int sample_size;

struct intel_context *ctx;
bool enabled;
@@ -1786,6 +1792,20 @@ struct i915_perf_stream {
void (*destroy)(struct i915_perf_stream *stream);
 };

+struct i915_oa_ops {
+   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
+   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*oa_enable)(struct drm_i915_private *dev_priv);
+   void (*oa_disable)(struct drm_i915_private *dev_priv);
+   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
+   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
+   u32 ctx_id);
+   int (*read)(struct i915_perf_stream *stream,
+   struct i915_perf_read_state *read_state);
+   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
+};
+
 struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *objects;
@@ -2059,16 +2079,46 @@ struct drm_i915_private {

struct {
bool initialized;
+
struct mutex lock;
struct list_head streams;

+   spinlock_t hook_lock;
+
struct {
-   u32 metrics_set;
+   struct i915_perf_stream *exclusive_stream;
+
+   u32 specific_ctx_id;
+
+   struct hrtimer poll_check_timer;
+   wait_queue_head_t poll_wq;
+
+   bool periodic;
+   int period_exponent;
+   int timestamp_frequency;
+
+   int tail_margin;
+
+   int metrics_set;

const struct i915_oa_reg *mux_regs;
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+
+   struct {
+   struct drm_i915_gem_object *obj;
+   u32 gtt_offset;
+   u8 *addr;
+   int format;
+   int format_size;
+   } oa_buffer;
+
+   u32 gen7_latched_oastatus1;
+
+   struct i915_oa_ops ops;
+   const struct i915_oa_format *oa_formats;
+   int n_builtin_sets;
} oa;
} perf;

@@ -3429,6 +3479,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,

 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
+void i915_oa_context_pin_notify(struct drm_i915_private *dev_priv,
+   struct intel_context *context);

 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index e5acc39..ed5665f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -133,6 +133,23 @@ static int get_context_size(struct drm_device *dev)
return ret;
 }

+static int i915_gem_context_pin_state(struct drm_device *dev,
+ struct intel_context *ctx)
+{
+   int ret;
+
+   BUG_ON(!mutex_is_locked(&dev->struct_mutex));
+
+   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+   get_context_alignment(dev), 0);
+   if (ret)
+   return ret;
+
+   i915_oa_context_pin_notify(dev->dev_private, ctx);
+
+   return 0;
+}
+
 static void i915_gem_context_clean(struc

[PATCH 4/9] drm/i915: Add 'render basic' Haswell OA unit config

2016-04-20 Thread Robert Bragg
Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is autogenerated from an internal XML
description of metric sets.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h|  14 
 drivers/gpu/drm/i915/i915_oa_hsw.c | 132 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  34 ++
 4 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2f7ef71..2a3dc67 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -99,7 +99,8 @@ i915-y += dvo_ch7017.o \
 i915-y += i915_vgpu.o

 # perf code
-i915-y += i915_perf.o
+i915-y += i915_perf.o \
+ i915_oa_hsw.o

 # legacy horrors
 i915-y += i915_dma.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5a2a4d6..5e959f3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1708,6 +1708,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_oa_reg {
+   u32 addr;
+   u32 value;
+};
+
 struct i915_perf_read_state {
int count;
ssize_t read;
@@ -2056,6 +2061,15 @@ struct drm_i915_private {
bool initialized;
struct mutex lock;
struct list_head streams;
+
+   struct {
+   u32 metrics_set;
+
+   const struct i915_oa_reg *mux_regs;
+   int mux_regs_len;
+   const struct i915_oa_reg *b_counter_regs;
+   int b_counter_regs_len;
+   } oa;
} perf;

/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
new file mode 100644
index 000..5472aa0
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -0,0 +1,132 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 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.
+ *
+ */
+
+#include "i915_drv.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_hsw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2710), 0x },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+   { _MMIO(0x253A4), 0x0160 },
+   { _MMIO(0x25440), 0x0010 },
+   { _MMIO(0x25128), 0x },
+   { _MMIO(0x2691C), 0x0800 },
+   { _MMIO(0x26AA0), 0x0150 },
+   { _MMIO(0x26B9C), 0x6000 },
+   { _MMIO(0x2791C), 0x0800 },
+   { _MMIO(0x27AA0), 0x0150 },
+   { _MMIO(0x27B9C), 0x6000 },
+   { _MMIO(0x2641C), 0x0400 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538C), 0x },
+   { _MMIO(0x25384), 0x0800 },
+   { _MMIO(0x25400), 0x0004 },
+   { _MMIO(0x2540C), 0x06029000 },
+   { _MMIO(0x25410), 0x0002 },
+   { _MMIO(0x25404), 0x5C30 },
+   { _MMIO(0x25100), 0x0016 },
+   { _MMIO(0x25110), 0x0400 },
+   { _MMIO(0x25104), 0x },
+   { _MMIO(0x26804), 0x1211 },
+   { _MMIO(0x26884), 0x0100 },
+   { _MMIO(0x26900), 0x0002 },
+   { _MMIO(0x26908), 0x0070 },
+   { _MMIO(0x26904), 0x },
+   { _MMIO(0x26984), 0x1022 },
+   { _MMIO(0x26A04), 0x0011 },
+   { _MMIO(0x26A80), 0x0006 },
+   { _MMIO(0x26A88), 0x0C02 },
+   { _MMIO(0x26A84), 0x },

[PATCH 3/9] drm/i915: don't whitelist oacontrol in cmd parser

2016-04-20 Thread Robert Bragg
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

XXX: actually since rebasing this on a recent nightly this patch does
seem to be breaking gnome-shell on mesa-11.1 - it's not clear a.t.m
why the change didn't seem to cause a problem based on v4.5 with the
same gnome-shell/mesa versions.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 33 ++---
 1 file changed, 2 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 035f2dd..8d323b9 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -445,7 +445,6 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1044,8 +1043,7 @@ bool i915_needs_cmd_parser(struct intel_engine_cs *engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
  const struct drm_i915_cmd_descriptor *desc,
  const u32 *cmd, u32 length,
- const bool is_master,
- bool *oacontrol_set)
+ const bool is_master)
 {
if (desc->flags & CMD_DESC_REJECT) {
DRM_DEBUG_DRIVER("CMD: Rejected command: 0x%08X\n", *cmd);
@@ -1083,26 +1081,6 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
}

/*
-* OACONTROL requires some special handling for
-* writes. We want to make sure that any batch which
-* enables OA also disables it before the end of the
-* batch. The goal is to prevent one process from
-* snooping on the perf data from another process. To do
-* that, we need to check the value that will be written
-* to the register. Hence, limit OACONTROL writes to
-* only MI_LOAD_REGISTER_IMM commands.
-*/
-   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-   if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-   *oacontrol_set = (cmd[offset + 1] != 0);
-   }
-
-   /*
 * Check the value written to the register against the
 * allowed mask/value pair given in the whitelist entry.
 */
@@ -1186,7 +1164,6 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
 {
u32 *cmd, *batch_base, *batch_end;
struct drm_i915_cmd_descriptor default_desc = { 0 };
-   bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
int ret = 0;

batch_base = copy_batch(shadow_batch_obj, batch_obj,
@@ -1243,8 +1220,7 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
break;
}

-   if (!check_cmd(engine, desc, cmd, length, is_master,
-  &oacontrol_set)) {
+   if (!check_cmd(engine, desc, cmd, length, is_master)) {
ret = -EINVAL;
break;
}
@@ -1252,11 +1228,6 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
cmd += length;
}

-   if (oacontrol_set) {
-   DRM_DEBUG_DRIVER(

[PATCH 2/9] drm/i915: rename OACONTROL GEN7_OACONTROL

2016-04-20 Thread Robert Bragg
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before add more gen7 OA
registers

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index a337f33..035f2dd 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -445,7 +445,7 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(OACONTROL), /* Only allowed for LRI and SRM. See below. */
+   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1092,7 +1092,7 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
 * to the register. Hence, limit OACONTROL writes to
 * only MI_LOAD_REGISTER_IMM commands.
 */
-   if (reg_addr == i915_mmio_reg_offset(OACONTROL)) {
+   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9464ba3..de1e9a0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -593,7 +593,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define HSW_CS_GPR(n)   _MMIO(0x2600 + (n) * 8)
 #define HSW_CS_GPR_UDW(n)   _MMIO(0x2600 + (n) * 8 + 4)

-#define OACONTROL _MMIO(0x2360)
+#define GEN7_OACONTROL _MMIO(0x2360)

 #define _GEN7_PIPEA_DE_LOAD_SL 0x70068
 #define _GEN7_PIPEB_DE_LOAD_SL 0x71068
-- 
2.7.1



[PATCH 1/9] drm/i915: Add i915 perf infrastructure

2016-04-20 Thread Robert Bragg
Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_dma.c  |   8 +
 drivers/gpu/drm/i915/i915_drv.h  |  86 
 drivers/gpu/drm/i915/i915_perf.c | 443 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 607 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0b88ba0..2f7ef71 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -98,6 +98,9 @@ i915-y += dvo_ch7017.o \
 # virtual gpu code
 i915-y += i915_vgpu.o

+# perf code
+i915-y += i915_perf.o
+
 # legacy horrors
 i915-y += i915_dma.o

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b377753..b62e269 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1039,6 +1039,11 @@ static int i915_driver_init_early(struct 
drm_i915_private *dev_priv,
if (ret < 0)
return ret;

+   /* Must at least be initialized before trying to pin any context
+* which i915_perf hooks into.
+*/
+   i915_perf_init(dev);
+
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev);

@@ -1425,6 +1430,8 @@ int i915_driver_unload(struct drm_device *dev)

i915_driver_unregister(dev_priv);

+   i915_perf_fini(dev);
+
drm_vblank_cleanup(dev);

intel_modeset_cleanup(dev);
@@ -1579,6 +1586,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };

 int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 85102ad..5a2a4d6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1708,6 +1708,79 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_perf_read_state {
+   int count;
+   ssize_t read;
+   char __user *buf;
+};
+
+struct i915_perf_stream {
+   struct drm_i915_private *dev_priv;
+
+   struct list_head link;
+
+   u32 sample_flags;
+
+   struct intel_context *ctx;
+   bool enabled;
+
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is something ready to read() for the stream
+*/
+   void (*poll_wait)(struct i915_perf_strea

[PATCH 0/9] Enable Gen 7 Observation Architecture

2016-04-20 Thread Robert Bragg
I've been working on some i-g-t tests for this new interface and while I still
have some more tests to write, it still seemed worth sending out another updated
series in the mean time.


Firstly this includes updates based on Emil's previous comments.

Then there have been a few issue hit while writing tests:

* It seems it can take a fairly long time for the MUX config to apply after
  the register writes have finished, and now the driver inserts a delay after
  configuration, before enabling periodic sampling.
* I've found that sometimes the HW tail pointer can get ahead of OA buffer
  writes, especially with higher sampling frequencies, and so now the driver
  maintains a margin behind the HW tail pointer to ensure the most recent
  reports have some time to land before attempting to copy them to userspace.
* As a sanity check that a report is valid before it's copied to userspace the
  driver checks the report-id field != 0
* The _BUFFER_OVERFLOW record has been replaced with a _BUFFER_LOST record with
  more specific semantics.
* Since we can't clear the overflow status on Haswell while periodic sampling
  is enabled, if an overflow occurs we now restart the unit.
* The maximum OA periodic sampling exponent is now 31
* We verify the head/tail pointers read back from HW look sane before using as
  offsets to read reports from the OA buffer. We reset the HW if they look bad.


For reference the work-in-progress i-g-t tests can be found here:

https://github.com/rib/intel-gpu-tools
branch = wip/rib/i915-perf-tests

or browsed here:
https://github.com/rib/intel-gpu-tools/commits/wip/rib/i915-perf-tests

Also for reference these patches can be fetched from here:

https://github.com/rib/linux
branch = wip/rib/oa-2016-04-19-nightly

Regards,
- Robert


Robert Bragg (9):
  drm/i915: Add i915 perf infrastructure
  drm/i915: rename OACONTROL GEN7_OACONTROL
  drm/i915: don't whitelist oacontrol in cmd parser
  drm/i915: Add 'render basic' Haswell OA unit config
  drm/i915: Enable i915 perf stream for Haswell OA unit
  drm/i915: advertise available metrics via sysfs
  drm/i915: Add dev.i915.perf_event_paranoid sysctl option
  drm/i915: add oa_event_min_timer_exponent sysctl
  drm/i915: Add more Haswell OA metric sets

 drivers/gpu/drm/i915/Makefile   |4 +
 drivers/gpu/drm/i915/i915_cmd_parser.c  |   33 +-
 drivers/gpu/drm/i915/i915_dma.c |8 +
 drivers/gpu/drm/i915/i915_drv.h |  155 
 drivers/gpu/drm/i915/i915_gem_context.c |   24 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c  |  658 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h  |   38 +
 drivers/gpu/drm/i915/i915_perf.c| 1439 +++
 drivers/gpu/drm/i915/i915_reg.h |  340 +++-
 include/uapi/drm/i915_drm.h |  133 +++
 10 files changed, 2795 insertions(+), 37 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

-- 
2.7.1



[PATCH] drm/vc4: Add missing render node support

2016-04-20 Thread Eric Anholt
There shouldn't be any other driver support necessary, since none of
the driver-specific ioctls ever required auth, and none of them deal
with modesetting.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 54f9f52fa004..143dd98aa079 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -81,6 +81,7 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_ATOMIC |
DRIVER_GEM |
DRIVER_HAVE_IRQ |
+   DRIVER_RENDER |
DRIVER_PRIME),
.lastclose = vc4_lastclose,
.irq_handler = vc4_irq,
-- 
2.8.0.rc3



[PATCH] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-04-20 Thread Vinay Simha
On Thu, Apr 14, 2016 at 8:10 PM, Archit Taneja  
wrote:
>
>
> On 4/13/2016 11:58 AM, Vinay Simha BN wrote:
>>
>> Add support for the JDI lt070me05000 WUXGA DSI panel used in
>> Nexus 7 2013 devices.
>>
>> Programming sequence for the panel is was originally found in the
>> android-msm-flo-3.4-lollipop-release branch from:
>>  https://android.googlesource.com/kernel/msm.git
>>
>> And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
>> file in:
>>  git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27
>>
>> Other fixes folded in were provided
>> by Archit Taneja 
>>
>> Signed-off-by: Vinay Simha BN 
>> [sumit.semwal: Ported to the drm/panel framework]
>> Signed-off-by: Sumit Semwal 
>> [jstultz: Cherry-picked to mainline, folded down other fixes
>>   from Vinay and Archit]
>> Signed-off-by: John Stultz 
>> ---
>>   .../bindings/display/panel/jdi,lt070me05000.txt|  27 +
>>   .../devicetree/bindings/vendor-prefixes.txt|   1 +
>>   drivers/gpu/drm/panel/Kconfig  |  11 +
>>   drivers/gpu/drm/panel/Makefile |   1 +
>>   drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 685
>> +
>>   5 files changed, 725 insertions(+)
>>   create mode 100644
>> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>>   create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> new file mode 100644
>> index 000..35c5ac7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> @@ -0,0 +1,27 @@
>> +JDI model LT070ME05000 1920x1200 7" DSI Panel
>> +
>> +Basic data sheet is at:
>> +
>> http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
>> +
>> +This panel has video mode implemented currently in the driver.
>> +
>> +Required properties:
>> +- compatible: should be "jdi,lt070me05000"
>> +
>> +Optional properties:
>> +- power-supply: phandle of the regulator that provides the supply voltage
>> +- reset-gpio: phandle of gpio for reset line
>> +- backlight: phandle of the backlight device attached to the panel
>> +
>> +Example:
>> +
>> +   dsi at 5430 {
>> +   panel: panel at 0 {
>> +   compatible = "jdi,lt070me05000";
>> +   reg = <0>;
>> +
>> +   power-supply = <...>;
>> +   reset-gpio = <...>;
>> +   backlight = <...>;
>> +   };
>> +   };
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index a580f3e..ec42bb4 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -130,6 +130,7 @@ invensense  InvenSense Inc.
>>   isee  ISEE 2007 S.L.
>>   isil  Intersil
>>   issi  Integrated Silicon Solutions Inc.
>> +jdiJapan Display Inc.
>>   jedec JEDEC Solid State Technology Association
>>   karo  Ka-Ro electronics GmbH
>>   keymile   Keymile GmbH
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 1500ab9..f41690e 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -61,6 +61,17 @@ config DRM_PANEL_SHARP_LQ101R1SX01
>>   To compile this driver as a module, choose M here: the module
>>   will be called panel-sharp-lq101r1sx01.
>>
>> +config DRM_PANEL_JDI_LT070ME05000
>> +   tristate "JDI LT070ME05000 WUXGA DSI panel"
>> +   depends on OF
>> +   depends on DRM_MIPI_DSI
>> +   depends on BACKLIGHT_CLASS_DEVICE
>> +   help
>> + Say Y here if you want to enable support for JDI WUXGA DSI
>> video/
>> + command mode panel as found in Google Nexus 7 (2013) devices.
>> + The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
>> + 24 bit RGB per pixel.
>> +
>>   config DRM_PANEL_SHARP_LS043T1LE01
>> tristate "Sharp LS043T1LE01 qHD video mode panel"
>> depends on OF
>> diff --git a/drivers/gpu/drm/panel/Makefile
>> b/drivers/gpu/drm/panel/Makefile
>> index f277eed..e6c6fc8 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -5,3 +5,4 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) +=
>> panel-samsung-ld9040.o
>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
>>   obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>>   obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>> +obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
>> diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
>> b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
>> new file mode 100644
>> index 000..051aa1b
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-

[PATCH] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-04-20 Thread Vinay Simha
On Wed, Apr 13, 2016 at 7:19 PM, Thierry Reding
 wrote:
> On Wed, Apr 13, 2016 at 11:58:04AM +0530, Vinay Simha BN wrote:
>> Add support for the JDI lt070me05000 WUXGA DSI panel used in
>> Nexus 7 2013 devices.
>>
>> Programming sequence for the panel is was originally found in the
>> android-msm-flo-3.4-lollipop-release branch from:
>> https://android.googlesource.com/kernel/msm.git
>>
>> And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
>> file in:
>> git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27
>>
>> Other fixes folded in were provided
>> by Archit Taneja 
>>
>> Signed-off-by: Vinay Simha BN 
>> [sumit.semwal: Ported to the drm/panel framework]
>> Signed-off-by: Sumit Semwal 
>> [jstultz: Cherry-picked to mainline, folded down other fixes
>>  from Vinay and Archit]
>> Signed-off-by: John Stultz 
>> ---
>>  .../bindings/display/panel/jdi,lt070me05000.txt|  27 +
>>  .../devicetree/bindings/vendor-prefixes.txt|   1 +
>>  drivers/gpu/drm/panel/Kconfig  |  11 +
>>  drivers/gpu/drm/panel/Makefile |   1 +
>>  drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 685 
>> +
>>  5 files changed, 725 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
>
> What's the difference between this and the patch you sent earlier? I'm
> going to assume that the newer one is the correct patch, so I'll ignore
> the previous patch.
>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
>> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> new file mode 100644
>> index 000..35c5ac7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>
> The binding documentation should be a separate patch.
>
>> @@ -0,0 +1,27 @@
>> +JDI model LT070ME05000 1920x1200 7" DSI Panel
>> +
>> +Basic data sheet is at:
>> + http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
>> +
>> +This panel has video mode implemented currently in the driver.
>
> That's information irrelevant to the DT binding, since you're presumably
> talking about the Linux drm/panel driver, whereas the DT binding is
> supposed to specify the description of the panel hardware in OS-agnostic
> terms.
>
>> +Required properties:
>> +- compatible: should be "jdi,lt070me05000"
>> +
>> +Optional properties:
>> +- power-supply: phandle of the regulator that provides the supply voltage
>> +- reset-gpio: phandle of gpio for reset line
>> +- backlight: phandle of the backlight device attached to the panel
>> +
>> +Example:
>> +
>> + dsi at 5430 {
>> + panel: panel at 0 {
>> + compatible = "jdi,lt070me05000";
>> + reg = <0>;
>> +
>> + power-supply = <...>;
>> + reset-gpio = <...>;
>> + backlight = <...>;
>> + };
>> + };
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index a580f3e..ec42bb4 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -130,6 +130,7 @@ invensenseInvenSense Inc.
>>  isee ISEE 2007 S.L.
>>  isil Intersil
>>  issi Integrated Silicon Solutions Inc.
>> +jdi  Japan Display Inc.
>>  jedecJEDEC Solid State Technology Association
>>  karo Ka-Ro electronics GmbH
>>  keymile  Keymile GmbH
>
> This should be a separate patch as well.
>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 1500ab9..f41690e 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -61,6 +61,17 @@ config DRM_PANEL_SHARP_LQ101R1SX01
>> To compile this driver as a module, choose M here: the module
>> will be called panel-sharp-lq101r1sx01.
>>
>> +config DRM_PANEL_JDI_LT070ME05000
>> + tristate "JDI LT070ME05000 WUXGA DSI panel"
>> + depends on OF
>> + depends on DRM_MIPI_DSI
>> + depends on BACKLIGHT_CLASS_DEVICE
>> + help
>> +   Say Y here if you want to enable support for JDI WUXGA DSI video/
>> +   command mode panel as found in Google Nexus 7 (2013) devices.
>> +   The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
>> +   24 bit RGB per pixel.
>> +
>>  config DRM_PANEL_SHARP_LS043T1LE01
>>   tristate "Sharp LS043T1LE01 qHD video mode panel"
>>   depends on OF
>
> Please keep these sorted alphabetically. I do realize that the list
> isn't sorted quite correctly at the moment, so you may as well leave
> this as-is and I'll fix up the order when applying and after fixing
> the current ordering.
>
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index f277eed

[PATCH] drm: Fix compilation on systems that don't provide O_CLOEXEC

2016-04-20 Thread Eric Engestrom
On Wed, Apr 20, 2016 at 03:49:19PM +0200, Stefan Dirsch wrote:
> Patch suggestion by Thomas Klausner . See
You might want to replace that with a valid email address, or remove it :)


[Bug 44647] [wine regression] Call of Duty 4: Intro videos renders garbage

2016-04-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=44647

--- Comment #4 from Sven Arvidsson  ---
Setting StrictDrawOrdering in Wine to enabled gets working videos again, but at
a severe performance cost.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/9cafb6d2/attachment.html>


[PATCH v2 4/4] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-04-20 Thread Vinay Simha BN
Add support for the JDI lt070me05000 WUXGA DSI panel used in
Nexus 7 2013 devices.

Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git

And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
file in:
git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27

Other fixes folded in were provided
by Archit Taneja 

Cc: Archit Taneja 
Signed-off-by: Vinay Simha BN 
[sumit.semwal: Ported to the drm/panel framework]
Signed-off-by: Sumit Semwal 
[jstultz: Cherry-picked to mainline, folded down other fixes
 from Vinay and Archit]
Signed-off-by: John Stultz 
[vinay simha bn: removed interface setting cmd mode, video
mode panel setting selection]
Signed-off-by: Vinay Simha BN 
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 506 +
 3 files changed, 518 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 1500ab9..4a6fcc2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -7,6 +7,17 @@ config DRM_PANEL
 menu "Display Panels"
depends on DRM && DRM_PANEL

+config DRM_PANEL_JDI_LT070ME05000
+   tristate "JDI LT070ME05000 WUXGA DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for JDI WUXGA DSI video
+ mode panel as found in Google Nexus 7 (2013) devices.
+ The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
+ 24 bit RGB per pixel.
+
 config DRM_PANEL_SIMPLE
tristate "support for simple panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f277eed..5d74ac2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
new file mode 100644
index 000..aeeba99
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -0,0 +1,506 @@
+/*
+ * Copyright (C) 2016 InforceComputing
+ * Author: Vinay Simha BN 
+ *
+ * Copyright (C) 2016 Linaro Ltd
+ * Author: Sumit Semwal 
+ *
+ * From internet archives, the panel for Nexus 7 2nd Gen, 2013 model is a
+ * JDI model LT070ME05000, and its data sheet is at:
+ * http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define PANEL_DEV_REGULATOR_MAX   3
+
+const char *regs[] = {
+   "power",
+   "vddp",
+   "dcdc_en"
+};
+
+struct jdi_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct regulator_bulk_data supplies[PANEL_DEV_REGULATOR_MAX];
+
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *enable_gpio;
+   struct gpio_desc *vcc_gpio;
+   struct gpio_desc *pwm_gpio;
+
+   /* TODO: Add backlight brightness support */
+   bool prepared;
+   bool enabled;
+
+   const struct drm_display_mode *mode;
+};
+
+static inline struct jdi_panel *to_jdi_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct jdi_panel, base);
+}
+
+static int jdi_panel_init(struct jdi_panel *jdi)
+{
+   struct mipi_dsi_device *dsi = jdi->dsi;
+   int ret;
+
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_soft_reset(dsi);
+   if (ret < 0)
+   return ret;
+
+   usleep_range(1, 2);
+
+   ret = mipi_dsi_dcs_set_pixel_format(dsi, 0x70);
+   if (ret < 0)
+   return ret;
+
+   ret = mipi_dsi_dcs_set_column_address(dsi, 0x, 0x04AF);
+   if (ret < 0)
+   return ret;
+
+   ret = mipi_dsi_dcs_set_page_address(dsi, 0x, 0x077F);
+   if (ret < 0)
+ 

[PATCH v2 3/4] drm/dsi: Implement set tear scanline

2016-04-20 Thread Vinay Simha BN
Provide a small convenience wrapper that transmits
a set_tear_scanline command.

Signed-off-by: Vinay Simha BN 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 22 ++
 include/drm/drm_mipi_dsi.h |  2 ++
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index f5d8083..26aba75 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -983,6 +983,28 @@ int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);

 /**
+ * mipi_dsi_set_tear_scanline() - turn on the display module's Tearing Effect
+ *output signal on the TE signal line when display module reaches line N
+ *defined by STS[n:0].
+ * @dsi: DSI peripheral device
+ * @param1: STS[10:8]
+ * @param2: STS[7:0]
+ * Return: 0 on success or a negative error code on failure
+ */
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi,
+ u8 param1, u8 param2)
+{
+u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, param1 , param2};
+ssize_t err;
+
+err = mipi_dsi_generic_write(dsi, &payload, sizeof(payload));
+if (err < 0)
+return err;
+
+return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_scanline);
+/**
  * mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
  *data used by the interface
  * @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7a9840f..37bd75d 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -263,6 +263,8 @@ int mipi_dsi_dcs_set_column_address(struct mipi_dsi_device 
*dsi, u16 start,
u16 end);
 int mipi_dsi_dcs_set_page_address(struct mipi_dsi_device *dsi, u16 start,
  u16 end);
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u8 param1,
+  u8 param2);
 int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
 int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 enum mipi_dsi_dcs_tear_mode mode);
-- 
2.1.2



[PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

2016-04-20 Thread Vinay Simha BN
Add documentation for lt070me05000 panel

Signed-off-by: Vinay Simha BN 
---
 .../bindings/display/panel/jdi,lt070me05000.txt| 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
new file mode 100644
index 000..ffe0550
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
@@ -0,0 +1,43 @@
+JDI model LT070ME05000 1200x1920 7" DSI Panel
+
+Required properties:
+- compatible: should be "jdi,lt070me05000"
+- power-supply: phandle of the regulator that provides the supply voltage
+  IOVCC , power supply for LCM (1.8V)
+- vddp-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply (3-5V)
+- dcdc_en-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply enable, High active
+- reset-gpio: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux and pinctrl.
+  XRES, Reset, Low active
+- enable-gpio: phandle of gpio for enable line
+  LED_EN, LED backlight enable, High active
+- vcc-gpio: phandle of regulator/gpio that provides the supply voltage
+  VDD, LED power supply (3-5V)
+
+Optional properties:
+- pwm-gpio: phandle of gpio/pwm
+  pwm backlight control, this should be mapped to the backlight level
+  display brightness (0x51)
+
+Example:
+
+   dsi0: qcom,mdss_dsi at 470 {
+   panel at 0 {
+   compatible = "jdi,lt070me05000";
+   reg = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&dsi_panel_pinctrl>;
+
+   power-supply = <&pm8921_lvs5>;
+   vddp-supply = <&pm8921_l17>;
+   dcdc_en-supply = <&pm8921_lvs7>;
+
+   reset-gpio = <&tlmm_pinmux 54 0>;
+   enable-gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
+   vcc-gpio = <&pm8921_gpio 23 GPIO_ACTIVE_HIGH>;
+
+   pwm-gpio = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
2.1.2



[PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event v4

2016-04-20 Thread Tomeu Vizoso
As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
updated is requested and there is an earlier updated pending".

v2: Use the status of the workqueue instead of vop->event, and don't add
a superfluous wait on the workqueue.

v3: Drop work_busy, as there's a sizeable delay when the worker
finishes, which introduces a race in which the client has already
received the last flip event but the next page flip ioctl will still
return -EBUSY because work_busy returns outdated information.

v4: Hold dev->event_lock while checking the VOP's event field as
suggested by Daniel Stone.

Signed-off-by: Tomeu Vizoso 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 19 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  6 ++
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 00d17d71aa4c..02ed8b78c939 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,6 +70,7 @@ int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
 void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
  int out_mode);
+bool rockchip_drm_crtc_has_pending_event(struct drm_crtc *crtc);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 3b8f652698f8..45cdc2859364 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -280,7 +280,24 @@ int rockchip_drm_atomic_commit(struct drm_device *dev,
 {
struct rockchip_drm_private *private = dev->dev_private;
struct rockchip_atomic_commit *commit = &private->commit;
-   int ret;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   unsigned long flags;
+   int i, ret;
+
+   if (async) {
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   spin_lock_irqsave(&dev->event_lock, flags);
+
+   if (crtc->state->event ||
+   rockchip_drm_crtc_has_pending_event(crtc)) {
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+   return -EBUSY;
+   }
+
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+   }
+   }

ret = drm_atomic_helper_prepare_planes(dev, state);
if (ret)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index a619f120f801..82e6f145f7a2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -850,6 +850,12 @@ int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
 }
 EXPORT_SYMBOL_GPL(rockchip_drm_crtc_mode_config);

+bool rockchip_drm_crtc_has_pending_event(struct drm_crtc *crtc)
+{
+   assert_spin_locked(&crtc->dev->event_lock);
+   return to_vop(crtc)->event;
+}
+
 static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
-- 
2.5.5



[PATCH v3 3/3] drm: bridge: anx78xx: Add anx78xx driver support.

2016-04-20 Thread Thierry Reding
On Mon, Apr 18, 2016 at 01:23:54PM +0200, Enric Balletbo i Serra wrote:
> On 14/04/16 15:10, Thierry Reding wrote:
> > On Fri, Apr 08, 2016 at 02:52:52PM +0200, Enric Balletbo i Serra wrote:
[...]
> > > + /* Map slave addresses of ANX7814 */
> > > + for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
> > > + anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter,
> > > + anx78xx_i2c_addresses[i] >> 1);
> > > + if (!anx78xx->i2c_dummy[i]) {
> > > + err = -ENOMEM;
> > > + DRM_ERROR("Failed to reserve i2c bus %02x.\n",
> > > +   anx78xx_i2c_addresses[i]);
> > > + goto err_unregister_i2c;
> > > + }
> > > +
> > > + anx78xx->map[i] = devm_regmap_init_i2c(anx78xx->i2c_dummy[i],
> > > +&anx78xx_regmap_config);
> > > + if (IS_ERR(anx78xx->map[i])) {
> > > + err = PTR_ERR(anx78xx->map[i]);
> > > + DRM_ERROR("Failed regmap initialization %02x.\n",
> > > +   anx78xx_i2c_addresses[i]);
> > > + goto err_unregister_i2c;
> > > + }
> > > + }
> > 
> > That's quite some overhead merely to use regmap... Perhaps there's room
> > to enhance regmap-i2c to support multiple addresses for the same device?
> > 
> 
> Yes it is, guess this is also used on other drivers, so will make sense
> enhance regmap-i2c, but let me do this on a future regmap-i2c patch series
> ;)

Yes, improving this in a follow-up patch seems fine, especially since
this already seems to be a common pattern.

I'll try to take a look at v4 hopefully within the week.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160420/40fdb0db/attachment.sig>


[PATCH 1/3 v6] drm: Introduce drm_connector_register_all() helper

2016-04-20 Thread Alexey Brodkin
Hi Daniel,

On Wed, 2016-04-20 at 13:28 +0200, Daniel Vetter wrote:
> On Tue, Apr 19, 2016 at 03:24:51PM +0300, Alexey Brodkin wrote:
> > 
> > As a pair to already existing drm_connector_unregister_all() we're adding
> > generic implementation of what is already done in some drivers.
> > 
> > Once this helper is implemented we'll be ready to switch existing
> > driver-specific implementations with the generic one.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: Boris Brezillon 
> > ---
> > 
> > No changes v5 -> v6.
> > 
> > Changes v4 -> v5:
> >  * Added missing mutex unlock on a fail path in 
> > drm_connector_register_all().
> >    Thanks David for his attention and patience!
> When resending, please add everyone who commmented on previous versions of
> your patches to the cc: list. Just to make sure they have a chance to look
> at the next version.

Sure I usually do that but looks like this time I completely forgot to add
more people in Cc.

-Alexey


[PATCH v2 5/5] dt-bindings: add documentation for Rockchip rk3399 display controllers

2016-04-20 Thread Mark Yao
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 

Signed-off-by: Mark Yao 
---
 .../bindings/display/rockchip/rockchip-vop.txt |5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index 196121f..6bf8473 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -8,6 +8,11 @@ Required properties:
 - compatible: value should be one of the following
"rockchip,rk3036-vop";
"rockchip,rk3288-vop";
+   "rockchip,rk3399-vop-big";
+   "rockchip,rk3399-vop-lit";
+Document compatible values for rk3399 display controllers.
+Big and little display controllers are not identical and have differing
+feature sets on the rk3399.

 - interrupts: should contain a list of all VOP IP block interrupts in the
 order: VSYNC, LCD_SYSTEM. The interrupt specifier
-- 
1.7.9.5




[PATCH] drm: Loongson-3 doesn't fully support wc memory

2016-04-20 Thread Huacai Chen
Cc: stable at vger.kernel.org

On Tue, Apr 19, 2016 at 9:53 PM, Alex Deucher  wrote:
> On Tue, Apr 19, 2016 at 7:19 AM, Huacai Chen  wrote:
>> Signed-off-by: Huacai Chen 
>
> Reviewed-by: Alex Deucher 
>
>> ---
>>  include/drm/drm_cache.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
>> index 461a055..cebecff 100644
>> --- a/include/drm/drm_cache.h
>> +++ b/include/drm/drm_cache.h
>> @@ -39,6 +39,8 @@ static inline bool drm_arch_can_wc_memory(void)
>>  {
>>  #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
>> return false;
>> +#elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
>> +   return false;
>>  #else
>> return true;
>>  #endif
>> --
>> 2.7.0
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 4/5] drm/rockchip: vop: add rk3399 vop support

2016-04-20 Thread Mark Yao
There are two VOP in rk3399 chip, respectively VOP_BIG and VOP_LIT.
most registers layout of this two vop is same, their framework are both
VOP_FULL, the Major differences of this two is that:

VOP_BIG max output resolution is 4096x2160.
VOP_LIT max output resolution is 2560x1600

VOP_BIG support four windows.
VOP_LIT only support two windows.

RK3399 vop register layout is similar with rk3288, so some feature
can reuse with rk3288.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   15 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |4 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   91 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  193 +++
 4 files changed, 298 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 59f24cd..5c9ff8e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -912,7 +912,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
u16 vsync_len = adjusted_mode->vsync_end - adjusted_mode->vsync_start;
u16 vact_st = adjusted_mode->vtotal - adjusted_mode->vsync_start;
u16 vact_end = vact_st + vdisplay;
-   uint32_t val;
+   uint32_t pin_pol, val;

vop_enable(crtc);
/*
@@ -951,21 +951,26 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
vop_dsp_hold_valid_irq_disable(vop);
}

-   val = 0x8;
-   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
-   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
-   VOP_CTRL_SET(vop, pin_pol, val);
+   pin_pol = 0x8;
+   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
+   pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
+   VOP_CTRL_SET(vop, pin_pol, pin_pol);
+
switch (s->output_type) {
case DRM_MODE_CONNECTOR_LVDS:
VOP_CTRL_SET(vop, rgb_en, 1);
+   VOP_CTRL_SET(vop, rgb_pin_pol, pin_pol);
break;
case DRM_MODE_CONNECTOR_eDP:
+   VOP_CTRL_SET(vop, edp_pin_pol, pin_pol);
VOP_CTRL_SET(vop, edp_en, 1);
break;
case DRM_MODE_CONNECTOR_HDMIA:
+   VOP_CTRL_SET(vop, hdmi_pin_pol, pin_pol);
VOP_CTRL_SET(vop, hdmi_en, 1);
break;
case DRM_MODE_CONNECTOR_DSI:
+   VOP_CTRL_SET(vop, mipi_pin_pol, pin_pol);
VOP_CTRL_SET(vop, mipi_en, 1);
break;
default:
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 28dafb6..ff4f52e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -49,6 +49,10 @@ struct vop_ctrl {
struct vop_reg dither_down;
struct vop_reg dither_up;
struct vop_reg pin_pol;
+   struct vop_reg rgb_pin_pol;
+   struct vop_reg hdmi_pin_pol;
+   struct vop_reg edp_pin_pol;
+   struct vop_reg mipi_pin_pol;

struct vop_reg htotal_pw;
struct vop_reg hact_st_end;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 6846868..6f42e56 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -278,11 +278,102 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
 };

+static const struct vop_ctrl rk3399_ctrl_data = {
+   .standby = VOP_REG(RK3399_SYS_CTRL, 0x1, 22),
+   .gate_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 23),
+   .rgb_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 12),
+   .hdmi_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 13),
+   .edp_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 14),
+   .mipi_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 15),
+   .dither_down = VOP_REG(RK3399_DSP_CTRL1, 0xf, 1),
+   .dither_up = VOP_REG(RK3399_DSP_CTRL1, 0x1, 6),
+   .data_blank = VOP_REG(RK3399_DSP_CTRL0, 0x1, 19),
+   .out_mode = VOP_REG(RK3399_DSP_CTRL0, 0xf, 0),
+   .rgb_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 16),
+   .hdmi_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 20),
+   .edp_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 24),
+   .mipi_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 28),
+   .htotal_pw = VOP_REG(RK3399_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
+   .hact_st_end = VOP_REG(RK3399_DSP_HACT_ST_END, 0x1fff1fff, 0),
+   .vtotal_pw = VOP_REG(RK3399_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
+   .vact_st_end = VOP_REG(RK3399_DSP_VACT_ST_END, 0x1fff1fff, 0),
+   .hpost_st_end = VOP_REG(RK3399_POST_DSP_HACT_INFO, 0x1fff1fff, 0),
+   .vpost_st_end = VOP_REG(RK3399_POST_DSP_VACT_INFO, 0x1fff1fff, 0),
+   .cfg_done = VOP_REG_MASK(RK3399_REG_CFG_DONE, 0x1, 0),
+};
+
+static const int rk3399_vop_intrs[] = {
+   FS_INTR,
+   

[PATCH v2 3/5] drm/rockchip: vop: introduce VOP_REG_MASK

2016-04-20 Thread Mark Yao
Some new vop register support mask, bit[16-31] is mask,
bit[0-15] is value, the mask is correspond to the value.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   45 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |9 +-
 3 files changed, 32 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 28596e7..59f24cd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -36,15 +36,18 @@
 #include "rockchip_drm_fb.h"
 #include "rockchip_drm_vop.h"

-#define __REG_SET_RELAXED(x, off, mask, shift, v) \
-   vop_mask_write_relaxed(x, off, (mask) << shift, (v) << shift)
-#define __REG_SET_NORMAL(x, off, mask, shift, v) \
-   vop_mask_write(x, off, (mask) << shift, (v) << shift)
+#define __REG_SET_RELAXED(x, off, mask, shift, v, write_mask) \
+   vop_mask_write(x, off, mask, shift, v, write_mask, true)
+
+#define __REG_SET_NORMAL(x, off, mask, shift, v, write_mask) \
+   vop_mask_write(x, off, mask, shift, v, write_mask, false)

 #define REG_SET(x, base, reg, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, reg.mask, reg.shift, v)
+   __REG_SET_##mode(x, base + reg.offset, \
+reg.mask, reg.shift, v, reg.write_mask)
 #define REG_SET_MASK(x, base, reg, mask, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, mask, reg.shift, v)
+   __REG_SET_##mode(x, base + reg.offset, \
+mask, reg.shift, v, reg.write_mask)

 #define VOP_WIN_SET(x, win, name, v) \
REG_SET(x, win->base, win->phy->name, v, RELAXED)
@@ -160,27 +163,25 @@ static inline uint32_t vop_read_reg(struct vop *vop, 
uint32_t base,
 }

 static inline void vop_mask_write(struct vop *vop, uint32_t offset,
- uint32_t mask, uint32_t v)
+ uint32_t mask, uint32_t shift, uint32_t v,
+ bool write_mask, bool relaxed)
 {
-   if (mask) {
-   uint32_t cached_val = vop->regsbak[offset >> 2];
-
-   cached_val = (cached_val & ~mask) | v;
-   writel(cached_val, vop->regs + offset);
-   vop->regsbak[offset >> 2] = cached_val;
-   }
-}
+   if (!mask)
+   return;

-static inline void vop_mask_write_relaxed(struct vop *vop, uint32_t offset,
- uint32_t mask, uint32_t v)
-{
-   if (mask) {
+   if (write_mask) {
+   v = (v << shift) | (mask << (shift + 16));
+   } else {
uint32_t cached_val = vop->regsbak[offset >> 2];

-   cached_val = (cached_val & ~mask) | v;
-   writel_relaxed(cached_val, vop->regs + offset);
-   vop->regsbak[offset >> 2] = cached_val;
+   v = (cached_val & ~(mask << shift)) | (v << shift);
+   vop->regsbak[offset >> 2] = v;
}
+
+   if (relaxed)
+   writel_relaxed(v, vop->regs + offset);
+   else
+   writel(v, vop->regs + offset);
 }

 static inline uint32_t vop_get_intr_type(struct vop *vop,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 071ff0b..28dafb6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -33,6 +33,7 @@ struct vop_reg {
uint32_t offset;
uint32_t shift;
uint32_t mask;
+   bool write_mask;
 };

 struct vop_ctrl {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index e75b2b8..6846868 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -23,7 +23,14 @@
 #define VOP_REG(off, _mask, s) \
{.offset = off, \
 .mask = _mask, \
-.shift = s,}
+.shift = s, \
+.write_mask = false,}
+
+#define VOP_REG_MASK(off, _mask, s) \
+   {.offset = off, \
+.mask = _mask, \
+.shift = s, \
+.write_mask = true,}

 static const uint32_t formats_win_full[] = {
DRM_FORMAT_XRGB,
-- 
1.7.9.5




[PATCH v2 2/5] dt-bindings: sort Rockchip vop compatible by chip's number

2016-04-20 Thread Mark Yao
Signed-off-by: Mark Yao 
---
 .../bindings/display/rockchip/rockchip-vop.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index 5489b59..196121f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -6,8 +6,8 @@ buffer to an external LCD interface.

 Required properties:
 - compatible: value should be one of the following
-   "rockchip,rk3288-vop";
"rockchip,rk3036-vop";
+   "rockchip,rk3288-vop";

 - interrupts: should contain a list of all VOP IP block interrupts in the
 order: VSYNC, LCD_SYSTEM. The interrupt specifier
-- 
1.7.9.5




[PATCH v2 1/5] drm/rockchip: sort registers define by chip's number

2016-04-20 Thread Mark Yao
No functional changes, sort the vop registers to make
code more readable.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  166 +--
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |   88 +++---
 2 files changed, 127 insertions(+), 127 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 3166b46..e75b2b8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,87 @@ static const uint32_t formats_win_lite[] = {
DRM_FORMAT_BGR565,
 };

+static const struct vop_scl_regs rk3066_win_scl = {
+   .scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+   .scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
+   .scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+   .scale_cbcr_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
+static const struct vop_win_phy rk3036_win0_data = {
+   .scl = &rk3066_win_scl,
+   .data_formats = formats_win_full,
+   .nformats = ARRAY_SIZE(formats_win_full),
+   .enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 0),
+   .format = VOP_REG(RK3036_SYS_CTRL, 0x7, 3),
+   .rb_swap = VOP_REG(RK3036_SYS_CTRL, 0x1, 15),
+   .act_info = VOP_REG(RK3036_WIN0_ACT_INFO, 0x1fff1fff, 0),
+   .dsp_info = VOP_REG(RK3036_WIN0_DSP_INFO, 0x0fff0fff, 0),
+   .dsp_st = VOP_REG(RK3036_WIN0_DSP_ST, 0x1fff1fff, 0),
+   .yrgb_mst = VOP_REG(RK3036_WIN0_YRGB_MST, 0x, 0),
+   .uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0x, 0),
+   .yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0x, 0),
+};
+
+static const struct vop_win_phy rk3036_win1_data = {
+   .data_formats = formats_win_lite,
+   .nformats = ARRAY_SIZE(formats_win_lite),
+   .enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 1),
+   .format = VOP_REG(RK3036_SYS_CTRL, 0x7, 6),
+   .rb_swap = VOP_REG(RK3036_SYS_CTRL, 0x1, 19),
+   .act_info = VOP_REG(RK3036_WIN1_ACT_INFO, 0x1fff1fff, 0),
+   .dsp_info = VOP_REG(RK3036_WIN1_DSP_INFO, 0x0fff0fff, 0),
+   .dsp_st = VOP_REG(RK3036_WIN1_DSP_ST, 0x1fff1fff, 0),
+   .yrgb_mst = VOP_REG(RK3036_WIN1_MST, 0x, 0),
+   .yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0x, 0),
+};
+
+static const struct vop_win_data rk3036_vop_win_data[] = {
+   { .base = 0x00, .phy = &rk3036_win0_data,
+ .type = DRM_PLANE_TYPE_PRIMARY },
+   { .base = 0x00, .phy = &rk3036_win1_data,
+ .type = DRM_PLANE_TYPE_CURSOR },
+};
+
+static const int rk3036_vop_intrs[] = {
+   DSP_HOLD_VALID_INTR,
+   FS_INTR,
+   LINE_FLAG_INTR,
+   BUS_ERROR_INTR,
+};
+
+static const struct vop_intr rk3036_intr = {
+   .intrs = rk3036_vop_intrs,
+   .nintrs = ARRAY_SIZE(rk3036_vop_intrs),
+   .status = VOP_REG(RK3036_INT_STATUS, 0xf, 0),
+   .enable = VOP_REG(RK3036_INT_STATUS, 0xf, 4),
+   .clear = VOP_REG(RK3036_INT_STATUS, 0xf, 8),
+};
+
+static const struct vop_ctrl rk3036_ctrl_data = {
+   .standby = VOP_REG(RK3036_SYS_CTRL, 0x1, 30),
+   .out_mode = VOP_REG(RK3036_DSP_CTRL0, 0xf, 0),
+   .pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+   .htotal_pw = VOP_REG(RK3036_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
+   .hact_st_end = VOP_REG(RK3036_DSP_HACT_ST_END, 0x1fff1fff, 0),
+   .vtotal_pw = VOP_REG(RK3036_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
+   .vact_st_end = VOP_REG(RK3036_DSP_VACT_ST_END, 0x1fff1fff, 0),
+   .cfg_done = VOP_REG(RK3036_REG_CFG_DONE, 0x1, 0),
+};
+
+static const struct vop_reg_data rk3036_vop_init_reg_table[] = {
+   {RK3036_DSP_CTRL1, 0x},
+};
+
+static const struct vop_data rk3036_vop = {
+   .init_table = rk3036_vop_init_reg_table,
+   .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
+   .ctrl = &rk3036_ctrl_data,
+   .intr = &rk3036_intr,
+   .win = rk3036_vop_win_data,
+   .win_size = ARRAY_SIZE(rk3036_vop_win_data),
+};
+
 static const struct vop_scl_extension rk3288_win_full_scl_ext = {
.cbcr_vsd_mode = VOP_REG(RK3288_WIN0_CTRL1, 0x1, 31),
.cbcr_vsu_mode = VOP_REG(RK3288_WIN0_CTRL1, 0x1, 30),
@@ -190,92 +271,11 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
 };

-static const struct vop_scl_regs rk3066_win_scl = {
-   .scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
-   .scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
-   .scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
-   .scale_cbcr_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 16),
-};
-
-static const struct vop_win_phy rk3036_win0_data = {
-   .scl = &rk3066_win_scl,
-   .data_formats = formats_win_full,
-   .nformats = ARRAY_SIZE(formats_win_full),
-   .enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 0),
-   .format = VOP_REG(RK3036_SYS_CTRL, 0x7, 3),
-   .rb_swap = VOP_REG(RK3036

[PATCH v2 0/5] drm/rockchip: add rk3399 display controller support

2016-04-20 Thread Mark Yao
This series of patches add support for rk3399 display crontroller(vop),

there are two VOP in rk3399 chip, respectively VOP_BIG and VOP_LIT.
most registers layout of this two vop is same, their framework are both
VOP_FULL, the differences of this two is VOP_LIT cut off some features.

Those patches tested on rk3399 evb board.

Changes in v2:
- sort the registers and vop compatible name
- spilt VOP_REG_MASK into a single patch
- make rk3399 vop documentation more readable(Heiko Stübner)

Mark Yao (5):
  drm/rockchip: sort registers define by chip's number
  dt-bindings: sort Rockchip vop compatible by chip's number
  drm/rockchip: vop: introduce VOP_REG_MASK
  drm/rockchip: vop: add rk3399 vop support
  dt-bindings: add documentation for Rockchip rk3399 display
controllers

 .../bindings/display/rockchip/rockchip-vop.txt |7 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|   60 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|5 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c|  236 -
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h|  279 +---
 5 files changed, 447 insertions(+), 140 deletions(-)

-- 
1.7.9.5




[PATCH] drm/panel: simple: Add support for Innolux AT070TN92

2016-04-20 Thread Boris Brezillon
From: Riccardo Bortolato 

Add support for the Innolux AT070TN92 panel.

Signed-off-by: Riccardo Bortolato 
---
 .../bindings/display/panel/innolux,at070tn92.txt   |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt
new file mode 100644
index 000..3e10cd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt
@@ -0,0 +1,7 @@
+Innolux AT070TN92 7.0" WQVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,at070tn92"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3649eb0..d321c57 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -822,6 +822,29 @@ static const struct panel_desc innolux_at043tn24 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

+static const struct drm_display_mode innolux_at070tn92_mode = {
+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 210,
+   .hsync_end = 800 + 210 + 20,
+   .htotal = 800 + 210 + 20 + 46,
+   .vdisplay = 480,
+   .vsync_start = 480 + 22,
+   .vsync_end = 480 + 22 + 10,
+   .vtotal = 480 + 22 + 23 + 10,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc innolux_at070tn92 = {
+   .modes = &innolux_at070tn92_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct drm_display_mode innolux_g121i1_l01_mode = {
.clock = 71000,
.hdisplay = 1280,
@@ -1362,6 +1385,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,at043tn24",
.data = &innolux_at043tn24,
}, {
+   .compatible = "innolux,at070tn92",
+   .data = &innolux_at070tn92,
+   }, {
.compatible ="innolux,g121i1-l01",
.data = &innolux_g121i1_l01
}, {
-- 
2.5.0



[PATCH] drm/ttm: fix kref count mess in ttm_bo_move_to_lru_tail

2016-04-20 Thread Alex Deucher
From: Flora Cui 

Fixes the following scenario:

1. Page table bo allocated in vram and linked to man->lru.
   tbo->list_kref.refcount=2
2. Page table bo is swapped out and removed from man->lru.
   tbo->list_kref.refcount=1
3. Command submission from userspace.  Page table bo is moved
   to vram.  ttm_bo_move_to_lru_tail() link it to man->lru and
   don't increase the kref count.

Signed-off-by: Flora Cui 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/ttm/ttm_bo.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 4cbf265..e3daafa 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -230,22 +230,13 @@ EXPORT_SYMBOL(ttm_bo_del_sub_from_lru);

 void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
 {
-   struct ttm_bo_device *bdev = bo->bdev;
-   struct ttm_mem_type_manager *man;
+   int put_count = 0;

lockdep_assert_held(&bo->resv->lock.base);

-   if (bo->mem.placement & TTM_PL_FLAG_NO_EVICT) {
-   list_del_init(&bo->swap);
-   list_del_init(&bo->lru);
-
-   } else {
-   if (bo->ttm && !(bo->ttm->page_flags & TTM_PAGE_FLAG_SG))
-   list_move_tail(&bo->swap, &bo->glob->swap_lru);
-
-   man = &bdev->man[bo->mem.mem_type];
-   list_move_tail(&bo->lru, &man->lru);
-   }
+   put_count = ttm_bo_del_from_lru(bo);
+   ttm_bo_list_ref_sub(bo, put_count, true);
+   ttm_bo_add_to_lru(bo);
 }
 EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);

-- 
2.5.5



[PATCH v2] drm: Make drm.debug parameter description more helpful

2016-04-20 Thread Ezequiel Garcia
Let's be user-friendly and print an actually helpful parameter
description.

This makes modinfo output the debug parameter like this:

parm:   debug:Enable debug output, where each bit enables a debug 
category.
Bit 0 (0x01) will enable CORE messages (drm core code)
Bit 1 (0x02) will enable DRIVER messages (drm controller code)
Bit 2 (0x04) will enable KMS messages (modesetting code)
Bit 3 (0x08) will enable PRIME messages (prime code)
Bit 4 (0x10) will enable ATOMIC messages (atomic code)
Bit 5 (0x20) will enable VBL messages (vblank code) (int)

Signed-off-by: Ezequiel Garcia 
--
Changes from v1:

  * Fixed s/PRMIE/PRIME typo.
  * Add ATOMIC and VBL debug parameter documentation.
  * Prefix the continuation lines with two tabs and
removed the last new line.
  * Remove spurious whitespace.

 drivers/gpu/drm/drm_drv.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 167c8d3d4a31..c4f45ac04ea4 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -37,13 +37,23 @@
 #include "drm_legacy.h"
 #include "drm_internal.h"

-unsigned int drm_debug = 0;/* bitmask of DRM_UT_x */
+/*
+ * drm_debug: Enable debug output.
+ * Bitmask of DRM_UT_x. See include/drm/drmP.h for details.
+ */
+unsigned int drm_debug = 0;
 EXPORT_SYMBOL(drm_debug);

 MODULE_AUTHOR(CORE_AUTHOR);
 MODULE_DESCRIPTION(CORE_DESC);
 MODULE_LICENSE("GPL and additional rights");
-MODULE_PARM_DESC(debug, "Enable debug output");
+MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug 
category.\n"
+"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
+"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
+"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
+"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
+"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
+"\t\tBit 5 (0x20) will enable VBL messages (vblank code)");
 module_param_named(debug, drm_debug, int, 0600);

 static DEFINE_SPINLOCK(drm_minor_lock);
-- 
2.7.0



[PATCH] drm/vc4: Add support for gamma ramps.

2016-04-20 Thread Eric Anholt
We could possibly save a bit of power by not requesting gamma
conversion when the ramp happens to be 1:1, but at least if all the
CRTCs are off the SRAM will be disabled.

This should fix brightness sliders in a lot of fullscreen games.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 58 ++
 drivers/gpu/drm/vc4/vc4_regs.h |  6 +
 2 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 355ee4b091b3..231356f42a04 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -49,6 +49,10 @@ struct vc4_crtc {
/* Which HVS channel we're using for our CRTC. */
int channel;

+   u8 lut_r[256];
+   u8 lut_g[256];
+   u8 lut_b[256];
+
struct drm_pending_vblank_event *event;
 };

@@ -147,6 +151,46 @@ static void vc4_crtc_destroy(struct drm_crtc *crtc)
drm_crtc_cleanup(crtc);
 }

+static void
+vc4_crtc_lut_load(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   u32 i;
+
+   /* The LUT memory is laid out with each HVS channel in order,
+* each of which takes 256 writes for R, 256 for G, then 256
+* for B.
+*/
+   HVS_WRITE(SCALER_GAMADDR,
+ SCALER_GAMADDR_AUTOINC |
+ (vc4_crtc->channel * 3 * crtc->gamma_size));
+
+   for (i = 0; i < crtc->gamma_size; i++)
+   HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_r[i]);
+   for (i = 0; i < crtc->gamma_size; i++)
+   HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_g[i]);
+   for (i = 0; i < crtc->gamma_size; i++)
+   HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_b[i]);
+}
+
+static void
+vc4_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
+  uint32_t start, uint32_t size)
+{
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   u32 i;
+
+   for (i = start; i < start + size; i++) {
+   vc4_crtc->lut_r[i] = r[i] >> 8;
+   vc4_crtc->lut_g[i] = g[i] >> 8;
+   vc4_crtc->lut_b[i] = b[i] >> 8;
+   }
+
+   vc4_crtc_lut_load(crtc);
+}
+
 static u32 vc4_get_fifo_full_level(u32 format)
 {
static const u32 fifo_len_bytes = 64;
@@ -260,8 +304,14 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)

HVS_WRITE(SCALER_DISPBKGNDX(vc4_crtc->channel),
  SCALER_DISPBKGND_AUTOHS |
+ SCALER_DISPBKGND_GAMMA |
  (interlace ? SCALER_DISPBKGND_INTERLACE : 0));

+   /* Reload the LUT, since the SRAMs would have been disabled if
+* all CRTCs had SCALER_DISPBKGND_GAMMA unset at once.
+*/
+   vc4_crtc_lut_load(crtc);
+
if (debug_dump_regs) {
DRM_INFO("CRTC %d regs after:\n", drm_crtc_index(crtc));
vc4_crtc_dump_regs(vc4_crtc);
@@ -613,6 +663,7 @@ static const struct drm_crtc_funcs vc4_crtc_funcs = {
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = vc4_crtc_duplicate_state,
.atomic_destroy_state = vc4_crtc_destroy_state,
+   .gamma_set = vc4_crtc_gamma_set,
 };

 static const struct drm_crtc_helper_funcs vc4_crtc_helper_funcs = {
@@ -711,6 +762,7 @@ static int vc4_crtc_bind(struct device *dev, struct device 
*master, void *data)
primary_plane->crtc = crtc;
vc4->crtc[drm_crtc_index(crtc)] = vc4_crtc;
vc4_crtc->channel = vc4_crtc->data->hvs_channel;
+   drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));

/* Set up some arbitrary number of planes.  We're not limited
 * by a set number of physical registers, just the space in
@@ -751,6 +803,12 @@ static int vc4_crtc_bind(struct device *dev, struct device 
*master, void *data)

vc4_set_crtc_possible_masks(drm, crtc);

+   for (i = 0; i < crtc->gamma_size; i++) {
+   vc4_crtc->lut_r[i] = i;
+   vc4_crtc->lut_g[i] = i;
+   vc4_crtc->lut_b[i] = i;
+   }
+
platform_set_drvdata(pdev, vc4_crtc);

return 0;
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index bf42a8e87111..6163b95c5411 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -390,6 +390,12 @@
 #define SCALER_DISPBASE20x006c
 #define SCALER_DISPALPHA2   0x0070
 #define SCALER_GAMADDR  0x0078
+# define SCALER_GAMADDR_AUTOINCBIT(31)
+/* Enables all gamma ramp SRAMs, not just those of CRTCs with gamma
+ * enabled.
+ */
+# define SCALER_GAMADDR_SRAMENBBIT(30)
+
 #define SCALER_GAMDATA  0x00e0
 #define SCALER_DLIST_START  0x2000
 #define SCALER_DLIST_SIZE   0x4000

[PATCH] drm: probe_helper: Hide ugly ifdef

2016-04-20 Thread Daniel Vetter
On Wed, Apr 20, 2016 at 12:24:16PM +0300, Jani Nikula wrote:
> On Tue, 19 Apr 2016, Ezequiel Garcia  wrote:
> > Push the ifdef to the drm_edid.h and create a stub, for the
> > DRM_LOAD_EDID_FIRMWARE=n case. This removes some clutter in
> > the code, making it more readable.
> >
> > Signed-off-by: Ezequiel Garcia 
> 
> Reviewed-by: Jani Nikula 

Applied to drm-misc, thanks.
-Daniel

> 
> 
> > ---
> >  drivers/gpu/drm/drm_probe_helper.c | 2 --
> >  include/drm/drm_edid.h | 8 
> >  2 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index e714b5a7955f..0329080d7f7c 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -264,10 +264,8 @@ int drm_helper_probe_single_connector_modes(struct 
> > drm_connector *connector,
> > count = drm_add_edid_modes(connector, edid);
> > drm_edid_to_eld(connector, edid);
> > } else {
> > -#ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
> > count = drm_load_edid_firmware(connector);
> > if (count == 0)
> > -#endif
> > count = (*connector_funcs->get_modes)(connector);
> > }
> >  
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 2af97691e878..5996598bc778 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -328,7 +328,15 @@ int drm_edid_to_speaker_allocation(struct edid *edid, 
> > u8 **sadb);
> >  int drm_av_sync_delay(struct drm_connector *connector,
> >   const struct drm_display_mode *mode);
> >  struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
> > +
> > +#ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
> >  int drm_load_edid_firmware(struct drm_connector *connector);
> > +#else
> > +static inline int drm_load_edid_firmware(struct drm_connector *connector)
> > +{
> > +   return 0;
> > +}
> > +#endif
> >  
> >  int
> >  drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Nouveau crashes in 4.6-rc on arm64

2016-04-20 Thread Alexandre Courbot
On 04/11/2016 04:22 PM, Alexandre Courbot wrote:
> Hi Robin,
>
> On 04/09/2016 03:46 AM, Robin Murphy wrote:
>> Hi Alex,
>>
>> On 08/04/16 05:47, Alexandre Courbot wrote:
>>> Hi Robin,
>>>
>>> On 04/07/2016 08:50 PM, Robin Murphy wrote:
 Hello,

 With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
 look of it by dereferencing some offset from NULL inside
 nouveau_fbcon_imageblit(). My setup is an old XFX 7600GT card plugged
 into an ARM Juno r1 board, which works fine with 4.5 and earlier.

 Attached are a couple of logs from booting arm64 defconfig plus DRM and
 Nouveau enabled - the second also has framebuffer console rotation
 turned on, which interestingly seems to move the point of failure, and
 the display does eventually come up to show the tail end of the
 panic in
 that case.

 I might be able to find time for a full bisection next week if isn't
 something sufficiently obvious to anyone who knows this driver.
>>>
>>> Looking at the log it is not clear to me what could be causing this. I
>>> can boot 4.6-rc2 with a GM206 card without any issue. A bisect would
>>> indeed be useful here.
>>
>> OK, turns out the lure of writing something to remotely drive a Juno and
>> parse kernel bootlogs through an automatic bisection was too great to
>> resist on a Friday afternoon :D
>>
>> Bisection came down to 1733a2ad3674("drm/nouveau/device/pci: set as
>> non-CPU-coherent on ARM64"), and sure enough reverting that removes the
>> crash.
>
> Thanks for taking the time to bisect this. And apologies as it seems my
> commit is the reason for your troubles.
>
> The CPU coherency flag is used for two things: explicitly sync buffers
> pages when required, and allocating buffers that are not explicitly
> synced (like fences or pushbuffers) using the DMA API. For this latter
> use, it also accesses the buffer's content using the mapping provided by
> dma_alloc_coherent() instead of creating a new one. All nouveau_bos are
> supposed to be written using nouveau_bo_rd32(), and this function
> handles the case of an DMA-API allocated object by detecting that the
> result of ttm_kmap_obj_virtual() is NULL.
>
> But as it turns out, OUT_RINGp() also calls ttm_kmap_obj_virtual() in
> order to perform a memcpy and uses its result directly - which means we
> are doing memcpy on a NULL pointer. We never caught this because we
> typically do not use Nouveau's fbcon with an ARM setup.
>
> I don't really like this special access for coherent objects, and
> actually had a patch in my tree to attempt to remove it (attached).
> Although it is not the whole solution (see below), the issue should at
> least not be visible with it applied - could you confirm?

Hi Robin, could you confirm whether the attached patch in my previous 
mail helps with your problem?

Thanks!



[Intel-gfx] [PATCH] drm: i915: Improve behavior in case of broken HDMI EDID

2016-04-20 Thread Daniel Vetter
On Tue, Apr 19, 2016 at 02:31:13PM -0300, Ezequiel Garcia wrote:
> Currently, our implementation of drm_connector_funcs.detect is
> based on getting a valid EDID.
> 
> This requirement makes the driver fail to detect connected
> connectors in case of EDID corruption, which in turn prevents
> from falling back to modes provided by builtin or user-provided
> EDIDs.

Imo, this should be fixed in the probe helpers. Something like the below
might make sense:


diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index e714b5a7955f..d3b9dc7535da 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -214,7 +214,10 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
else
connector->status = connector_status_disconnected;
if (connector->funcs->force)
-   connector->funcs->force(connector);
+   connector->funcs->force(connector);
+   } else if (connector->override_edid){
+   connector->status = connector_status_connected;
+   connector->funcs->force(connector);
} else {
connector->status = connector->funcs->detect(connector, true);
}


It should do what you want it to do, still allow us to override force
state manually and also fix things up for every, not just i915-hdmi. Also,
much smaller patch.

Only downside is that we need acks from other driver maintainers, since
essentially it's a behaviour change. Thus far you had to both inject the
edid and override status if your sink was totally busted. Now just
injecting edid will be enough.

Cheers, Daniel

> 
> Let's fix this by calling drm_probe_ddc in drm_connector_funcs.detect,
> and do the EDID full reading and parsing in
> drm_connector_helper_funcs.get_modes, when it's actually needed.
> 
> This patch allows i915 to take advantage of the DRM_LOAD_EDID_FIRMWARE
> infrastructure.
> 
> Without this patch, any device that fails to provide a valid
> EDID will be reported as disconnected (unless the state is forced)
> and thus the kernel won't allow to use such device with any mode,
> either builtin, user-provided, or the 1024x768 noedid fallback.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
> This patch supersedes: "drm/i915/hdmi: Fix weak connector detection",
> https://patchwork.freedesktop.org/patch/79098/.
> 
>  drivers/gpu/drm/i915/intel_hdmi.c | 59 
> ---
>  1 file changed, 36 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 616108c4bc3e..aa2f2271394a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1392,36 +1392,17 @@ intel_hdmi_detect(struct drm_connector *connector, 
> bool force)
>   enum drm_connector_status status;
>   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - bool live_status = false;
> - unsigned int try;
> -
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> -   connector->base.id, connector->name);
> + struct i2c_adapter *adap;
>  
>   intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>  
> - for (try = 0; !live_status && try < 9; try++) {
> - if (try)
> - msleep(10);
> - live_status = intel_digital_port_connected(dev_priv,
> - hdmi_to_dig_port(intel_hdmi));
> - }
> -
> - if (!live_status)
> - DRM_DEBUG_KMS("Live status not up!");
> -
> - intel_hdmi_unset_edid(connector);
> -
> - if (intel_hdmi_set_edid(connector, live_status)) {
> - struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> -
> - hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
> + adap = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> + if (drm_probe_ddc(adap))
>   status = connector_status_connected;
> - } else
> + else
>   status = connector_status_disconnected;
>  
>   intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
> -
>   return status;
>  }
>  
> @@ -1442,10 +1423,42 @@ intel_hdmi_force(struct drm_connector *connector)
>   hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
>  }
>  
> +static void intel_hdmi_detect_edid(struct drm_connector *connector)
> +{
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + bool live_status = false;
> + unsigned int try;
> +
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> +   connector->base.id, connector->name);
> +
> + intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
> +
> + for (try = 0; !live_status && try < 9; try++) {
> + if (try)
> +   

[PATCH 0/3 v6] drm: Introduce drm_connector_register_all() helper

2016-04-20 Thread Daniel Vetter
On Tue, Apr 19, 2016 at 03:24:50PM +0300, Alexey Brodkin wrote:
> As a pair to already existing drm_connector_unplug_all()
> (which we'll rename in this series to drm_connector_unregister_all())
> we're adding generic implementation of what is already done in some drivers
> for registering all connectors.
> 
> After implementation of that new helper we're updating 2 drivers
> that used to use it's own implementation:
>  [1] atmel_hlcdc
>  [2] rcar_du
> 
> Other drivers still use load() callback and so should be first modified so
> their load() gets called from their probe() explicitly.
> 
> Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x board).
> 
> Changes v5 -> v6:
>  * In atmel_hlcdc only substitute its own atmel_hlcdc_dc_connector_plug_all().
>drm_connector_unregister_all() is already used there since
>222b90943446 "drm/atmel: Fixup drm_connector_/unplug/unregister/_all"
> 
> Changes v4 -> v5:
>  * Added missing mutex unlock on a fail path in drm_connector_register_all()
>Thanks David for his attention and patience!
> 
> Changes v3 -> v4:
>  * Based on current drm-intel/topic/drm-misc
>It's now on commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
>And since thet new base already has
>"drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()"
>this series now only includes 3 subsequent patches.
> 
>  * In drm_connector_register_all() fail path which calls unregister_all()
>is moved outside of loop&locked section (as suggested by Daniel)
> 
> Changes v2 -> v3:
>  * Added acks for 1, 3 and 4 patches
>  * Updated kerneldoc descriptins of both register_ and unregister_all()
>  * Updated commit messages (mostly spellos and grammar issues)
> 
> Changes v1 -> v2:
>  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
>  * Use drm_for_each_connector() instead of list_for_each_entry()
>  * Updated kerneldoc for drm_dev_register()
> 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Boris Brezillon 
> Cc: Laurent Pinchart 
> Cc: linux-renesas-soc at vger.kernel.org
> Cc: David Herrmann 

All three applied to drm-misc, thanks.
-Daniel

> 
> Alexey Brodkin (3):
>   drm: Introduce drm_connector_register_all() helper
>   drm: atmel_hldc: Use generic drm_connector_register_all() helper
>   drm: rcar-du: Use generic drm_connector_register_all() helper
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 30 +
>  drivers/gpu/drm/drm_crtc.c   | 40 
> 
>  drivers/gpu/drm/drm_drv.c|  6 -
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c|  9 +--
>  include/drm/drm_crtc.h   |  3 ++-
>  5 files changed, 49 insertions(+), 39 deletions(-)
> 
> -- 
> 2.5.5
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH 1/3 v6] drm: Introduce drm_connector_register_all() helper

2016-04-20 Thread Daniel Vetter
On Tue, Apr 19, 2016 at 03:24:51PM +0300, Alexey Brodkin wrote:
> As a pair to already existing drm_connector_unregister_all() we're adding
> generic implementation of what is already done in some drivers.
> 
> Once this helper is implemented we'll be ready to switch existing
> driver-specific implementations with the generic one.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Boris Brezillon 
> ---
> 
> No changes v5 -> v6.
> 
> Changes v4 -> v5:
>  * Added missing mutex unlock on a fail path in drm_connector_register_all().
>Thanks David for his attention and patience!

When resending, please add everyone who commmented on previous versions of
your patches to the cc: list. Just to make sure they have a chance to look
at the next version.
-Daniel

> 
> Changes v3 -> v4:
>  * In drm_connector_register_all() fail path which calls unregister_all()
>is moved outside of loop&locked section (as suggested by Daniel)
> 
> Changes v2 -> v3:
>  * Updated title with capital after colon
>  * Simplified failure path with direct and unconditional invocation of
>unregister_all()
>  * Updated kerneldoc description of the drm_connector_register_all()
> 
> Changes v1 -> v2:
>  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
>  * Use drm_for_each_connector() instead of list_for_each_entry()
>  * Updated kerneldoc for drm_dev_register()
> 
>  drivers/gpu/drm/drm_crtc.c | 40 
>  drivers/gpu/drm/drm_drv.c  |  6 +-
>  include/drm/drm_crtc.h |  3 ++-
>  3 files changed, 47 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f7fe9e1..ee549a3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1068,6 +1068,46 @@ void drm_connector_unregister(struct drm_connector 
> *connector)
>  EXPORT_SYMBOL(drm_connector_unregister);
>  
>  /**
> + * drm_connector_register_all - register all connectors
> + * @dev: drm device
> + *
> + * This function registers all connectors in sysfs and other places so that
> + * userspace can start to access them. Drivers can call it after calling
> + * drm_dev_register() to complete the device registration, if they don't call
> + * drm_connector_register() on each connector individually.
> + *
> + * When a device is unplugged and should be removed from userspace access,
> + * call drm_connector_unregister_all(), which is the inverse of this
> + * function.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_connector_register_all(struct drm_device *dev)
> +{
> + struct drm_connector *connector;
> + int ret;
> +
> + mutex_lock(&dev->mode_config.mutex);
> +
> + drm_for_each_connector(connector, dev) {
> + ret = drm_connector_register(connector);
> + if (ret)
> + goto err;
> + }
> +
> + mutex_unlock(&dev->mode_config.mutex);
> +
> + return 0;
> +
> +err:
> + mutex_unlock(&dev->mode_config.mutex);
> + drm_connector_unregister_all(dev);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_connector_register_all);
> +
> +/**
>   * drm_connector_unregister_all - unregister connector userspace interfaces
>   * @dev: drm device
>   *
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 167c8d3..2c9a2b6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -715,7 +715,11 @@ EXPORT_SYMBOL(drm_dev_unref);
>   *
>   * Register the DRM device @dev with the system, advertise device to 
> user-space
>   * and start normal device operation. @dev must be allocated via 
> drm_dev_alloc()
> - * previously.
> + * previously. Right after drm_dev_register() the driver should call
> + * drm_connector_register_all() to register all connectors in sysfs. This is
> + * a separate call for backward compatibility with drivers still using
> + * the deprecated ->load() callback, where connectors are registered from 
> within
> + * the ->load() callback.
>   *
>   * Never call this twice on any device!
>   *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 6d46842..f9d2274 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2249,7 +2249,8 @@ static inline unsigned drm_connector_index(struct 
> drm_connector *connector)
>   return connector->connector_id;
>  }
>  
> -/* helper to unregister all connectors from sysfs for device */
> +/* helpers to {un}register all connectors from sysfs for device */
> +extern int drm_connector_register_all(struct drm_device *dev);
>  extern void drm_connector_unregister_all(struct drm_device *dev);
>  
>  extern int drm_bridge_add(struct drm_bridge *bridge);
> -- 
> 2.5.5
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


  1   2   >