[PATCH] drm: Add DRM_NOTICE_IF

[Emil Velikov]

On 28/07/15 14:14, Chris Wilson wrote:
> Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
> KERN_NOTICE for significant but mild events) that allows us to insert
> interesting events without alarming the user or bug reporting tools.
> 
Wouldn't it be better to opt for DRM_NOTICE_ON to be consistent with the
other two ? It sounds fine here, although I am a non-native English
speaker, so take it with a grain of salt.

Thanks
Emil

[PATCH] drm: Add DRM_NOTICE_IF

[Emil Velikov]

On 28/07/15 14:14, Chris Wilson wrote:
> Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
> KERN_NOTICE for significant but mild events) that allows us to insert
> interesting events without alarming the user or bug reporting tools.
> 
Wouldn't it be better to opt for DRM_NOTICE_ON to be consistent with the
other two ? It sounds fine here, although I am a non-native English
speaker, so take it with a grain of salt.

Thanks
Emil

[patch] drm/amdgpu: information leak in amdgpu_info_ioctl()

[Alex Deucher]

On Tue, Jul 28, 2015 at 11:51 AM, Dan Carpenter
 wrote:
> We recently changed the drm_amdgpu_info_device struct so now there is
> a 4 byte hole at the end.  We need to initialize it so we don't disclose
> secret information from the stack.
>
> Fixes: fa92754e9c47 ('drm/amdgpu: add VCE harvesting instance query')
> Signed-off-by: Dan Carpenter 

Applied.  thanks!

Alex

>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index d9de73a..81d60a9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -423,7 +423,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file
> return n ? -EFAULT : 0;
> }
> case AMDGPU_INFO_DEV_INFO: {
> -   struct drm_amdgpu_info_device dev_info;
> +   struct drm_amdgpu_info_device dev_info = {};
> struct amdgpu_cu_info cu_info;
>
> dev_info.device_id = dev->pdev->device;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND v2 06/25] drm/fb_helper: Create a wrapper for remove_conflicting_framebuffers

[Daniel Vetter]

On Tue, Jul 28, 2015 at 08:46:24PM +0200, Daniel Vetter wrote:
> On Wed, Jul 22, 2015 at 02:58:01PM +0530, Archit Taneja wrote:
> > Some drm drivers call remove_conflicting_framebuffers. Create a
> > drm_fb_helper function that wraps around these calls.
> > 
> > This is part of an effort to prevent drm drivers from calling fbdev
> > functions directly, in order to make fbdev emulation a top level drm
> > option.
> > 
> > v2:
> > - Added kerneldocs
> > - Follow the drm way of aligning of arguments in func definitions
> > 
> > Signed-off-by: Archit Taneja 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 15 +++
> >  include/drm/drm_fb_helper.h |  4 
> >  2 files changed, 19 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 9620aa5..86e4e2c 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -894,6 +894,21 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
> > *fb_helper, int state)
> >  }
> >  EXPORT_SYMBOL(drm_fb_helper_set_suspend);
> >  
> > +/**
> > + * drm_fb_helper_remove_conflicting_framebuffers - wrapper around
> > + * remove_conflicting_framebuffers
> > + * @fb_helper: driver-allocated fbdev helper
> > + *
> > + * A wrapper around remove_conflicting_framebuffers implemented by fbdev 
> > core
> > + */
> > +int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct 
> > *a,
> > + const char *name,
> > + bool primary)
> > +{
> > +   return remove_conflicting_framebuffers(a, name, primary);
> > +}
> > +EXPORT_SYMBOL(drm_fb_helper_remove_conflicting_framebuffers);
> 
> Chris Wilson reported on irc that if he builds with I915_FBDEV=n then
> there's a missing symbol problem here because i915 wants to kick out other
> framebuffers (well we have to for correctness) even when fbdev emulation
> is disabled. If you look at i915_dma.c you'll see that the call to
> remove_conflicting_framebuffers is conditional upon CONFIG_FB and not
> CONFIG_I915_FBDEV.
> 
> I think the proper solution here would be to provide a static inline
> helper for remove_conflicting_framebuffer itself when CONFIG_FB=n, since a
> all drivers who call this still want to call this even when fbdev
> emulation is disabled.
> 
> Plan B would be to move this into core drm and make the static inline one
> selected for CONFIG_FB=n. If you do that then maybe also rename it to
> drm_remove_conflicting_framebuffer since this really is only tangetial to
> fbdev emulation.
> 
> Anyway current patch unfortunately won't work since we really must remove
> other framebuffers even in the FB=y, I915_FBDEV=n case. So I dropped it
> from drm-misc for now. Unfortunately that means all the driver conversions
> won't apply anymore either :(

Ok I didn't have to drop all of the driver specific patches since all the
arm ones don't have calls to remove_conflicting_framebuffers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH RESEND v2 06/25] drm/fb_helper: Create a wrapper for remove_conflicting_framebuffers

[Daniel Vetter]

On Wed, Jul 22, 2015 at 02:58:01PM +0530, Archit Taneja wrote:
> Some drm drivers call remove_conflicting_framebuffers. Create a
> drm_fb_helper function that wraps around these calls.
> 
> This is part of an effort to prevent drm drivers from calling fbdev
> functions directly, in order to make fbdev emulation a top level drm
> option.
> 
> v2:
> - Added kerneldocs
> - Follow the drm way of aligning of arguments in func definitions
> 
> Signed-off-by: Archit Taneja 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 15 +++
>  include/drm/drm_fb_helper.h |  4 
>  2 files changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 9620aa5..86e4e2c 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -894,6 +894,21 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
> *fb_helper, int state)
>  }
>  EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>  
> +/**
> + * drm_fb_helper_remove_conflicting_framebuffers - wrapper around
> + *   remove_conflicting_framebuffers
> + * @fb_helper: driver-allocated fbdev helper
> + *
> + * A wrapper around remove_conflicting_framebuffers implemented by fbdev core
> + */
> +int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> +   const char *name,
> +   bool primary)
> +{
> + return remove_conflicting_framebuffers(a, name, primary);
> +}
> +EXPORT_SYMBOL(drm_fb_helper_remove_conflicting_framebuffers);

Chris Wilson reported on irc that if he builds with I915_FBDEV=n then
there's a missing symbol problem here because i915 wants to kick out other
framebuffers (well we have to for correctness) even when fbdev emulation
is disabled. If you look at i915_dma.c you'll see that the call to
remove_conflicting_framebuffers is conditional upon CONFIG_FB and not
CONFIG_I915_FBDEV.

I think the proper solution here would be to provide a static inline
helper for remove_conflicting_framebuffer itself when CONFIG_FB=n, since a
all drivers who call this still want to call this even when fbdev
emulation is disabled.

Plan B would be to move this into core drm and make the static inline one
selected for CONFIG_FB=n. If you do that then maybe also rename it to
drm_remove_conflicting_framebuffer since this really is only tangetial to
fbdev emulation.

Anyway current patch unfortunately won't work since we really must remove
other framebuffers even in the FB=y, I915_FBDEV=n case. So I dropped it
from drm-misc for now. Unfortunately that means all the driver conversions
won't apply anymore either :(

Thanks, Daniel
> +
>  static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>u16 blue, u16 regno, struct fb_info *info)
>  {
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index ef32500..cbdc69d 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -168,6 +168,10 @@ void drm_fb_helper_cfb_imageblit(struct fb_info *info,
>  
>  void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state);
>  
> +int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> +   const char *name,
> +   bool primary);
> +
>  int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>  
>  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 

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

[Bug 91480] Dead Island: Crash loading Act 3 possible shader issue

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91480

--- Comment #3 from Sven Arvidsson  ---
(In reply to Ilia Mirkin from comment #2)
> FWIW I can't reproduce the segfault by running through glsl_compiler. I do,
> however, get a
> 
> 0:35(1): error: #extension directive is not allowed in the middle of a shader
> 
> But that should be work-around-able with a driconf setting (or by running
> the game with allow_glsl_extension_directive_midshader=1 in the
> environment). When I move the #extension line up, no complaints (other than
> the unknown GL_ATI_draw_buffers thing), nothing in valgrind either.
> 
> Perhaps you can capture an apitrace of the issue?

Right, there's already a workaround for this game in drirc.

I can't really make out much from the backtrace, but at least for some of the
crashes the segfault seems to come from the game, probably because of the
failing shader?

You didn't get the syntax error?
0:209(3): error: syntax error, unexpected '='

I will try again with git master and try to capture a trace too,

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

[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91041

--- Comment #16 from Andreas Tunek  ---
Patch works for me.

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

[PATCH] drm/nouveau/fifo: fix simple_return.cocci warnings

[kbuild test robot]

drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c:372:1-4: WARNING: end returns 
can be simpified

 Simplify a trivial if-return sequence.  Possibly combine with a
 preceding function call.

Generated by: scripts/coccinelle/misc/simple_return.cocci

Signed-off-by: Fengguang Wu 
---

 gk104.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
@@ -369,11 +369,7 @@ gk104_fifo_context_ctor(struct nvkm_obje
nv_wo32(base, 0x0208, 0x);
nv_wo32(base, 0x020c, 0x00ff);

-   ret = nvkm_vm_ref(nvkm_client(parent)->vm, >vm, base->pgd);
-   if (ret)
-   return ret;
-
-   return 0;
+   return nvkm_vm_ref(nvkm_client(parent)->vm, >vm, base->pgd);
 }

 static void

drm/amdkfd: Add support for VI in DQM

[Dan Carpenter]

Hello Ben Goz,

The patch 914bea6329b2: "drm/amdkfd: Add support for VI in DQM" from
Jan 12, 2015, leads to the following static checker warning:

drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c:158 
init_sdma_vm()
warn: should this be a bitwise op?

drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
   148  static void init_sdma_vm(struct device_queue_manager *dqm, struct queue 
*q,
   149  struct qcm_process_device *qpd)
   150  {
   151  uint32_t value = (1 << SDMA0_RLC0_VIRTUAL_ADDR__ATC__SHIFT);
   152  
   153  if (q->process->is_32bit_user_mode)
   154  value |= (1 << SDMA0_RLC0_VIRTUAL_ADDR__PTR32__SHIFT) |
   155  get_sh_mem_bases_32(qpd_to_pdd(qpd));
   156  else
   157  value |= ((get_sh_mem_bases_nybble_64(qpd_to_pdd(qpd))) 
<<
   158  
SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &&

 ^^
Probably logical AND was intended.

   159  
SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE_MASK;
   160  
   161  q->properties.sdma_vm_addr = value;
   162  }

Also:

drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c:146
init_sdma_vm() warn: should this be a bitwise op?

drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
   136  static void init_sdma_vm(struct device_queue_manager *dqm, struct queue 
*q,
   137  struct qcm_process_device *qpd)
   138  {
   139  uint32_t value = (1 << SDMA0_RLC0_VIRTUAL_ADDR__ATC__SHIFT);
   140  
   141  if (q->process->is_32bit_user_mode)
   142  value |= (1 << SDMA0_RLC0_VIRTUAL_ADDR__PTR32__SHIFT) |
   143  get_sh_mem_bases_32(qpd_to_pdd(qpd));
   144  else
   145  value |= ((get_sh_mem_bases_nybble_64(qpd_to_pdd(qpd))) 
<<
   146  
SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &&

 ^
   147  
SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE_MASK;
   148  
   149  q->properties.sdma_vm_addr = value;
   150  }

regards,
dan carpenter

drm/amdgpu: add amdgpu <--> amdkfd gfx7 interface

[Dan Carpenter]

Hello Oded Gabbay,

The patch 32c22e994f44: "drm/amdgpu: add amdgpu <--> amdkfd gfx7
interface" from Jun 12, 2015, leads to the following static checker
warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c:453 kgd_hqd_destroy()
warn: bitwise AND condition is false here

drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
   439  static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t reset_type,
   440  unsigned int timeout, uint32_t pipe_id,
   441  uint32_t queue_id)
   442  {
   443  struct amdgpu_device *adev = get_amdgpu_device(kgd);
   444  uint32_t temp;
   445  
   446  acquire_queue(kgd, pipe_id, queue_id);
   447  WREG32(mmCP_HQD_PQ_DOORBELL_CONTROL, 0);
   448  
   449  WREG32(mmCP_HQD_DEQUEUE_REQUEST, reset_type);
   450  
   451  while (true) {
   452  temp = RREG32(mmCP_HQD_ACTIVE);
   453  if (temp & CP_HQD_ACTIVE__ACTIVE__SHIFT)
^^^
Never true.  ANDing against a shift is weird.  A zero shift is sort of
pointless, also.

   454  break;
   455  if (timeout == 0) {
   456  pr_err("kfd: cp queue preemption time out 
(%dms)\n",
   457  temp);
   458  release_queue(kgd);
   459  return -ETIME;
   460  }
   461  msleep(20);
   462  timeout -= 20;
   463  }
   464  
   465  release_queue(kgd);
   466  return 0;
   467  }

regards,
dan carpenter

[patch] drm/amdgpu: information leak in amdgpu_info_ioctl()

[Dan Carpenter]

We recently changed the drm_amdgpu_info_device struct so now there is
a 4 byte hole at the end.  We need to initialize it so we don't disclose
secret information from the stack.

Fixes: fa92754e9c47 ('drm/amdgpu: add VCE harvesting instance query')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index d9de73a..81d60a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -423,7 +423,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
return n ? -EFAULT : 0;
}
case AMDGPU_INFO_DEV_INFO: {
-   struct drm_amdgpu_info_device dev_info;
+   struct drm_amdgpu_info_device dev_info = {};
struct amdgpu_cu_info cu_info;

dev_info.device_id = dev->pdev->device;

[PATCH 2/2] drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

[Bjorn Andersson]

From: Werner Johansson 

This adds support for the Sharp panel found on the Qualcomm
Snapdragon 800 Dragonboard (APQ8074)

Signed-off-by: Werner Johansson 
Signed-off-by: Bjorn Andersson 
---
 drivers/gpu/drm/panel/Kconfig   |   9 +
 drivers/gpu/drm/panel/Makefile  |   1 +
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 387 
 3 files changed, 397 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6d64c7bb908b..7ee9c9aa857a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -43,4 +43,13 @@ 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_SHARP_LS043T1LE01
+   tristate "Sharp LS043T1LE01 qHD video mode 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 Sharp LS043T1LE01 qHD
+ (540x960) DSI panel as found on the Qualcomm APQ8074 Dragonboard
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4b2a0430804b..13ccdcc47e32 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
+obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
new file mode 100644
index ..481f4cdfc8ad
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -0,0 +1,387 @@
+/*
+ * Copyright (C) 2015 Red Hat
+ * Copyright (C) 2015 Sony Mobile Communications Inc.
+ * Author: Werner Johansson 
+ *
+ * Based on AUO panel driver by Rob Clark 
+ *
+ * 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 
+
+#include 
+
+struct sharp_nt_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+   struct gpio_desc *reset_gpio;
+
+   bool prepared;
+   bool enabled;
+
+   const struct drm_display_mode *mode;
+};
+
+static inline struct sharp_nt_panel *to_sharp_nt_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct sharp_nt_panel, base);
+}
+
+static int sharp_nt_panel_init(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+   if (ret < 0)
+   return ret;
+
+   msleep(120);
+
+   /* Novatek two-lane operation */
+   ret = mipi_dsi_dcs_write(dsi, 0xae, (u8[]){ 0x03 }, 1);
+   if (ret < 0)
+   return ret;
+
+   /* Set both MCU and RGB I/F to 24bpp */
+   ret = mipi_dsi_dcs_set_pixel_format(dsi, MIPI_DCS_PIXEL_FMT_24BIT |
+   (MIPI_DCS_PIXEL_FMT_24BIT << 4));
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static int sharp_nt_panel_on(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_set_display_on(dsi);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static int sharp_nt_panel_off(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_set_display_off(dsi);
+   if (ret < 0)
+   return ret;
+
+   ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+
+static int sharp_nt_panel_disable(struct drm_panel *panel)
+{
+   struct sharp_nt_panel *sharp_nt = to_sharp_nt_panel(panel);
+
+   if (!sharp_nt->enabled)
+

[PATCH 1/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

[Bjorn Andersson]

From: Werner Johansson 

Signed-off-by: Werner Johansson 
Signed-off-by: Bjorn Andersson 
---
 .../bindings/panel/sharp,ls043t1le01.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt

diff --git a/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt 
b/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
new file mode 100644
index ..758d48d33e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
@@ -0,0 +1,22 @@
+Sharp Microelectronics 4.3" qHD TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls043t1le01-qhd-vid"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- reset-gpios: a GPIO spec for the reset pin
+
+Example:
+
+   mdss_dsi0: qcom,mdss_dsi at fd922800 {
+   panel: panel at 0 {
+   compatible = "sharp,ls043t1le01-qhd-vid";
+   reg = <0>;
+   avdd-supply = <_l22>;
+   backlight = <_wled>;
+   reset-gpios = <_gpios 19 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
1.8.2.2

[PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()

[Chris Wilson]

On Tue, Jul 28, 2015 at 06:09:16PM +0100, Dave Gordon wrote:
> On 28/07/15 17:34, Chris Wilson wrote:
> >On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
> >>On 28/07/15 14:27, Chris Wilson wrote:
> >>>Since we already return -EFAULT to the user, emitting an error message
> >>>*and* WARN is overkill. If the caller is upset, they can do so, but for
> >>>the purposes of debugging we need only log the erroneous values.
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>Cc:: Alex Dai 
> >>>Cc: Dave Gordon 
> >>>Cc: Tom O'Rourke 
> >>>---
> >>>  drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >>>b/drivers/gpu/drm/i915/i915_gem.c
> >>>index c1ded76a6eb4..2039798f4403 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>@@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device 
> >>>*dev,
> >>>
> >>>   i915_gem_object_unpin_pages(obj);
> >>>
> >>>-  if (WARN_ON(bytes != size)) {
> >>>-  DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
> >>>+  if (bytes != size) {
> >>>+  DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
> >>>   ret = -EFAULT;
> >>>   goto fail;
> >>>   }
> >>
> >>I agree the WARN_ON() is overkill, but I think maybe the DRM_ERROR()
> >>is useful. The (one current) caller will report an error, but at
> >>that level it's just:
> >>
> >> DRM_ERROR("Failed to fetch GuC firmware from %s\n", ...)
> >>
> >>with no more detail as to whether that was due to file-not-found,
> >>bad-file-size, out-of-memory, failed-to-get-pages, or any of the
> >>other errors that might arise.
> >>
> >>At present this code is only called once, and I think this copy
> >>failure "shouldn't ever happen", so it won't be filling the logfile.
> >>But emitting the error here for the truly unexpected case (as
> >>opposed to the commonplace "out-of-memory" and suchlike) helps
> >>current and future callers avoid doing the detailed failure
> >>analysis.
> >
> >The message is still there though, it's just a debug message for the
> >developer. And all it could mean is that the caller passed in a bad
> >value for the size.
> >-Chris
> 
> I'm not sure you could trigger it with a bad size. The copy-target
> has just been allocated (in this function) and so is known to be the
> right size. If the size specified is larger than the data source
> buffer, the copy will likely have OOPSed anyway - or just continued
> with whatever happens to be next in memory.
> 
> So AFAICT the bytes vs. size mismatch can only happen if something
> is broken in the GEM (or SG-list) framework, hence worth announcing.
> If you reload the driver with debug enabled, it probably won't
> happen again (and you would have to reload, not just change the
> debug level, because at present this is only called during driver
> load).

Hmm, I was thinking that the access of data[size] would be checked and
the likely cause of the failure (thinking this was basically just
another copy_from_user check). I disagree that this one failure is any
more significant that any of the other internal failure cases then.

> If not an actual ERROR, then maybe a NOTICE is the right level:

No.

> DRM_NOTICE_IF(bytes != size,
> "Incomplete copy, wrote %zu of %zu", bytes, size);
> 
> so the the support engineer who sees the "failed to fetch" message
> in the log at least gets some hint about what particular weirdness
> has occurred on this occasion. (Other cases are easier: missing
> firmware file is obvious, wrong version gets a specific ERROR in the
> log; and these errors would be persistent. But a copy-fail would be
> a puzzle.)

That equally applies to a debug message. And even more so since EFAULT
here is unique. Under my assumption bytes would be recognisable in the
context of the caller, however if it ever happens it will be an equally
opaque value.

Given your arguments here, I think we should just remove it.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm: Detect no-op drmModeAtomicRequest and return early

[Chris Wilson]

On Tue, Jul 28, 2015 at 02:42:49PM +0100, Emil Velikov wrote:
> On 21 July 2015 at 13:50, Chris Wilson  wrote:
> > If the number of items to process in the request is zero, we can forgo
> > duplicating, sorting the request and feeding it into the kernel and
> > instead report success immediately.  This prevents a NULL dereference of
> > the sorted->items for the no-op request.
> >
> Why do you attempt a null/empty commit :P But seriously, nicely caught !

Nah, it was a silly static analysis tool that one time told the truth.

Pushed,
293f8fa..1a6efaf  1a6efaf68e207302cd9423051b8091fa663bbabe -> master
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()

[Dave Gordon]

On 28/07/15 17:34, Chris Wilson wrote:
> On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
>> On 28/07/15 14:27, Chris Wilson wrote:
>>> Since we already return -EFAULT to the user, emitting an error message
>>> *and* WARN is overkill. If the caller is upset, they can do so, but for
>>> the purposes of debugging we need only log the erroneous values.
>>>
>>> Signed-off-by: Chris Wilson 
>>> Cc:: Alex Dai 
>>> Cc: Dave Gordon 
>>> Cc: Tom O'Rourke 
>>> ---
>>>   drivers/gpu/drm/i915/i915_gem.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>>> b/drivers/gpu/drm/i915/i915_gem.c
>>> index c1ded76a6eb4..2039798f4403 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>> @@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device 
>>> *dev,
>>>
>>> i915_gem_object_unpin_pages(obj);
>>>
>>> -   if (WARN_ON(bytes != size)) {
>>> -   DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
>>> +   if (bytes != size) {
>>> +   DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
>>> ret = -EFAULT;
>>> goto fail;
>>> }
>>
>> I agree the WARN_ON() is overkill, but I think maybe the DRM_ERROR()
>> is useful. The (one current) caller will report an error, but at
>> that level it's just:
>>
>>  DRM_ERROR("Failed to fetch GuC firmware from %s\n", ...)
>>
>> with no more detail as to whether that was due to file-not-found,
>> bad-file-size, out-of-memory, failed-to-get-pages, or any of the
>> other errors that might arise.
>>
>> At present this code is only called once, and I think this copy
>> failure "shouldn't ever happen", so it won't be filling the logfile.
>> But emitting the error here for the truly unexpected case (as
>> opposed to the commonplace "out-of-memory" and suchlike) helps
>> current and future callers avoid doing the detailed failure
>> analysis.
>
> The message is still there though, it's just a debug message for the
> developer. And all it could mean is that the caller passed in a bad
> value for the size.
> -Chris

I'm not sure you could trigger it with a bad size. The copy-target has 
just been allocated (in this function) and so is known to be the right 
size. If the size specified is larger than the data source buffer, the 
copy will likely have OOPSed anyway - or just continued with whatever 
happens to be next in memory.

So AFAICT the bytes vs. size mismatch can only happen if something is 
broken in the GEM (or SG-list) framework, hence worth announcing. If you 
reload the driver with debug enabled, it probably won't happen again 
(and you would have to reload, not just change the debug level, because 
at present this is only called during driver load).

If not an actual ERROR, then maybe a NOTICE is the right level:

 DRM_NOTICE_IF(bytes != size,
 "Incomplete copy, wrote %zu of %zu", bytes, size);

so the the support engineer who sees the "failed to fetch" message in 
the log at least gets some hint about what particular weirdness has 
occurred on this occasion. (Other cases are easier: missing firmware 
file is obvious, wrong version gets a specific ERROR in the log; and 
these errors would be persistent. But a copy-fail would be a puzzle.)

.Dave.

[Bug 91463] radeon/audio:HDMI audio not working since upgrade from 3.19.3 to 4.0

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91463

--- Comment #1 from Alex Deucher  ---
Make sure your kernel has this patch:
https://bugs.freedesktop.org/attachment.cgi?id=116221

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

[Intel-gfx] [PATCH 1/3] drm/fbdev: Return -EBUSY when oopsing

[Daniel Vetter]

On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
> On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter  
> wrote:
> > Trying to do anything with kms drivers when oopsing has become a
> > failing proposition. But since we can end up in the fbdev code simply
> > due to the console unblanking that's done unconditionally just
> > removing our panic handler isn't enough. We need to block all fbdev
> > callbacks when oopsing.
> >
> > There was already one in the blank handler, but it failed silently.
> > That makes it impossible for drivers (like i915) who subclass these
> > functions to figure this out.
> >
> > Instead consistently return -EBUSY so that everyone knows that we
> > really don't want to be bothered right now. This also allows us to
> > remove a pile of FIXMEs from the i915 fbdev code (since due to the
> > failure code they now won't attempt to grab dangerous locks any more).
> 
> I guess drivers that were keeping fbdev buffer pinned just for opps'
> can stop doing that now..

Well there's still the kgdb stuff, but we might want to nuke that too.
Also fbdev assumes (at least afaik) that the mmap is always valid and it
just writes to it. At least that's why we have the fbdev_set_suspend call
to in suspend/resume to tell it that now it's really no longer cool to
draw fbcon. But userspace doesn't have anything like that I think.

> anyways, lgtm.. for the series:
> 
> Reviewed-by: Rob Clark 

Thanks for the review, all merged.
-Daniel

> 
> > Cc: Dave Airlie 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c| 24 
> >  drivers/gpu/drm/i915/intel_fbdev.c | 21 -
> >  2 files changed, 12 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 73f90f7e2f74..77f570a470da 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, 
> > int dpms_mode)
> > int i, j;
> >
> > /*
> > -* fbdev->blank can be called from irq context in case of a panic.
> > -* Since we already have our own special panic handler which will
> > -* restore the fbdev console mode completely, just bail out early.
> > -*/
> > -   if (oops_in_progress)
> > -   return;
> > -
> > -   /*
> >  * For each CRTC in this fb, turn the connectors on/off.
> >  */
> > drm_modeset_lock_all(dev);
> > @@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, 
> > int dpms_mode)
> >   */
> >  int drm_fb_helper_blank(int blank, struct fb_info *info)
> >  {
> > +   if (oops_in_progress)
> > +   return -EBUSY;
> > +
> > switch (blank) {
> > /* Display: On; HSync: On, VSync: On */
> > case FB_BLANK_UNBLANK:
> > @@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
> > fb_info *info)
> > int i, j, rc = 0;
> > int start;
> >
> > -   if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> > +   if (oops_in_progress)
> > return -EBUSY;
> > -   }
> > +
> > +   drm_modeset_lock_all(dev);
> > if (!drm_fb_helper_is_bound(fb_helper)) {
> > drm_modeset_unlock_all(dev);
> > return -EBUSY;
> > @@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
> > struct drm_fb_helper *fb_helper = info->par;
> > struct fb_var_screeninfo *var = >var;
> >
> > +   if (oops_in_progress)
> > +   return -EBUSY;
> > +
> > if (var->pixclock != 0) {
> > DRM_ERROR("PIXEL CLOCK SET\n");
> > return -EINVAL;
> > @@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo 
> > *var,
> > int ret = 0;
> > int i;
> >
> > -   if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> > +   if (oops_in_progress)
> > return -EBUSY;
> > -   }
> > +
> > +   drm_modeset_lock_all(dev);
> > if (!drm_fb_helper_is_bound(fb_helper)) {
> > drm_modeset_unlock_all(dev);
> > return -EBUSY;
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index eef54feb7545..b763f24e20ef 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
> > ret = drm_fb_helper_set_par(info);
> >
> > if (ret == 0) {
> > -   /*
> > -* FIXME: fbdev presumes that all callbacks also work from
> > -* atomic contexts and relies on that for emergency oops
> > -* printing. KMS totally doesn't do that and the locking 
> > here is
> > -* by far not the only place this goes wrong. 

[PATCH 14/14] drm/exynos: merge exynos_drm_buf.c to exynos_drm_gem.c

[Joonyoung Shim]

The struct exynos_drm_gem_obj can have fields of the struct
exynos_drm_gem_buf then don't need to use exynos_drm_buf.c file.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/Makefile   |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_buf.c   | 170 
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |  33 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  14 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   4 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  30 ++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 209 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |  40 +++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  10 +-
 9 files changed, 179 insertions(+), 334 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_buf.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_buf.h

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 95d0306..9c72535 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -5,8 +5,7 @@
 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
 exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
-   exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
-   exynos_drm_plane.o
+   exynos_drm_gem.o exynos_drm_core.o exynos_drm_plane.o

 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
deleted file mode 100644
index 9260dfb..000
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ /dev/null
@@ -1,170 +0,0 @@
-/* exynos_drm_buf.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * Author: Inki Dae 
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#include 
-#include 
-
-#include "exynos_drm_drv.h"
-#include "exynos_drm_gem.h"
-#include "exynos_drm_buf.h"
-#include "exynos_drm_iommu.h"
-
-static int lowlevel_buffer_allocate(struct drm_device *dev,
-   unsigned int flags, struct exynos_drm_gem_buf *buf)
-{
-   int ret = 0;
-   enum dma_attr attr;
-   unsigned int nr_pages;
-
-   if (buf->dma_addr) {
-   DRM_DEBUG_KMS("already allocated.\n");
-   return 0;
-   }
-
-   init_dma_attrs(>dma_attrs);
-
-   /*
-* if EXYNOS_BO_CONTIG, fully physically contiguous memory
-* region will be allocated else physically contiguous
-* as possible.
-*/
-   if (!(flags & EXYNOS_BO_NONCONTIG))
-   dma_set_attr(DMA_ATTR_FORCE_CONTIGUOUS, >dma_attrs);
-
-   /*
-* if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping
-* else cachable mapping.
-*/
-   if (flags & EXYNOS_BO_WC || !(flags & EXYNOS_BO_CACHABLE))
-   attr = DMA_ATTR_WRITE_COMBINE;
-   else
-   attr = DMA_ATTR_NON_CONSISTENT;
-
-   dma_set_attr(attr, >dma_attrs);
-   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, >dma_attrs);
-
-   nr_pages = buf->size >> PAGE_SHIFT;
-
-   if (!is_drm_iommu_supported(dev)) {
-   dma_addr_t start_addr;
-   unsigned int i = 0;
-
-   buf->pages = drm_calloc_large(nr_pages, sizeof(struct page *));
-   if (!buf->pages) {
-   DRM_ERROR("failed to allocate pages.\n");
-   return -ENOMEM;
-   }
-
-   buf->cookie = dma_alloc_attrs(dev->dev,
-   buf->size,
-   >dma_addr, GFP_KERNEL,
-   >dma_attrs);
-   if (!buf->cookie) {
-   DRM_ERROR("failed to allocate buffer.\n");
-   ret = -ENOMEM;
-   goto err_free;
-   }
-
-   start_addr = buf->dma_addr;
-   while (i < nr_pages) {
-   buf->pages[i] = phys_to_page(start_addr);
-   start_addr += PAGE_SIZE;
-   i++;
-   }
-   } else {
-
-   buf->pages = dma_alloc_attrs(dev->dev, buf->size,
-   >dma_addr, GFP_KERNEL,
-   >dma_attrs);
-   if (!buf->pages) {
-   DRM_ERROR("failed to allocate buffer.\n");
-   return -ENOMEM;
-   }
-   }
-
-   DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buf->dma_addr,
-   buf->size);
-
-   return ret;
-
-err_free:
-   

[PATCH 13/14] drm/exynos: use prime helpers

[Joonyoung Shim]

The dma-buf codes of exynos drm is almost same with prime helpers. A
difference is that consider DMA_NONE when import dma-buf, but it's wrong
and we don't consider it any more, so we can use prime interface.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/Makefile|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 289 -
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h |  20 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   9 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c|  79 
 drivers/gpu/drm/exynos/exynos_drm_gem.h|   9 +
 6 files changed, 95 insertions(+), 313 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 7de0b10..95d0306 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -6,7 +6,7 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
 exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
-   exynos_drm_plane.o exynos_drm_dmabuf.o
+   exynos_drm_plane.o

 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
deleted file mode 100644
index 619ecdd..000
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ /dev/null
@@ -1,289 +0,0 @@
-/* exynos_drm_dmabuf.c
- *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd.
- * Author: Inki Dae 
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#include 
-#include 
-#include "exynos_drm_dmabuf.h"
-#include "exynos_drm_drv.h"
-#include "exynos_drm_gem.h"
-
-#include 
-
-struct exynos_drm_dmabuf_attachment {
-   struct sg_table *sgt;
-   enum dma_data_direction dir;
-   bool is_mapped;
-};
-
-static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
-{
-   return to_exynos_gem_obj(buf->priv);
-}
-
-static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
-   struct device *dev,
-   struct dma_buf_attachment *attach)
-{
-   struct exynos_drm_dmabuf_attachment *exynos_attach;
-
-   exynos_attach = kzalloc(sizeof(*exynos_attach), GFP_KERNEL);
-   if (!exynos_attach)
-   return -ENOMEM;
-
-   exynos_attach->dir = DMA_NONE;
-   attach->priv = exynos_attach;
-
-   return 0;
-}
-
-static void exynos_gem_detach_dma_buf(struct dma_buf *dmabuf,
-   struct dma_buf_attachment *attach)
-{
-   struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
-   struct sg_table *sgt;
-
-   if (!exynos_attach)
-   return;
-
-   sgt = exynos_attach->sgt;
-   if (sgt) {
-   if (exynos_attach->dir != DMA_NONE)
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
-   exynos_attach->dir);
-   sg_free_table(sgt);
-   }
-
-   kfree(sgt);
-   kfree(exynos_attach);
-   attach->priv = NULL;
-}
-
-static struct sg_table *
-   exynos_gem_map_dma_buf(struct dma_buf_attachment *attach,
-   enum dma_data_direction dir)
-{
-   struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
-   struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
-   struct exynos_drm_gem_buf *buf;
-   struct sg_table *sgt;
-   int npages;
-
-   /* just return current sgt if already requested. */
-   if (exynos_attach->dir == dir && exynos_attach->is_mapped)
-   return exynos_attach->sgt;
-
-   buf = gem_obj->buffer;
-   if (!buf) {
-   DRM_ERROR("buffer is null.\n");
-   return ERR_PTR(-ENOMEM);
-   }
-
-   npages = buf->size >> PAGE_SHIFT;
-
-   sgt = drm_prime_pages_to_sg(buf->pages, npages);
-   if (IS_ERR(sgt))
-   goto err;
-
-   if (dir != DMA_NONE) {
-   if (!dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir)) {
-   DRM_ERROR("failed to map sgl with iommu.\n");
-   sg_free_table(sgt);
-   sgt = ERR_PTR(-EIO);
-   goto err;
-   }
-   }
-
-   exynos_attach->is_mapped = true;
-   exynos_attach->sgt = sgt;
-   exynos_attach->dir = dir;
-   attach->priv = exynos_attach;
-
-   

[PATCH 12/14] drm/exynos: remove function roundup_gem_size

[Joonyoung Shim]

The function roundup_gem_size can be merged in exynos_drm_gem_create.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 55c64cf..9df100f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -20,13 +20,6 @@
 #include "exynos_drm_buf.h"
 #include "exynos_drm_iommu.h"

-static unsigned long roundup_gem_size(unsigned long size, unsigned int flags)
-{
-   /* TODO */
-
-   return roundup(size, PAGE_SIZE);
-}
-
 static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
struct drm_file *file_priv,
unsigned int *handle)
@@ -153,7 +146,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
drm_device *dev,
return ERR_PTR(-EINVAL);
}

-   size = roundup_gem_size(size, flags);
+   size = roundup(size, PAGE_SIZE);

buf = exynos_drm_init_buf(dev, size);
if (!buf)
-- 
1.9.1

[PATCH 11/14] drm/exynos: remove function update_vm_cache_attr

[Joonyoung Shim]

The function update_vm_cache_attr can be merged in exynos_drm_gem_mmap.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 28 +++-
 1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 03e85d8..55c64cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -20,22 +20,6 @@
 #include "exynos_drm_buf.h"
 #include "exynos_drm_iommu.h"

-static void update_vm_cache_attr(struct exynos_drm_gem_obj *obj,
-   struct vm_area_struct *vma)
-{
-   DRM_DEBUG_KMS("flags = 0x%x\n", obj->flags);
-
-   /* non-cachable as default. */
-   if (obj->flags & EXYNOS_BO_CACHABLE)
-   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
-   else if (obj->flags & EXYNOS_BO_WC)
-   vma->vm_page_prot =
-   pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
-   else
-   vma->vm_page_prot =
-   pgprot_noncached(vm_get_page_prot(vma->vm_flags));
-}
-
 static unsigned long roundup_gem_size(unsigned long size, unsigned int flags)
 {
/* TODO */
@@ -580,7 +564,17 @@ int exynos_drm_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
goto err_close_vm;
}

-   update_vm_cache_attr(exynos_gem_obj, vma);
+   DRM_DEBUG_KMS("flags = 0x%x\n", exynos_gem_obj->flags);
+
+   /* non-cachable as default. */
+   if (exynos_gem_obj->flags & EXYNOS_BO_CACHABLE)
+   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+   else if (exynos_gem_obj->flags & EXYNOS_BO_WC)
+   vma->vm_page_prot =
+   pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+   else
+   vma->vm_page_prot =
+   pgprot_noncached(vm_get_page_prot(vma->vm_flags));

ret = exynos_drm_gem_mmap_buffer(exynos_gem_obj, vma);
if (ret)
-- 
1.9.1

[PATCH 10/14] drm/exynos: remove function check_gem_flags

[Joonyoung Shim]

The function check_gem_flags is too simple, so it's better to move codes
in each consumer functions.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index ab7d029..03e85d8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -20,16 +20,6 @@
 #include "exynos_drm_buf.h"
 #include "exynos_drm_iommu.h"

-static int check_gem_flags(unsigned int flags)
-{
-   if (flags & ~(EXYNOS_BO_MASK)) {
-   DRM_ERROR("invalid flags.\n");
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
 static void update_vm_cache_attr(struct exynos_drm_gem_obj *obj,
struct vm_area_struct *vma)
 {
@@ -169,6 +159,11 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
drm_device *dev,
struct exynos_drm_gem_buf *buf;
int ret;

+   if (flags & ~(EXYNOS_BO_MASK)) {
+   DRM_ERROR("invalid flags.\n");
+   return ERR_PTR(-EINVAL);
+   }
+
if (!size) {
DRM_ERROR("invalid size.\n");
return ERR_PTR(-EINVAL);
@@ -176,10 +171,6 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
drm_device *dev,

size = roundup_gem_size(size, flags);

-   ret = check_gem_flags(flags);
-   if (ret)
-   return ERR_PTR(ret);
-
buf = exynos_drm_init_buf(dev, size);
if (!buf)
return ERR_PTR(-ENOMEM);
@@ -584,9 +575,10 @@ int exynos_drm_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
obj = vma->vm_private_data;
exynos_gem_obj = to_exynos_gem_obj(obj);

-   ret = check_gem_flags(exynos_gem_obj->flags);
-   if (ret)
+   if (exynos_gem_obj->flags & ~(EXYNOS_BO_MASK)) {
+   DRM_ERROR("invalid flags.\n");
goto err_close_vm;
+   }

update_vm_cache_attr(exynos_gem_obj, vma);

-- 
1.9.1

[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()

[Joonyoung Shim]

The drm_gem_object_release() function already performs this cleanup,
so there is no reason to do it explicitly.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index c76aa8a..ab7d029 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -100,8 +100,6 @@ out:
exynos_drm_fini_buf(obj->dev, buf);
exynos_gem_obj->buffer = NULL;

-   drm_gem_free_mmap_offset(obj);
-
/* release file pointer to gem object. */
drm_gem_object_release(obj);

@@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)

 err_close_vm:
drm_gem_vm_close(vma);
-   drm_gem_free_mmap_offset(obj);

return ret;
 }
-- 
1.9.1

[PATCH 08/14] drm/exynos: create a fake mmap offset with gem creation

[Joonyoung Shim]

Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
not, it will call drm_gem_create_mmap_offset whenever user requests
DRM_IOCTL_MODE_MAP_DUMB ioctl.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 550d267..c76aa8a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -151,6 +151,13 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct 
drm_device *dev,
return ERR_PTR(ret);
}

+   ret = drm_gem_create_mmap_offset(obj);
+   if (ret < 0) {
+   drm_gem_object_release(obj);
+   kfree(exynos_gem_obj);
+   return ERR_PTR(ret);
+   }
+
DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);

return exynos_gem_obj;
@@ -521,14 +528,9 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
goto unlock;
}

-   ret = drm_gem_create_mmap_offset(obj);
-   if (ret)
-   goto out;
-
*offset = drm_vma_node_offset_addr(>vma_node);
DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);

-out:
drm_gem_object_unreference(obj);
 unlock:
mutex_unlock(>struct_mutex);
-- 
1.9.1

[PATCH 07/14] drm/exynos: use ERR_PTR instead of NULL in exynos_drm_gem_init

[Joonyoung Shim]

For more correct error information.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8fffc4d..550d267 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -139,7 +139,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct 
drm_device *dev,

exynos_gem_obj = kzalloc(sizeof(*exynos_gem_obj), GFP_KERNEL);
if (!exynos_gem_obj)
-   return NULL;
+   return ERR_PTR(-ENOMEM);

exynos_gem_obj->size = size;
obj = _gem_obj->base;
@@ -148,7 +148,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct 
drm_device *dev,
if (ret < 0) {
DRM_ERROR("failed to initialize gem object\n");
kfree(exynos_gem_obj);
-   return NULL;
+   return ERR_PTR(ret);
}

DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);
@@ -180,8 +180,8 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
drm_device *dev,
return ERR_PTR(-ENOMEM);

exynos_gem_obj = exynos_drm_gem_init(dev, size);
-   if (!exynos_gem_obj) {
-   ret = -ENOMEM;
+   if (IS_ERR(exynos_gem_obj)) {
+   ret = PTR_ERR(exynos_gem_obj);
goto err_fini_buf;
}

-- 
1.9.1

[PATCH 06/14] drm/exynos: remove unused fields of struct exynos_drm_gem_buf

[Joonyoung Shim]

The userptr, write and pfnmap of struct exynos_drm_gem_buf are not used
anywhere.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 5979f22..49b5ef1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -24,26 +24,19 @@
  *
  * @cookie: cookie returned by dma_alloc_attrs
  * @kvaddr: kernel virtual address to allocated memory region.
- * *userptr: user space address.
  * @dma_addr: bus address(accessed by dma) to allocated memory region.
  * - this address could be physical address without IOMMU and
  * device address with IOMMU.
- * @write: whether pages will be written to by the caller.
  * @pages: Array of backing pages.
  * @size: size of allocated memory region.
- * @pfnmap: indicate whether memory region from userptr is mmaped with
- * VM_PFNMAP or not.
  */
 struct exynos_drm_gem_buf {
void*cookie;
void __iomem*kvaddr;
-   unsigned long   userptr;
dma_addr_t  dma_addr;
struct dma_attrsdma_attrs;
-   unsigned intwrite;
struct page **pages;
unsigned long   size;
-   boolpfnmap;
 };

 /*
-- 
1.9.1

[PATCH 05/14] drm/exynos: stop copying sg table

[Joonyoung Shim]

Already struct exynos_drm_gem_buf has pages of the buffer, so we don't
need to copy from sg table of the buffer to sg table of dma-buf
attachment, just can make sg table from pages of the buffer.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 55 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c|  3 --
 drivers/gpu/drm/exynos/exynos_drm_gem.h|  2 --
 3 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index d10f9b6..619ecdd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -18,7 +18,7 @@
 #include 

 struct exynos_drm_dmabuf_attachment {
-   struct sg_table sgt;
+   struct sg_table *sgt;
enum dma_data_direction dir;
bool is_mapped;
 };
@@ -53,13 +53,15 @@ static void exynos_gem_detach_dma_buf(struct dma_buf 
*dmabuf,
if (!exynos_attach)
return;

-   sgt = _attach->sgt;
-
-   if (exynos_attach->dir != DMA_NONE)
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
-   exynos_attach->dir);
+   sgt = exynos_attach->sgt;
+   if (sgt) {
+   if (exynos_attach->dir != DMA_NONE)
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
+   exynos_attach->dir);
+   sg_free_table(sgt);
+   }

-   sg_free_table(sgt);
+   kfree(sgt);
kfree(exynos_attach);
attach->priv = NULL;
 }
@@ -70,16 +72,13 @@ static struct sg_table *
 {
struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
-   struct drm_device *dev = gem_obj->base.dev;
struct exynos_drm_gem_buf *buf;
-   struct scatterlist *rd, *wr;
-   struct sg_table *sgt = NULL;
-   unsigned int i;
-   int nents, ret;
+   struct sg_table *sgt;
+   int npages;

/* just return current sgt if already requested. */
if (exynos_attach->dir == dir && exynos_attach->is_mapped)
-   return _attach->sgt;
+   return exynos_attach->sgt;

buf = gem_obj->buffer;
if (!buf) {
@@ -87,42 +86,29 @@ static struct sg_table *
return ERR_PTR(-ENOMEM);
}

-   sgt = _attach->sgt;
+   npages = buf->size >> PAGE_SHIFT;

-   ret = sg_alloc_table(sgt, buf->sgt->orig_nents, GFP_KERNEL);
-   if (ret) {
-   DRM_ERROR("failed to alloc sgt.\n");
-   return ERR_PTR(-ENOMEM);
-   }
-
-   mutex_lock(>struct_mutex);
-
-   rd = buf->sgt->sgl;
-   wr = sgt->sgl;
-   for (i = 0; i < sgt->orig_nents; ++i) {
-   sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
-   rd = sg_next(rd);
-   wr = sg_next(wr);
-   }
+   sgt = drm_prime_pages_to_sg(buf->pages, npages);
+   if (IS_ERR(sgt))
+   goto err;

if (dir != DMA_NONE) {
-   nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
-   if (!nents) {
+   if (!dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir)) {
DRM_ERROR("failed to map sgl with iommu.\n");
sg_free_table(sgt);
sgt = ERR_PTR(-EIO);
-   goto err_unlock;
+   goto err;
}
}

exynos_attach->is_mapped = true;
+   exynos_attach->sgt = sgt;
exynos_attach->dir = dir;
attach->priv = exynos_attach;

DRM_DEBUG_PRIME("buffer size = 0x%lx\n", buf->size);

-err_unlock:
-   mutex_unlock(>struct_mutex);
+err:
return sgt;
 }

@@ -280,7 +266,6 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
}

exynos_gem_obj->buffer = buffer;
-   buffer->sgt = sgt;
exynos_gem_obj->base.import_attach = attach;

DRM_DEBUG_PRIME("dma_addr = %pad, size = 0x%lx\n", >dma_addr,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index cb5d9b6..8fffc4d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -455,9 +455,6 @@ void exynos_drm_gem_free_object(struct drm_gem_object *obj)
exynos_gem_obj = to_exynos_gem_obj(obj);
buf = exynos_gem_obj->buffer;

-   if (obj->import_attach)
-   drm_prime_gem_destroy(obj, buf->sgt);
-
exynos_drm_gem_destroy(to_exynos_gem_obj(obj));
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 6f42e22..5979f22 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -30,7 +30,6 @@
  * device address with IOMMU.
  * @write: whether 

[PATCH 04/14] drm/exynos: remove function exynos_drm_gem_map_buf

[Joonyoung Shim]

The exynos_drm_gem_map_buf can be merged in exynos_drm_gem_fault.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 36 +++--
 1 file changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 4741226..cb5d9b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -53,25 +53,6 @@ static unsigned long roundup_gem_size(unsigned long size, 
unsigned int flags)
return roundup(size, PAGE_SIZE);
 }

-static int exynos_drm_gem_map_buf(struct drm_gem_object *obj,
-   struct vm_area_struct *vma,
-   unsigned long f_vaddr,
-   pgoff_t page_offset)
-{
-   struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
-   struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
-   unsigned long pfn;
-
-   if (page_offset >= (buf->size >> PAGE_SHIFT)) {
-   DRM_ERROR("invalid page offset\n");
-   return -EINVAL;
-   }
-
-   pfn = page_to_pfn(buf->pages[page_offset]);
-
-   return vm_insert_mixed(vma, f_vaddr, pfn);
-}
-
 static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
struct drm_file *file_priv,
unsigned int *handle)
@@ -560,18 +541,25 @@ unlock:
 int exynos_drm_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
struct drm_gem_object *obj = vma->vm_private_data;
-   unsigned long f_vaddr;
+   struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
+   struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
+   unsigned long pfn;
pgoff_t page_offset;
int ret;

page_offset = ((unsigned long)vmf->virtual_address -
vma->vm_start) >> PAGE_SHIFT;
-   f_vaddr = (unsigned long)vmf->virtual_address;

-   ret = exynos_drm_gem_map_buf(obj, vma, f_vaddr, page_offset);
-   if (ret < 0)
-   DRM_ERROR("failed to map a buffer with user.\n");
+   if (page_offset >= (buf->size >> PAGE_SHIFT)) {
+   DRM_ERROR("invalid page offset\n");
+   ret = -EINVAL;
+   goto out;
+   }

+   pfn = page_to_pfn(buf->pages[page_offset]);
+   ret = vm_insert_mixed(vma, (unsigned long)vmf->virtual_address, pfn);
+
+out:
switch (ret) {
case 0:
case -ERESTARTSYS:
-- 
1.9.1

[PATCH 03/14] drm/exynos: remove mutex locking in pagefault handler

[Joonyoung Shim]

There is no reason to use mutex locking in pagefault handler.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 752cb7c..4741226 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -560,7 +560,6 @@ unlock:
 int exynos_drm_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
struct drm_gem_object *obj = vma->vm_private_data;
-   struct drm_device *dev = obj->dev;
unsigned long f_vaddr;
pgoff_t page_offset;
int ret;
@@ -569,14 +568,10 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
vma->vm_start) >> PAGE_SHIFT;
f_vaddr = (unsigned long)vmf->virtual_address;

-   mutex_lock(>struct_mutex);
-
ret = exynos_drm_gem_map_buf(obj, vma, f_vaddr, page_offset);
if (ret < 0)
DRM_ERROR("failed to map a buffer with user.\n");

-   mutex_unlock(>struct_mutex);
-
switch (ret) {
case 0:
case -ERESTARTSYS:
-- 
1.9.1

[PATCH 02/14] drm/exynos: remove function convert_to_vm_err_msg

[Joonyoung Shim]

The convert_to_vm_err_msg is called just once by exynos_drm_gem_fault,
so it's simple not to use the function.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 33 +
 1 file changed, 9 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index d320acd..752cb7c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -20,29 +20,6 @@
 #include "exynos_drm_buf.h"
 #include "exynos_drm_iommu.h"

-static unsigned int convert_to_vm_err_msg(int msg)
-{
-   unsigned int out_msg;
-
-   switch (msg) {
-   case 0:
-   case -ERESTARTSYS:
-   case -EINTR:
-   out_msg = VM_FAULT_NOPAGE;
-   break;
-
-   case -ENOMEM:
-   out_msg = VM_FAULT_OOM;
-   break;
-
-   default:
-   out_msg = VM_FAULT_SIGBUS;
-   break;
-   }
-
-   return out_msg;
-}
-
 static int check_gem_flags(unsigned int flags)
 {
if (flags & ~(EXYNOS_BO_MASK)) {
@@ -600,7 +577,15 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)

mutex_unlock(>struct_mutex);

-   return convert_to_vm_err_msg(ret);
+   switch (ret) {
+   case 0:
+   case -ERESTARTSYS:
+   return VM_FAULT_NOPAGE;
+   case -ENOMEM:
+   return VM_FAULT_OOM;
+   default:
+   return VM_FAULT_SIGBUS;
+   }
 }

 int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
-- 
1.9.1

[PATCH 01/14] drm/exynos: stop using sgtable in page fault handler

[Joonyoung Shim]

Already struct exynos_drm_gem_buf has pages of the buffer when buffer is
created, so just can use pages in page fault handler, we don't have to
make sgtable of the buffer. But this needs to construct pages of the
buffer that is imported from dma-buf prime.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c| 16 
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 18 ++
 drivers/gpu/drm/exynos/exynos_drm_gem.c| 14 +-
 3 files changed, 19 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 24994ba..9260dfb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -90,23 +90,12 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
}
}

-   buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages);
-   if (IS_ERR(buf->sgt)) {
-   DRM_ERROR("failed to get sg table.\n");
-   ret = PTR_ERR(buf->sgt);
-   goto err_free_attrs;
-   }
-
DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->dma_addr,
buf->size);

return ret;

-err_free_attrs:
-   dma_free_attrs(dev->dev, buf->size, buf->pages,
-   (dma_addr_t)buf->dma_addr, >dma_attrs);
-   buf->dma_addr = (dma_addr_t)NULL;
 err_free:
if (!is_drm_iommu_supported(dev))
drm_free_large(buf->pages);
@@ -126,11 +115,6 @@ static void lowlevel_buffer_deallocate(struct drm_device 
*dev,
(unsigned long)buf->dma_addr,
buf->size);

-   sg_free_table(buf->sgt);
-
-   kfree(buf->sgt);
-   buf->sgt = NULL;
-
if (!is_drm_iommu_supported(dev)) {
dma_free_attrs(dev->dev, buf->size, buf->cookie,
(dma_addr_t)buf->dma_addr, >dma_attrs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index cd485c0..d10f9b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -203,6 +203,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
struct scatterlist *sgl;
struct exynos_drm_gem_obj *exynos_gem_obj;
struct exynos_drm_gem_buf *buffer;
+   int npages;
int ret;

/* is this one of own objects? */
@@ -251,6 +252,20 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
buffer->size = dma_buf->size;
buffer->dma_addr = sg_dma_address(sgl);

+   npages = dma_buf->size >> PAGE_SHIFT;
+   buffer->pages = drm_malloc_ab(npages, sizeof(struct page *));
+   if (!buffer->pages) {
+   ret = -ENOMEM;
+   goto err_free_gem;
+   }
+
+   ret = drm_prime_sg_to_page_addr_arrays(sgt, buffer->pages, NULL,
+   npages);
+   if (ret < 0) {
+   drm_free_large(buffer->pages);
+   goto err_free_gem;
+   }
+
if (sgt->nents == 1) {
/* always physically continuous memory if sgt->nents is 1. */
exynos_gem_obj->flags |= EXYNOS_BO_CONTIG;
@@ -273,6 +288,9 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,

return _gem_obj->base;

+err_free_gem:
+   drm_gem_object_release(_gem_obj->base);
+   kfree(exynos_gem_obj);
 err_free_buffer:
kfree(buffer);
buffer = NULL;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 0d5b969..d320acd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -83,26 +83,14 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object 
*obj,
 {
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
-   struct scatterlist *sgl;
unsigned long pfn;
-   int i;
-
-   if (!buf->sgt)
-   return -EINTR;

if (page_offset >= (buf->size >> PAGE_SHIFT)) {
DRM_ERROR("invalid page offset\n");
return -EINVAL;
}

-   sgl = buf->sgt->sgl;
-   for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
-   if (page_offset < (sgl->length >> PAGE_SHIFT))
-   break;
-   page_offset -=  (sgl->length >> PAGE_SHIFT);
-   }
-
-   pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
+   pfn = page_to_pfn(buf->pages[page_offset]);

return vm_insert_mixed(vma, f_vaddr, pfn);
 }
-- 
1.9.1

[PATCH 00/14] drm/exynos: cleanup and update gem/dma-buf

[Joonyoung Shim]

This patchset improves gem and dma-buf codes of exynos drm.

Major changes:

- remove needless using sg table.
- use prime helpers instead of exynos specific dma-buf functions.
- merge struct exynos_drm_gem_buf in struct exynos_drm_gem.
- remove simple functions.
- cleanup.

Thanks.

Joonyoung Shim (14):
  drm/exynos: stop using sgtable in page fault handler
  drm/exynos: remove function convert_to_vm_err_msg
  drm/exynos: remove mutex locking in pagefault handler
  drm/exynos: remove function exynos_drm_gem_map_buf
  drm/exynos: stop copying sg table
  drm/exynos: remove unused fields of struct exynos_drm_gem_buf
  drm/exynos: use ERR_PTR instead of NULL in exynos_drm_gem_init
  drm/exynos: create a fake mmap offset with gem creation
  drm/exynos: remove call to drm_gem_free_mmap_offset()
  drm/exynos: remove function check_gem_flags
  drm/exynos: remove function update_vm_cache_attr
  drm/exynos: remove function roundup_gem_size
  drm/exynos: use prime helpers
  drm/exynos: merge exynos_drm_buf.c to exynos_drm_gem.c

 drivers/gpu/drm/exynos/Makefile|   3 +-
 drivers/gpu/drm/exynos/exynos_drm_buf.c| 186 ---
 drivers/gpu/drm/exynos/exynos_drm_buf.h|  33 ---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 286 --
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h |  20 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   9 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  14 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.h |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |  30 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c| 365 +
 drivers/gpu/drm/exynos/exynos_drm_gem.h|  58 ++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  10 +-
 12 files changed, 277 insertions(+), 741 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_buf.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_buf.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h

[PATCH v2] drm/exynos: clear channels only when iommu is enabled

[Joonyoung Shim]

This is simplest solution about reported problem[1]. It's no problem to
clear channel only when iommu is enabled, if we consider that we cannot
recognize iommu errors when iommu is disabled and it have been valid
until now. But this cannot be nice solution.

[1] https://lkml.org/lkml/2015/7/21/404

Reported-by: Krzysztof Kozlowski 
Signed-off-by: Joonyoung Shim 
---
v2: add Reported-by.

 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8d362b9..337af02 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -956,7 +956,8 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
if (ctx->display)
exynos_drm_create_enc_conn(drm_dev, ctx->display);

-   fimd_clear_channels(ctx->crtc);
+   if (is_drm_iommu_supported(drm_dev))
+   fimd_clear_channels(ctx->crtc);

ret = drm_iommu_attach_device(drm_dev, dev);
if (ret)
-- 
1.9.1

[PATCH] drm/exynos: clear channels only when iommu is enabled

[Joonyoung Shim]

On 07/28/2015 05:30 PM, Krzysztof Kozlowski wrote:
> On 28.07.2015 17:28, Joonyoung Shim wrote:
>> This is simplest solution about reported problem[1]. It's no problem to
>> clear channel only when iommu is enabled, if we consider that we cannot
>> recognize iommu errors when iommu is disabled and it have been valid
>> until now. But this cannot be nice solution.
> 
> I am not sure if I got it correctly. If this cannot be "nice solution"
> so is this a proper fix or not?
> 

Yeah, that clean channels always is more reasonable to me but now i
cannot give proper fix for that e.g. about clock problem.

> Anyway, please:
> Reported-by: Krzysztof Kozlowski 

Sure, Thanks.

[PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()

[Chris Wilson]

On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
> On 28/07/15 14:27, Chris Wilson wrote:
> >Since we already return -EFAULT to the user, emitting an error message
> >*and* WARN is overkill. If the caller is upset, they can do so, but for
> >the purposes of debugging we need only log the erroneous values.
> >
> >Signed-off-by: Chris Wilson 
> >Cc:: Alex Dai 
> >Cc: Dave Gordon 
> >Cc: Tom O'Rourke 
> >---
> >  drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index c1ded76a6eb4..2039798f4403 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device 
> >*dev,
> >
> > i915_gem_object_unpin_pages(obj);
> >
> >-if (WARN_ON(bytes != size)) {
> >-DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
> >+if (bytes != size) {
> >+DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
> > ret = -EFAULT;
> > goto fail;
> > }
> 
> I agree the WARN_ON() is overkill, but I think maybe the DRM_ERROR()
> is useful. The (one current) caller will report an error, but at
> that level it's just:
> 
> DRM_ERROR("Failed to fetch GuC firmware from %s\n", ...)
> 
> with no more detail as to whether that was due to file-not-found,
> bad-file-size, out-of-memory, failed-to-get-pages, or any of the
> other errors that might arise.
> 
> At present this code is only called once, and I think this copy
> failure "shouldn't ever happen", so it won't be filling the logfile.
> But emitting the error here for the truly unexpected case (as
> opposed to the commonplace "out-of-memory" and suchlike) helps
> current and future callers avoid doing the detailed failure
> analysis.

The message is still there though, it's just a debug message for the
developer. And all it could mean is that the caller passed in a bad
value for the size.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/exynos: clear channels only when iommu is enabled

[Krzysztof Kozlowski]

On 28.07.2015 17:28, Joonyoung Shim wrote:
> This is simplest solution about reported problem[1]. It's no problem to
> clear channel only when iommu is enabled, if we consider that we cannot
> recognize iommu errors when iommu is disabled and it have been valid
> until now. But this cannot be nice solution.

I am not sure if I got it correctly. If this cannot be "nice solution"
so is this a proper fix or not?

Anyway, please:
Reported-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

> 
> [1] https://lkml.org/lkml/2015/7/21/404
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 8d362b9..337af02 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -956,7 +956,8 @@ static int fimd_bind(struct device *dev, struct device 
> *master, void *data)
>   if (ctx->display)
>   exynos_drm_create_enc_conn(drm_dev, ctx->display);
>  
> - fimd_clear_channels(ctx->crtc);
> + if (is_drm_iommu_supported(drm_dev))
> + fimd_clear_channels(ctx->crtc);
>  
>   ret = drm_iommu_attach_device(drm_dev, dev);
>   if (ret)
> 

[PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()

[Dave Gordon]

On 28/07/15 14:27, Chris Wilson wrote:
> Since we already return -EFAULT to the user, emitting an error message
> *and* WARN is overkill. If the caller is upset, they can do so, but for
> the purposes of debugging we need only log the erroneous values.
>
> Signed-off-by: Chris Wilson 
> Cc:: Alex Dai 
> Cc: Dave Gordon 
> Cc: Tom O'Rourke 
> ---
>   drivers/gpu/drm/i915/i915_gem.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c1ded76a6eb4..2039798f4403 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device *dev,
>
>   i915_gem_object_unpin_pages(obj);
>
> - if (WARN_ON(bytes != size)) {
> - DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
> + if (bytes != size) {
> + DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
>   ret = -EFAULT;
>   goto fail;
>   }

I agree the WARN_ON() is overkill, but I think maybe the DRM_ERROR() is 
useful. The (one current) caller will report an error, but at that level 
it's just:

 DRM_ERROR("Failed to fetch GuC firmware from %s\n", ...)

with no more detail as to whether that was due to file-not-found, 
bad-file-size, out-of-memory, failed-to-get-pages, or any of the other 
errors that might arise.

At present this code is only called once, and I think this copy failure 
"shouldn't ever happen", so it won't be filling the logfile. But 
emitting the error here for the truly unexpected case (as opposed to the 
commonplace "out-of-memory" and suchlike) helps current and future 
callers avoid doing the detailed failure analysis.

Or maybe it's a good place for your (other) new macro?

DRM_NOTICE_ON(bytes != size,
"Incomplete copy, wrote %zu of %zu", bytes, size);

.Dave.

[PATCH] drm/exynos: clear channels only when iommu is enabled

[Joonyoung Shim]

This is simplest solution about reported problem[1]. It's no problem to
clear channel only when iommu is enabled, if we consider that we cannot
recognize iommu errors when iommu is disabled and it have been valid
until now. But this cannot be nice solution.

[1] https://lkml.org/lkml/2015/7/21/404

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8d362b9..337af02 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -956,7 +956,8 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
if (ctx->display)
exynos_drm_create_enc_conn(drm_dev, ctx->display);

-   fimd_clear_channels(ctx->crtc);
+   if (is_drm_iommu_supported(drm_dev))
+   fimd_clear_channels(ctx->crtc);

ret = drm_iommu_attach_device(drm_dev, dev);
if (ret)
-- 
1.9.1

[Nouveau] [PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

[Ben Skeggs]

On 28 July 2015 at 01:52, Hans de Goede  wrote:
> Hi,
>
> On 24-07-15 04:32, Ben Skeggs wrote:
>>
>> On 24 July 2015 at 01:20, Hans de Goede  wrote:
>>>
>>> MSI interrupts appear to not work for nv46 based cards. Change the mc
>>> subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is
>>> identical to the nv44 mc code except that it does not use msi
>>> (it does not define a msi_rearm callback).
>>
>> I'm fine with this, but it'd be nice to check that the binary driver
>> doesn't/can't use MSI on these too (there might be an alternate method
>> we need to use).
>>
>> Would you be able to grab the latest proprietary driver that works on
>> nv4x, and do a mmiotrace of it?
>
>
> I've grabbed 304.125
>
>> You *might* need to use "modprobe
>> nvidia NVreg_EnableMSI=1", because at some point NVIDIA didn't use it
>> by default anywhere.
>
>
> You're right I needed to specify NVreg_EnableMSI=1, with that set
> /proc/interrupts shows that MSI is used.
>
> Here is an of running glxgears with the binary driver using msi interrupts
> mmiotrace:
>
> https://fedorapeople.org/~jwrdegoede/nvidia-bin-nv46-msi-on-glxgears.mmiotrace.gz
>
> AFAIK there are some nouveau tools to parse this a bit, right ? I'm going
> to call it a day for today, if you can give me some pointers what to do with
> the
> mmiotrace to find a potential fix for the msi issues, that would be
> appreciated.
>
>
> BTW I had to build my own kernel with mmiotrace enabled in Kconfig, as this
> is disabled in the Fedora kernels by default. Do you know if there is a good
> reason to have this disabled by default, or should I ask the Fedora
> kernel maintainers to enable it by default ?
The -debug kernel has it enabled already.  However, it's also
problematic in that it enables various lockdep debugging stuff that
causes the binary driver kernel module to end up depending on GPL-only
symbols, which you have to hack around by changing the
MODULE_LICENSE() for the binary driver to "GPL"... Which is clearly a
pain :)  So, I guess if you want a slightly more straight-forward
approach, it'd be good to enable in the non-debug kernels too.

>
>
> Slightly offtopic:
>
> I decided to be bold and try gnome-shell on the nv46 with msi disabled,
> which sofar was a guaranteed way to freeze the system, and it now works
> somewhat (latest kernel, ddx and mesa). I see something which shows
> horizontal lines which are small parts from my desktop background, and
> things change significantly when I switch to the overview mode.
>
> But other then that the display is completely wrong, it looks a bit
> like a framebuffer pitch problem, but then different. I think it
> is likely some tiling problem or some such.
>
> Note that metacity + glxgears works, this only shows with
> gnome-shell, any hints where to start looking wrt debugging this?
These are the main issues that I'd like to see resolved :)

>
> Or should I first try to run piglet and see if some tests there
> point out the culprit?
I think this is a good place to start.

Thanks,
Ben.

>
>
> Regards,
>
> Hans
>
>
>
>>
>> Thanks,
>> Ben.
>>
>>> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90435
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>   drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c
>>> b/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c
>>> index c630136..b4ad791 100644
>>> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c
>>> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c
>>> @@ -265,7 +265,7 @@ nv40_identify(struct nvkm_device *device)
>>>  device->oclass[NVDEV_SUBDEV_CLK] = _clk_oclass;
>>>  device->oclass[NVDEV_SUBDEV_THERM  ] =
>>> _therm_oclass;
>>>  device->oclass[NVDEV_SUBDEV_DEVINIT] =
>>> nv1a_devinit_oclass;
>>> -   device->oclass[NVDEV_SUBDEV_MC ] =  nv44_mc_oclass;
>>> +   device->oclass[NVDEV_SUBDEV_MC ] =  nv4c_mc_oclass;
>>>  device->oclass[NVDEV_SUBDEV_BUS] =  nv31_bus_oclass;
>>>  device->oclass[NVDEV_SUBDEV_TIMER  ] =
>>> _timer_oclass;
>>>  device->oclass[NVDEV_SUBDEV_FB ] =  nv46_fb_oclass;
>>> --
>>> 2.4.3
>>>
>>> ___
>>> Nouveau mailing list
>>> Nouveau at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH v2 4/4] drm/doc: Convert to markdown

[Danilo Cesar Lemes de Paula]

DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.

* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
  drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore

* drivers/gpu/drm/drm_modeset_lock.c: had a code example that used
  to look pretty bad on html. Fixed by using proper code markup.

* drivers/gpu/drm/drm_prime.c: Remove spaces between lines to make
  a proper markup list.

* drivers/gpu/drm/i915/i915_reg.h: Altought pandoc supports tables,
  it doesn't support table cell spanning. But we can use fixed-width
  for those special cases.

* include/drm/drm_vma_manager.h: Another code example that should be
  proper indented with four spaces.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 Changelog:
  v2:
* Improve markup in drivers/gpu/drm/drm_modes.c

 Documentation/DocBook/Makefile |  2 +-
 Documentation/DocBook/drm.tmpl | 86 --
 drivers/gpu/drm/drm_modes.c| 12 +++---
 drivers/gpu/drm/drm_modeset_lock.c | 14 +++
 drivers/gpu/drm/drm_prime.c| 16 +++
 drivers/gpu/drm/i915/i915_reg.h| 48 ++---
 include/drm/drm_vma_manager.h  | 10 ++---
 7 files changed, 48 insertions(+), 140 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 8e6d022..f2408b3 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -17,7 +17,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml

-MARKDOWNREADY :=
+MARKDOWNREADY := drm.xml

 include Documentation/DocBook/media/Makefile

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 2fb9a54..4fb4636 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4073,92 +4073,6 @@ int num_ioctls;
   
 DPIO
 !Pdrivers/gpu/drm/i915/i915_reg.h DPIO
-   
- Dual channel PHY (VLV/CHV/BXT)
- 
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
- 
-   CH0
-   CH1
- 
-   
-   
- 
-   CMN/PLL/REF
-   CMN/PLL/REF
- 
- 
-   PCS01
-   PCS23
-   PCS01
-   PCS23
- 
- 
-   TX0
-   TX1
-   TX2
-   TX3
-   TX0
-   TX1
-   TX2
-   TX3
- 
- 
-   DDI0
-   DDI1
- 
-   
- 
-   
-   
- Single channel PHY (CHV/BXT)
- 
-   
-   
-   
-   
-   
-   
-   
-   
- 
-   CH0
- 
-   
-   
- 
-   CMN/PLL/REF
- 
- 
-   PCS01
-   PCS23
- 
- 
-   TX0
-   TX1
-   TX2
-   TX3
- 
- 
-   DDI2
- 
-   
- 
-   
   

   
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index cd74a09..9480464 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -553,10 +553,10 @@ EXPORT_SYMBOL(drm_gtf_mode_complex);
  * drivers/video/fbmon.c
  *
  * Standard GTF parameters:
- * M = 600
- * C = 40
- * K = 128
- * J = 20
+ * M = 600
+ * C = 40
+ * K = 128
+ * J = 20
  *
  * Returns:
  * The modeline based on the GTF algorithm stored in a drm_display_mode object.
@@ -1212,7 +1212,7 @@ EXPORT_SYMBOL(drm_mode_connector_list_update);
  * This uses the same parameters as the fb modedb.c, except for an extra
  * force-enable, force-enable-digital and force-disable bit at the end:
  *
- * x[M][R][-][@][i][m][eDd]
+ * x[M][R][-][@][i][m][eDd]
  *
  * The intermediate drm_cmdline_mode structure is required to store additional
  * options from the command line modline like the force-enable/disable flag.
@@ -1491,4 +1491,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out,

 out:
return ret;
-}
\ No newline at end of file
+}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index c0a5cd8..de59b0c 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -40,17 +40,15 @@
  * The basic usage pattern 

[PATCH v2 3/4] scripts/kernel-doc: Adding infrastructure for markdown support

[Danilo Cesar Lemes de Paula]

Markdown support is given by calling an external tool, pandoc, for all
highlighted text on kernel-doc.

Pandoc converts Markdown text to proper Docbook tags, which will be
later translated to pdf, html or other targets.

This adds the capability of adding human-readle text highlight (bold,
underline, etc), bullet and numbered lists, simple tables, fixed-width
text (including asciiart), requiring minimal changes to current
documentation.

So, text using *must* will be rendered as must
inside DocBook and then must for HTML.
Bullet lists eg:
* Element 1
* Element 2
will also be converted to proper docbook/html lists.
Although it has the support for a good part of the markup language,
pandoc has some limitations and won't render tables with spanning cells
or headings. The use of those features are not recommended.

At this moment, pandoc is totally optional. Docbooks ready for markdown
should be added to the MARKDOWNREADY variable inside the Makefile. In
case the developer doesn't have pandoc installed, Make will throw a
warning and the documentation build will continue, generating
simple Documentation without the features brought by pandoc.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 Changelog:
  v2:
* Fix checkpatch issues.
* Improved commit message.
* Fixed dependency issue causing "make htmldocs" recalculate without
  any code change.

 Documentation/DocBook/Makefile | 25 +++-
 scripts/docproc.c  | 54 --
 scripts/kernel-doc | 66 --
 3 files changed, 119 insertions(+), 26 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 322255b..8e6d022 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -17,6 +17,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml

+MARKDOWNREADY :=
+
 include Documentation/DocBook/media/Makefile

 ###
@@ -79,18 +81,23 @@ XMLTOFLAGS += --skip-validation
 # The following rules are used to generate the .xml documentation
 # required to generate the final targets. (ps, pdf, html).
 quiet_cmd_docproc = DOCPROC $@
-  cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $< >$@
+  cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $<
 define rule_docproc
-   set -e; \
-$(if $($(quiet)cmd_$(1)),echo '  $($(quiet)cmd_$(1))';)\
-$(cmd_$(1));   \
-(  \
-  echo 'cmd_$@ := $(cmd_$(1))';\
-  echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`;  \
+   set -e; 
\
+   USEMARKDOWN=""; 
\
+   FILE=`basename $@`; 
\
+   [[ "$(MARKDOWNREADY)" =~ "$${FILE}" ]] && USEMARKDOWN="-use-markdown";  
\
+$(if $($(quiet)cmd_$(1)),echo '  $($(quiet)cmd_$(1))';)
\
+$(cmd_$(1)) $$USEMARKDOWN >$@; 
\
+(  
\
+  echo 'cmd_$@ := $(cmd_$(1))';
\
+  echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`;  
\
 ) > $(dir $@).$(notdir $@).cmd
 endef

 %.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
+   @(which pandoc > /dev/null 2>&1) || \
+   (echo "*** To get propper documentation you need to install pandoc 
***";)
$(call if_changed_rule,docproc)

 # Tell kbuild to always build the programs
@@ -101,6 +108,10 @@ notfoundtemplate = echo "*** You have to install 
docbook-utils or xmlto ***"; \
 db2xtemplate = db2TYPE -o $(dir $@) $<
 xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $<

+ifneq ($(shell which pandoc >/dev/null 2>&1 && echo found),found)
+   MARKDOWNREADY := "";
+endif
+
 # determine which methods are available
 ifeq ($(shell which db2ps >/dev/null 2>&1 && echo found),found)
use-db2x = db2x
diff --git a/scripts/docproc.c b/scripts/docproc.c
index e267e621..7c6b225 100644
--- a/scripts/docproc.c
+++ b/scripts/docproc.c
@@ -73,12 +73,15 @@ FILELINE * docsection;
 #define NOFUNCTION"-nofunction"
 #define NODOCSECTIONS "-no-doc-sections"
 #define SHOWNOTFOUND  "-show-not-found"
+#define USEMARKDOWN   "-use-markdown"

 static char 

[PATCH v2 2/4] scripts/kernel-doc: Replacing highlights hash by an array

[Danilo Cesar Lemes de Paula]

The "highlight" code is very sensible to the order of the hash keys,
but the order of the keys cannot be predicted on Perl. It generates
faulty DocBook entries like:
- @device_for_each_child

We should use an array for that job, so we can guarantee that the order
of the regex execution on dohighlight won't change.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 Changelog:
v2: No changes

 scripts/kernel-doc | 104 ++---
 1 file changed, 60 insertions(+), 44 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9922e66..a38a69a 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -182,59 +182,73 @@ my $type_env = '(\$\w+)';
 #  One for each output format

 # these work fairly well
-my %highlights_html = ( $type_constant, "\$1",
-   $type_func, "\$1",
-   $type_struct_xml, "\$1",
-   $type_env, "\$1",
-   $type_param, "\$1" );
+my @highlights_html = (
+   [$type_constant, "\$1"],
+   [$type_func, "\$1"],
+   [$type_struct_xml, "\$1"],
+   [$type_env, "\$1"],
+   [$type_param, "\$1"]
+  );
 my $local_lt = "lt:";
 my $local_gt = "gt:";
 my $blankline_html = $local_lt . "p" . $local_gt;  # was ""

 # html version 5
-my %highlights_html5 = ( $type_constant, "\$1",
-   $type_func, "\$1",
-   $type_struct_xml, "\$1",
-   $type_env, "\$1",
-   $type_param, "\$1" );
+my @highlights_html5 = (
+[$type_constant, "\$1"],
+[$type_func, "\$1"],
+[$type_struct_xml, "\$1"],
+[$type_env, "\$1"],
+[$type_param, "\$1]"]
+  );
 my $blankline_html5 = $local_lt . "br /" . $local_gt;

 # XML, docbook format
-my %highlights_xml = ( "([^=])\\\"([^\\\"<]+)\\\"", "\$1\$2",
-   $type_constant, "\$1",
-   $type_func, "\$1",
-   $type_struct_xml, "\$1",
-   $type_env, "\$1",
-   $type_param, "\$1" );
+my @highlights_xml = (
+  ["([^=])\\\"([^\\\"<]+)\\\"", "\$1\$2"],
+  [$type_constant, "\$1"],
+  [$type_struct_xml, "\$1"],
+  [$type_param, "\$1"],
+  [$type_func, "\$1"],
+  [$type_env, "\$1"]
+);
 my $blankline_xml = $local_lt . "/para" . $local_gt . $local_lt . "para" . 
$local_gt . "\n";

 # gnome, docbook format
-my %highlights_gnome = ( $type_constant, "\$1",
-$type_func, "\$1",
-$type_struct, "\$1",
-$type_env, "\$1",
-$type_param, "\$1" );
+my @highlights_gnome = (
+[$type_constant, "\$1"],
+[$type_func, "\$1"],
+[$type_struct, "\$1"],
+[$type_env, "\$1"],
+[$type_param, "\$1" ]
+  );
 my $blankline_gnome = "\n";

 # these are pretty rough
-my %highlights_man = ( $type_constant, "\$1",
-  $type_func, "fB\$1fP",
-  $type_struct, "fI\$1fP",
-  $type_param, "fI\$1fP" );
+my @highlights_man = (
+  [$type_constant, "\$1"],
+  [$type_func, "fB\$1fP"],
+  [$type_struct, "fI\$1fP"],
+  [$type_param, "fI\$1fP"]
+);
 my $blankline_man = "";

 # text-mode
-my %highlights_text = ( $type_constant, "\$1",
-   $type_func, "\$1",
-   $type_struct, "\$1",
-   $type_param, "\$1" );
+my @highlights_text = (
+   [$type_constant, "\$1"],
+   [$type_func, "\$1"],
+   [$type_struct, "\$1"],
+   [$type_param, "\$1"]
+ );
 my $blankline_text = "";

 # list mode
-my %highlights_list = ( $type_constant, "\$1",
-   $type_func, "\$1",
-   $type_struct, "\$1",
-   $type_param, "\$1" );
+my @highlights_list = (
+   [$type_constant, "\$1"],
+   [$type_func, "\$1"],
+   [$type_struct, "\$1"],
+   [$type_param, "\$1"]
+ );
 my 

[PATCH v2 1/4] scripts/kernel-doc: Adding cross-reference links to html documentation.

[Danilo Cesar Lemes de Paula]

Functions, Structs and Parameters definitions on kernel documentation
are pure cosmetic, it only highlights the element.

To ease the navigation in the documentation we should use  inside
those tags so readers can easily jump between methods directly.

This was discussed in 2014[1] and is implemented by getting a list
of  from the DocBook XML to generate a database. Then it looks
for , and  tags that matches the ones in
the database. As it only links existent references, no broken links are
added.

[1] - lists.freedesktop.org/archives/dri-devel/2014-August/065404.html

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 Changelog:
  v1 (missing changlog from v1):
 * Add a "XMLREF FooBar.xml" as build output to reduce build noise.
 * Make kernel-doc-xml-ref ignore invalid arguments.
 * Improve kernel-doc-xml-ref documentation.

 Documentation/DocBook/Makefile |  43 ++---
 scripts/kernel-doc-xml-ref | 198 +
 2 files changed, 228 insertions(+), 13 deletions(-)
 create mode 100755 scripts/kernel-doc-xml-ref

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index b6a6a2e..322255b 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -64,8 +64,9 @@ installmandocs: mandocs

 ###
 #External programs used
-KERNELDOC = $(srctree)/scripts/kernel-doc
-DOCPROC   = $(objtree)/scripts/docproc
+KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
+KERNELDOC   = $(srctree)/scripts/kernel-doc
+DOCPROC = $(objtree)/scripts/docproc

 XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
 XMLTOFLAGS += --skip-validation
@@ -89,7 +90,7 @@ define rule_docproc
 ) > $(dir $@).$(notdir $@).cmd
 endef

-%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
+%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
$(call if_changed_rule,docproc)

 # Tell kbuild to always build the programs
@@ -140,7 +141,20 @@ quiet_cmd_db2html = HTML$@
echo ' \
$(patsubst %.html,%,$(notdir $@))' > $@

-%.html:%.xml
+###
+# Rules to create an aux XML and .db, and use them to re-process the DocBook 
XML
+# to fill internal hyperlinks
+   gen_aux_xml = :
+ quiet_gen_aux_xml = echo '  XMLREF  $@'
+silent_gen_aux_xml = :
+%.aux.xml: %.xml
+   @$($(quiet)gen_aux_xml)
+   @rm -rf $@
+   @(cat $< | egrep "^ 
$<.db)
+   @$(KERNELDOCXMLREF) -db $<.db $< > $@
+.PRECIOUS: %.aux.xml
+
+%.html:%.aux.xml
@(which xmlto > /dev/null 2>&1) || \
 (echo "*** You need to install xmlto ***"; \
  exit 1)
@@ -209,15 +223,18 @@ dochelp:
 ###
 # Temporary files left by various tools
 clean-files := $(DOCBOOKS) \
-   $(patsubst %.xml, %.dvi,  $(DOCBOOKS)) \
-   $(patsubst %.xml, %.aux,  $(DOCBOOKS)) \
-   $(patsubst %.xml, %.tex,  $(DOCBOOKS)) \
-   $(patsubst %.xml, %.log,  $(DOCBOOKS)) \
-   $(patsubst %.xml, %.out,  $(DOCBOOKS)) \
-   $(patsubst %.xml, %.ps,   $(DOCBOOKS)) \
-   $(patsubst %.xml, %.pdf,  $(DOCBOOKS)) \
-   $(patsubst %.xml, %.html, $(DOCBOOKS)) \
-   $(patsubst %.xml, %.9,$(DOCBOOKS)) \
+   $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
+   $(patsubst %.xml, %.aux, $(DOCBOOKS)) \
+   $(patsubst %.xml, %.tex, $(DOCBOOKS)) \
+   $(patsubst %.xml, %.log, $(DOCBOOKS)) \
+   $(patsubst %.xml, %.out, $(DOCBOOKS)) \
+   $(patsubst %.xml, %.ps,  $(DOCBOOKS)) \
+   $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
+   $(patsubst %.xml, %.html,$(DOCBOOKS)) \
+   $(patsubst %.xml, %.9,   $(DOCBOOKS)) \
+   $(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \
+   $(patsubst %.xml, %.xml.db,  $(DOCBOOKS)) \
+   $(patsubst %.xml, %.xml, $(DOCBOOKS)) \
$(index)

 clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
diff --git a/scripts/kernel-doc-xml-ref b/scripts/kernel-doc-xml-ref
new file mode 100755
index 000..104a5a5
--- /dev/null
+++ b/scripts/kernel-doc-xml-ref
@@ -0,0 +1,198 @@
+#!/usr/bin/perl -w
+
+use strict;
+
+## Copyright (C) 2015  Intel Corporation ##
+###
+## This software falls under the GNU General Public License. ##
+## Please read the COPYING file for more information ##
+#
+#
+# This software reads a XML file and a list of valid interal
+# references to replace Docbook tags with links.
+#
+# The list of "valid internal references" must be one-per-line in the 
following format:
+#  API-struct-foo
+#  API-enum-bar
+#  API-my-function
+#
+# The software walks over the XML file looking for xml tags representing 
possible references
+# to the Document. Each reference will be 

[PATCH v2 0/4] Add support for Hyperlinks and Markup on kernel-doc

[Danilo Cesar Lemes de Paula]

This series add supports for hyperlink cross-references on
Docbooks and an optional markup syntax for in-source
Documentation.

eg:
  
https://people.collabora.com/~danilo/intel/Documentation.MarkDown/DocBook/drm/API-drm-dev-ref.html
old:
  
https://people.collabora.com/~danilo/intel/Documentation.old/DocBook/drm/API-drm-dev-ref.html

Danilo Cesar Lemes de Paula (4):
  scripts/kernel-doc: Adding cross-reference links to html
documentation.
  scripts/kernel-doc: Replacing highlights hash by an array
  scripts/kernel-doc: Adding infrastructure for markdown support
  drm/doc: Convert to markdown

 Documentation/DocBook/Makefile |  68 +
 Documentation/DocBook/drm.tmpl |  86 
 drivers/gpu/drm/drm_modes.c|  12 +--
 drivers/gpu/drm/drm_modeset_lock.c |  14 ++-
 drivers/gpu/drm/drm_prime.c|  16 ++-
 drivers/gpu/drm/i915/i915_reg.h|  48 -
 include/drm/drm_vma_manager.h  |  10 +-
 scripts/docproc.c  |  54 +++---
 scripts/kernel-doc | 170 ++-
 scripts/kernel-doc-xml-ref | 198 +
 10 files changed, 454 insertions(+), 222 deletions(-)
 create mode 100755 scripts/kernel-doc-xml-ref

-- 
2.4.6

[PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions

[Boris Brezillon]

Archit, Laurent,

On Tue, 28 Jul 2015 13:47:37 +0530
Archit Taneja  wrote:

> Hi,
> 
> On 07/27/2015 02:29 PM, Laurent Pinchart wrote:
> > Hi Archit,
> >
> > (CC'ing Boris Brezillon)
> >
> > Thank you for the patch.
> >
> > On Monday 27 July 2015 11:46:57 Archit Taneja wrote:
> >> ADV7511 is represented as an i2c drm slave encoder device. ADV7533, on
> >> the other hand, is going be a normal i2c client device creating bridge
> >> and connector entities.
> >
> > Please, no. It's really time to stop piling hacks and fix the problem
> > properly. There's no reason to have separate APIs for I2C slave encoders and
> > DRM bridges. Those two APIs need to be merged, and then you'll find it much
> > easier to implement ADV7533 support.
> 
> i2c slave encoders and bridges aren't exactly the same. slave encoders
> are used when the there is no real 'encoder' in the display chain.
> bridges are used when there is already an encoder available, and the
> bridge entity represents another encoder in the chain.
> 
> ADV7511 takes in RGB/MIPI DPI data, which is generally the output of a 
> crtc for drm drivers.
> 
> ADV7533 takes in MIPI DSI data, which is generally the output of an
> encoder for drm drivers.
> 
> Therefore, having i2c slave encoder for the former and bridge for the
> latter made sense to me.
> 
> I do agree that it would be better if they were somehow merged. It
> would prevent the fragmentation we currently have among encoder
> chips.
> 
> One possible way would be to convert slave encoder to bridge. With
> this, an i2c slave encoder would be a 'dummy encoder' and a bridge.
> i2c slave encoders even now just tie the slave encoder helper funcs
> to encoder helper funcs. So it's not really any different.
> 
> Merging these 2 entities would be nice, but we're still shying away
> from the larger problem of creating generic encoder chains. The
> ideal solution would be for bridges and slave encoders to just be
> 'encoders', and the facility to connect on encoder output to the
> input of another. I don't know how easy it is to do this, and
> whether it'll break userspace.

Yes, that's pretty much what I was trying to do.
I'd also like to ease display pipelines creation by providing helper
functions, so that display controller don't have to worry about encoders
and connectors creation if these ones are attached to external encoders.

> 
> Archit
> 
> >
> > Boris, I know you were experimenting with that, do you have anything to 
> > report
> > ?

Nope, I didn't work on it since last time we talked about it. I pushed
my work here if you want to have a look [1].

Best Regards,

Boris

[1]https://github.com/bbrezillon/linux-at91/tree/drm-encoder-chain-WIP



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH] intel: wrap intel_bufmgr.h C code for C++ compilation/linking

[Emil Velikov]

On 27 July 2015 at 10:59, Tapani Pälli  wrote:
> On 07/03/2015 06:44 PM, Emil Velikov wrote:
>>
>> On 01/07/15 12:37, Tapani Pälli wrote:
>>>
>>> (We need this include in porting changes for the OpenGL ES
>>> conformance suite.)
>>>
>>> Signed-off-by: Tapani Pälli 
>>> ---
>>>   intel/intel_bufmgr.h | 8 
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
>>> index 285919e..f061454 100644
>>> --- a/intel/intel_bufmgr.h
>>> +++ b/intel/intel_bufmgr.h
>>> @@ -38,6 +38,10 @@
>>>   #include 
>>>   #include 
>>>   +#if defined(__cplusplus) || defined(c_plusplus)
>>> +extern "C" {
>>> +#endif
>>> +
>>
>> Strongly in favour - I've been pondering on this for a very long time.
>> Just a question - is there a compiler that care about (something from
>> the last decade) that does not define __cplusplus but c_plusplus ?
>
>
> I don't know, this was just copy paste from other file.
>
>> Afaict the former is defined since (at least) the 1998 C++ standard,
>> while the latter is extremely rare, and mostly mentioned as decrecated.
>
>
> For me it is ok to drop c_plusplus, no strong opinion.
>
That'll be great. Thanks.

-Emil

[PATCH 0/4] Add support for Hyperlinks and Markup on kernel-doc

[Danilo Cesar Lemes de Paula]

On 07/25/2015 07:20 AM, Stephan Mueller wrote:
> Am Donnerstag, 23. Juli 2015, 15:16:23 schrieb Danilo Cesar Lemes de Paula:
> 
> Hi Danilo,
> 
>> This series add supports for hyperlink cross-references on Docbooks and
>> an optional markup syntax for in-source Documentation.
> 
> Can you please give an example what you mean with the latter?

Sure,

take a look on
https://people.collabora.com/~danilo/intel/Documentation.MarkDown/DocBook/drm/API-drm-dev-ref.html
The words "must" and "any" are emphasised, it's different from the original
https://people.collabora.com/~danilo/intel/Documentation.old/DocBook/drm/API-drm-dev-ref.html

That page is created from drivers/gpu/drm/drm_drv.c, part of drm_dev_ref 
Documentation, where the text is "You *must* already own".

This is a ridiculous simple example but there are some bullet lists, numbered 
lists and code example in my patch 4/4.
It can also do asciiart and tables.

I'm sending a v2 of this patch series later as I have some fixes for it.

Danilo Cesar

[PATCH v2] drm/i2c: tda998x: Fix bad checksum of the HDMI AVI infoframe

[Jean-Francois Moine]

Using hdmi_avi_infoframe_pack() to create the AVI infoframe calculates
the checksum of the frame and breaks the second calculation which is
done in tda998x_write_if(). Then the HDMI AVI frame is wrong and
the display device does not handle correctly the video frames.

Fixes: 8c7a075da9f7980c ("use drm_hdmi_avi_infoframe_from_display_mode()")
Signed-off-by: Jean-Francois Moine 
---
v2: add the Fixes: tag
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index fe1599d..424228b 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -606,8 +606,6 @@ static void
 tda998x_write_if(struct tda998x_priv *priv, uint8_t bit, uint16_t addr,
 uint8_t *buf, size_t size)
 {
-   buf[PB(0)] = tda998x_cksum(buf, size);
-
reg_clear(priv, REG_DIP_IF_FLAGS, bit);
reg_write_range(priv, addr, buf, size);
reg_set(priv, REG_DIP_IF_FLAGS, bit);
@@ -627,6 +625,8 @@ tda998x_write_aif(struct tda998x_priv *priv, struct 
tda998x_encoder_params *p)
buf[PB(4)] = p->audio_frame[4];
buf[PB(5)] = p->audio_frame[5] & 0xf8; /* DM_INH + LSV */

+   buf[PB(0)] = tda998x_cksum(buf, sizeof(buf));
+
tda998x_write_if(priv, DIP_IF_FLAGS_IF4, REG_IF4_HB0, buf,
 sizeof(buf));
 }
-- 
2.4.6

[PATCH v2 12/22] drm/tegra: Probe dpaux devices on demand

[Tomeu Vizoso]

When looking up a dpaux device through its firmware node, probe it if it
hasn't already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso 
---

Changes in v2: None

 drivers/gpu/drm/tegra/dpaux.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 07b26972f487..9a793158a571 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -394,6 +394,8 @@ struct tegra_dpaux *tegra_dpaux_find_by_of_node(struct 
device_node *np)
 {
struct tegra_dpaux *dpaux;

+   fwnode_ensure_device(>fwnode);
+
mutex_lock(_lock);

list_for_each_entry(dpaux, _list, list)
-- 
2.4.3

[PATCH v2 11/22] drm: Probe panels on demand

[Tomeu Vizoso]

When looking up a panel through its firmware node, probe it if it hasn't
already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso 
---

Changes in v2: None

 drivers/gpu/drm/drm_panel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e037b7..374a964c3842 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -80,6 +80,8 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
 {
struct drm_panel *panel;

+   fwnode_ensure_device(>fwnode);
+
mutex_lock(_lock);

list_for_each_entry(panel, _list, list) {
-- 
2.4.3

[PATCH v2 0/22] On-demand device probing

[Tomeu Vizoso]

Hello,

I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playing with initcall levels and linking order.

While reading the thread [1] that Alexander Holler started with his
series to make probing order deterministic, it occurred to me that it
should be possible to achieve the same by probing devices as they are
referenced by other devices.

This basically reuses the information that is already implicit in the
probe() implementations, saving us from refactoring existing drivers or
adding information to DTBs.

During review of v1 of this series Linus Walleij suggested that it
should be the device driver core to make sure that dependencies are
ready before probing a device. I gave this idea a try [2] but Mark Brown
pointed out to the logic duplication between the resource acquisition
and dependency discovery code paths (though I think it's fairly minor).

To address that code duplication I experimented with Arnd's devm_probe
[3] concept of having drivers declare their dependencies instead of
acquiring them during probe, and while it worked [4], I don't think we
end up winning anything when compared to just probing devices on-demand
from resource getters.

One remaining objection is to the "sprinkling" of calls to
fwnode_ensure_device() in the resource getters of each subsystem, but I
think it's the right thing to do given that the storage of resources is
currently subsystem-specific.

We could avoid the above by moving resource storage into the core, but I
don't think there's a compelling case for that.

I have tested this on boards with Tegra, iMX.6, Exynos and OMAP SoCs,
and these patches were enough to eliminate all the deferred probes
(except one in PandaBoard because omap_dma_system doesn't have a
firmware node as of yet).

With this series I get the kernel to output to the panel in 0.5s,
instead of 2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

[2] https://lkml.org/lkml/2015/6/17/305

[3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689

[4] https://lkml.org/lkml/2015/7/21/441

Changes in v2:
- Move delay to platform.c
- Use set_primary_fwnode()
- Use of_node_full_name()
- Move the logic for finding a platform device from its firmware node to
  of/platform.c as it's not needed for ACPI nodes.
- Add acpi_dev_get_device()
- Add fwnode_ensure_device() so the mechanism for probing devices on
  demand is independent of the firmware format.
- Acquire regulator device lock before returning from regulator_dev_lookup()

Tomeu Vizoso (22):
  platform: delay device-driver matches until late_initcall
  of/platform: Set fwnode field for new devices
  device property: add fwnode_get_name()
  of/platform: add of_platform_device_find()
  ACPI: add acpi_dev_get_device()
  device property: add fwnode_ensure_device()
  gpio: Probe GPIO drivers on demand
  gpio: Probe pinctrl devices on demand
  regulator: core: Reduce critical area in _regulator_get
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c master devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on demand
  dma: of: Probe DMA controllers on demand
  power-supply: Probe power supplies on demand
  ASoC: core: Probe components on demand

 drivers/base/platform.c | 28 +++
 drivers/base/property.c | 73 +++
 drivers/clk/clk.c   |  3 ++
 drivers/dma/of-dma.c|  2 +
 drivers/gpio/gpiolib-of.c   |  4 ++
 drivers/gpu/drm/drm_panel.c |  2 +
 drivers/gpu/drm/tegra/dpaux.c   |  2 +
 drivers/i2c/i2c-core.c  |  2 +
 drivers/of/platform.c   | 61 +++
 drivers/phy/phy-core.c  |  2 +
 drivers/pinctrl/devicetree.c|  1 +
 drivers/power/power_supply_core.c   |  2 +
 drivers/pwm/core.c  |  2 +
 drivers/regulator/core.c| 99 +
 drivers/usb/phy/phy.c   |  2 +
 drivers/video/backlight/backlight.c |  2 +
 include/linux/acpi.h| 10 
 include/linux/of_platform.h |  1 +
 include/linux/property.h|  4 ++
 sound/soc/soc-core.c|  6 ++-
 20 files changed, 264 insertions(+), 44 deletions(-)

-- 
2.4.3

[PATCH v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support

[Rob Clark]

On Tue, Jul 28, 2015 at 1:50 PM, Andreas Färber  wrote:
> Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
>> This patch adds LVDS panel for IFC6410.
>>
>> Signed-off-by: Rob Clark 
>> [Rob Clark: WIP patch]
>> Signed-off-by: Srinivas Kandagatla 
>> ---
>>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 66 
>> ++
>>  1 file changed, 66 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
>> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> index 1ab71f1..3bdac02 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> @@ -63,6 +63,12 @@
>>   qcom,switch-mode-frequency = <320>;
>>   };
>>
>> + pm8921_l2: l2 {
>> + regulator-min-microvolt = <120>;
>> + regulator-max-microvolt = <120>;
>> + bias-pull-down;
>> + };
>> +
>>   pm8921_l3: l3 {
>>   regulator-min-microvolt = <305>;
>>   regulator-max-microvolt = <330>;
>> @@ -96,6 +102,10 @@
>>   pm8921_lvs1: lvs1 {
>>   bias-pull-down;
>>   };
>> +
>> + pm8921_lvs7: lvs7 {
>> + bias-pull-down;
>> + };
>>   };
>>   };
>>
>> @@ -119,6 +129,41 @@
>>
>>   mdp: qcom,mdp at 510 {
>>   status = "okay";
>> + qcom,lvds-panel = <>;
>
> In my testing this broke/uglified HDMI output. Since not everyone has
> that LVDS panel attached, or might have a different panel type, I don't
> think the panel node belongs in the generic -ifc6410.dts file.
> I suggest you add an -ifc6410+inforce-lvds.dts or so for that.

I think the problem is not so much the dt bindings, since we have an
i2c/ddc where we can probe the panel's edid and see if it is actually
attached.

Probably panel_simple_probe() should attempt to read edid (or at least
first block) if ddc is not null, and return an error if that times
out.  That way we could tell at runtime whether the panel is there or
not.

BR,
-R

>> + lvds-vccs-3p3v-supply = <_3p3v>;
>> + lvds-pll-vdda-supply = <_l2>;
>> + lvds-vdda-supply = <_lvs7>;
>> + };
>> +
>> + panel_3p3v: panel_3p3v {
>
> s/_/-/ ?
>
>> + compatible = "regulator-fixed";
>> + pinctrl-0 = <_en_gpios>;
>> + pinctrl-names = "default";
>> + regulator-min-microvolt = <330>;
>> + regulator-max-microvolt = <330>;
>> + regulator-name = "panel_en_3p3v";
>> + regulator-type = "voltage";
>> + startup-delay-us = <0>;
>> + gpio = <_gpio 36 GPIO_ACTIVE_HIGH>;
>> + enable-active-high;
>> + regulator-boot-on;
>> + };
>> +
>> + backlight: backlight{
>> + pinctrl-0 = <_bl_gpios>;
>> + pinctrl-names = "default";
>> + compatible = "gpio-backlight";
>> + gpios = <_gpio 26 GPIO_ACTIVE_HIGH>;
>> + default-on;
>> + };
>> +
>> + panel: auo,b101xtn01 {
>
> panel: panel { ?
>
> Regards,
> Andreas
>
>> + status = "okay";
>> + compatible = "auo,b101xtn01";
>> +
>> + ddc-i2c-bus = <>;
>> + backlight = <>;
>> + power-supply = <_3p3v>;
>>   };
>>
>>   gsbi3: gsbi at 1620 {
>> @@ -235,6 +280,27 @@
>>   pm8921_gpio: gpio at 150 {
>>   pinctrl-names = "default";
>>   pinctrl-0 = <_default_gpios>;
>> +
>> + pwm_bl_gpios: pwm-bl-gpios {
>> + pios {
>> + pins = "gpio26";
>> + bias-disable;
>> + function = "normal";
>> + qcom,drive-strength = 
>> ;
>> + power-source = 
>> ;
>> + };
>> + };
>> +
>> + disp_en_gpios: disp-en-gpios {
>> + 

[PATCH] drm: Detect no-op drmModeAtomicRequest and return early

[Emil Velikov]

On 21 July 2015 at 13:50, Chris Wilson  wrote:
> If the number of items to process in the request is zero, we can forgo
> duplicating, sorting the request and feeding it into the kernel and
> instead report success immediately.  This prevents a NULL dereference of
> the sorted->items for the no-op request.
>
Why do you attempt a null/empty commit :P But seriously, nicely caught !

Reviewed-by: Emil Velikov 

-Emil

[PATCH 2/2] drm/i915: Soften error messages in i915_gem_object_create_from_data()

[Chris Wilson]

Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes of debugging we need only log the erroneous values.

Signed-off-by: Chris Wilson 
Cc:: Alex Dai 
Cc: Dave Gordon 
Cc: Tom O'Rourke 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1ded76a6eb4..2039798f4403 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5243,8 +5243,8 @@ i915_gem_object_create_from_data(struct drm_device *dev,

i915_gem_object_unpin_pages(obj);

-   if (WARN_ON(bytes != size)) {
-   DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
+   if (bytes != size) {
+   DRM_DEBUG_GEM("Incomplete copy, wrote %zu of %zu", bytes, size);
ret = -EFAULT;
goto fail;
}
-- 
2.4.6

[PATCH 1/2] drm: Add DRM_DEBUG_GEM

[Chris Wilson]

Add a new debug value to distinguish and filter upon debug messages
emanating from GEM support code.

Signed-off-by: Chris Wilson 
---
 include/drm/drmP.h | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f2d68d185274..e7b58e37c583 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -107,6 +107,11 @@ struct dma_buf_attachment;
  * ATOMIC: used in the atomic code.
  *   This is the category used by the DRM_DEBUG_ATOMIC() macro.
  *
+ * GEM: used by portions of code backing the GEM interface, both in the
+ *  core (e.g. drm_gem.c) and vendor specific code.
+ * This is the category used by the DRM_DEBUG_GEM() macro.
+ *
+ *
  * Enabling verbose debug messages is done through the drm.debug parameter,
  * each category being enabled by a bit.
  *
@@ -114,17 +119,18 @@ struct dma_buf_attachment;
  * drm.debug=0x2 will enable DRIVER messages
  * drm.debug=0x3 will enable CORE and DRIVER messages
  * ...
- * drm.debug=0xf will enable all messages
+ * drm.debug=0xff will enable all messages
  *
  * An interesting feature is that it's possible to enable verbose logging at
  * run-time by echoing the debug value in its sysfs node:
- *   # echo 0xf > /sys/module/drm/parameters/debug
+ *   # echo 0xff > /sys/module/drm/parameters/debug
  */
 #define DRM_UT_CORE0x01
 #define DRM_UT_DRIVER  0x02
 #define DRM_UT_KMS 0x04
 #define DRM_UT_PRIME   0x08
 #define DRM_UT_ATOMIC  0x10
+#define DRM_UT_GEM 0x20

 extern __printf(2, 3)
 void drm_ut_debug_printk(const char *function_name,
@@ -254,6 +260,11 @@ void drm_err(const char *format, ...);
if (unlikely(drm_debug & DRM_UT_ATOMIC))\
drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
+#define DRM_DEBUG_GEM(fmt, args...)\
+   do {\
+   if (unlikely(drm_debug & DRM_UT_GEM))   \
+   drm_ut_debug_printk(__func__, fmt, ##args); \
+   } while (0)

 /*@}*/

-- 
2.4.6

[PATCH] drm: Add DRM_NOTICE_IF

[Chris Wilson]

Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug reporting tools.

For an example I have changed a DRM_ERROR for being unable to set a
performance enhancement in i915.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c |  5 ++---
 include/drm/drmP.h   | 20 
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 184d5f2dce21..f62cd78f8691 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1902,13 +1902,12 @@ static int gen8_init_rcs_context(struct 
drm_i915_gem_request *req)
if (ret)
return ret;

-   ret = intel_rcs_context_init_mocs(req);
/*
 * Failing to program the MOCS is non-fatal.The system will not
 * run at peak performance. So generate an error and carry on.
 */
-   if (ret)
-   DRM_ERROR("MOCS failed to program: expect performance 
issues.\n");
+   DRM_NOTICE_IF(intel_rcs_context_init_mocs(req),
+ "MOCS failed to program: expect performance issues.\n");

return intel_lr_context_render_state_init(req);
 }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b76af322d812..f2d68d185274 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -181,6 +181,26 @@ void drm_err(const char *format, ...);
 })

 /**
+ * Mild warning on assertion-esque failure.
+ *
+ * \param cond condition on which to *fail*
+ * \param fmt printf() like format string.
+ * \param arg arguments
+ *
+ * This is similar to WARN_ON but only prints a NOTICE rather than a warning
+ * and the whole stacktrace. It is only intended for mild issues which
+ * while significant do not critically impact the user (such as a performance
+ * issue).
+ */
+#define DRM_NOTICE_IF(cond, fmt, ...) ({   \
+   bool __cond = !!(cond); \
+   if (unlikely(__cond))   \
+   printk(KERN_NOTICE "[" DRM_NAME ":%s] " fmt,\
+  __func__, ##__VA_ARGS__);\
+   unlikely(__cond);   \
+})
+
+/**
  * Rate limited error output.  Like DRM_ERROR() but won't flood the log.
  *
  * \param fmt printf() like format string.
-- 
2.4.6

[Bug 88719] While using nine gallium tracker and wine Dark Souls 2 causes gpu hang

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=88719

Krzysztof A. Sobiecki  changed:

   What|Removed |Added

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

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

[PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions

[Archit Taneja]

Hi,

On 07/27/2015 02:29 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> (CC'ing Boris Brezillon)
>
> Thank you for the patch.
>
> On Monday 27 July 2015 11:46:57 Archit Taneja wrote:
>> ADV7511 is represented as an i2c drm slave encoder device. ADV7533, on
>> the other hand, is going be a normal i2c client device creating bridge
>> and connector entities.
>
> Please, no. It's really time to stop piling hacks and fix the problem
> properly. There's no reason to have separate APIs for I2C slave encoders and
> DRM bridges. Those two APIs need to be merged, and then you'll find it much
> easier to implement ADV7533 support.

i2c slave encoders and bridges aren't exactly the same. slave encoders
are used when the there is no real 'encoder' in the display chain.
bridges are used when there is already an encoder available, and the
bridge entity represents another encoder in the chain.

ADV7511 takes in RGB/MIPI DPI data, which is generally the output of a 
crtc for drm drivers.

ADV7533 takes in MIPI DSI data, which is generally the output of an
encoder for drm drivers.

Therefore, having i2c slave encoder for the former and bridge for the
latter made sense to me.

I do agree that it would be better if they were somehow merged. It
would prevent the fragmentation we currently have among encoder
chips.

One possible way would be to convert slave encoder to bridge. With
this, an i2c slave encoder would be a 'dummy encoder' and a bridge.
i2c slave encoders even now just tie the slave encoder helper funcs
to encoder helper funcs. So it's not really any different.

Merging these 2 entities would be nice, but we're still shying away
from the larger problem of creating generic encoder chains. The
ideal solution would be for bridges and slave encoders to just be
'encoders', and the facility to connect on encoder output to the
input of another. I don't know how easy it is to do this, and
whether it'll break userspace.

Archit

>
> Boris, I know you were experimenting with that, do you have anything to report
> ?
>
>> Move the code in encoder slave functions to generate helpers that are
>> agnostic to the drm object type. These helpers will later also be used
>> by bridge and connecter helper functions.
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   drivers/gpu/drm/i2c/adv7511.c | 80 +++
>>   1 file changed, 57 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
>> index 63a3d20..46fb24d 100644
>> --- a/drivers/gpu/drm/i2c/adv7511.c
>> +++ b/drivers/gpu/drm/i2c/adv7511.c
>> @@ -612,13 +612,11 @@ static int adv7511_get_edid_block(void *data, u8 *buf,
>> unsigned int block, }
>>
>>   /*
>> ---
>> -- - * Encoder operations
>> + * ADV75xx helpers
>>*/
>> -
>> -static int adv7511_get_modes(struct drm_encoder *encoder,
>> - struct drm_connector *connector)
>> +static int adv7511_get_modes(struct adv7511 *adv7511,
>> +struct drm_connector *connector)
>>   {
>> -struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
>>  struct edid *edid;
>>  unsigned int count;
>>
>> @@ -656,21 +654,10 @@ static int adv7511_get_modes(struct drm_encoder
>> *encoder, return count;
>>   }
>>
>> -static void adv7511_encoder_dpms(struct drm_encoder *encoder, int mode)
>> -{
>> -struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
>> -
>> -if (mode == DRM_MODE_DPMS_ON)
>> -adv7511_power_on(adv7511);
>> -else
>> -adv7511_power_off(adv7511);
>> -}
>> -
>>   static enum drm_connector_status
>> -adv7511_encoder_detect(struct drm_encoder *encoder,
>> +adv7511_detect(struct adv7511 *adv7511,
>> struct drm_connector *connector)
>>   {
>> -struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
>>  enum drm_connector_status status;
>>  unsigned int val;
>>  bool hpd;
>> @@ -694,7 +681,7 @@ adv7511_encoder_detect(struct drm_encoder *encoder,
>>  if (status == connector_status_connected && hpd && adv7511->powered) {
>>  regcache_mark_dirty(adv7511->regmap);
>>  adv7511_power_on(adv7511);
>> -adv7511_get_modes(encoder, connector);
>> +adv7511_get_modes(adv7511, connector);
>>  if (adv7511->status == connector_status_connected)
>>  status = connector_status_disconnected;
>>  } else {
>> @@ -708,8 +695,8 @@ adv7511_encoder_detect(struct drm_encoder *encoder,
>>  return status;
>>   }
>>
>> -static int adv7511_encoder_mode_valid(struct drm_encoder *encoder,
>> -  struct drm_display_mode *mode)
>> +static int adv7511_mode_valid(struct adv7511 *adv7511,
>> + const struct drm_display_mode *mode)
>>   {
>>  if (mode->clock > 165000)
>>  return MODE_CLOCK_HIGH;
>> @@ -717,11 +704,10 @@ static int 

[PATCH 3/3] drm: Remove __drm_modeset_lock_all

[Daniel Vetter]

The last user is gone, no need for trylocking any more in this legacy
helper.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_modeset_lock.c | 52 --
 include/drm/drm_modeset_lock.h |  1 -
 2 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index b4ddd1801642..9abee87c1501 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -53,41 +53,27 @@
  * drm_modeset_acquire_fini();
  */

-
 /**
- * __drm_modeset_lock_all - internal helper to grab all modeset locks
- * @dev: DRM device
- * @trylock: trylock mode for atomic contexts
- *
- * This is a special version of drm_modeset_lock_all() which can also be used 
in
- * atomic contexts. Then @trylock must be set to true.
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
  *
- * Returns:
- * 0 on success or negative error code on failure.
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
  */
-int __drm_modeset_lock_all(struct drm_device *dev,
-  bool trylock)
+void drm_modeset_lock_all(struct drm_device *dev)
 {
struct drm_mode_config *config = >mode_config;
struct drm_modeset_acquire_ctx *ctx;
int ret;

-   ctx = kzalloc(sizeof(*ctx),
- trylock ? GFP_ATOMIC : GFP_KERNEL);
-   if (!ctx)
-   return -ENOMEM;
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+   if (WARN_ON(!ctx))
+   return;

-   if (trylock) {
-   if (!mutex_trylock(>mutex)) {
-   ret = -EBUSY;
-   goto out;
-   }
-   } else {
-   mutex_lock(>mutex);
-   }
+   mutex_lock(>mutex);

drm_modeset_acquire_init(ctx, 0);
-   ctx->trylock_only = trylock;

 retry:
ret = drm_modeset_lock(>connection_mutex, ctx);
@@ -106,7 +92,7 @@ retry:

drm_warn_on_modeset_not_all_locked(dev);

-   return 0;
+   return;

 fail:
if (ret == -EDEADLK) {
@@ -114,23 +100,7 @@ fail:
goto retry;
}

-out:
kfree(ctx);
-   return ret;
-}
-EXPORT_SYMBOL(__drm_modeset_lock_all);
-
-/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
- *
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
- */
-void drm_modeset_lock_all(struct drm_device *dev)
-{
-   WARN_ON(__drm_modeset_lock_all(dev, false) != 0);
 }
 EXPORT_SYMBOL(drm_modeset_lock_all);

diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index 70595ff565ba..5dd18bfdf601 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -130,7 +130,6 @@ struct drm_crtc;
 struct drm_plane;

 void drm_modeset_lock_all(struct drm_device *dev);
-int __drm_modeset_lock_all(struct drm_device *dev, bool trylock);
 void drm_modeset_unlock_all(struct drm_device *dev);
 void drm_modeset_lock_crtc(struct drm_crtc *crtc,
   struct drm_plane *plane);
-- 
2.1.4

[PATCH 2/3] drm/fb-helper: Stop using trylocks in force_restore

[Daniel Vetter]

Since the panic handling is gone this is only used for force-restoring
the fbdev/fbcon from sysrq, and that's done with a work item. No need
any more to do trylocks, we can just do normal locking.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 77f570a470da..a9043ab7f58b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -416,19 +416,10 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;

-   /*
-* NOTE: Use trylock mode to avoid deadlocks and sleeping in
-* panic context.
-*/
-   if (__drm_modeset_lock_all(dev, true) != 0) {
-   error = true;
-   continue;
-   }
-
+   drm_modeset_lock_all(dev);
ret = drm_fb_helper_restore_fbdev_mode(helper);
if (ret)
error = true;
-
drm_modeset_unlock_all(dev);
}
return error;
-- 
2.1.4

[PATCH 1/3] drm/fbdev: Return -EBUSY when oopsing

[Daniel Vetter]

Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.

There was already one in the blank handler, but it failed silently.
That makes it impossible for drivers (like i915) who subclass these
functions to figure this out.

Instead consistently return -EBUSY so that everyone knows that we
really don't want to be bothered right now. This also allows us to
remove a pile of FIXMEs from the i915 fbdev code (since due to the
failure code they now won't attempt to grab dangerous locks any more).

Cc: Dave Airlie 
Cc: Rodrigo Vivi 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c| 24 
 drivers/gpu/drm/i915/intel_fbdev.c | 21 -
 2 files changed, 12 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 73f90f7e2f74..77f570a470da 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
int i, j;

/*
-* fbdev->blank can be called from irq context in case of a panic.
-* Since we already have our own special panic handler which will
-* restore the fbdev console mode completely, just bail out early.
-*/
-   if (oops_in_progress)
-   return;
-
-   /*
 * For each CRTC in this fb, turn the connectors on/off.
 */
drm_modeset_lock_all(dev);
@@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
  */
 int drm_fb_helper_blank(int blank, struct fb_info *info)
 {
+   if (oops_in_progress)
+   return -EBUSY;
+
switch (blank) {
/* Display: On; HSync: On, VSync: On */
case FB_BLANK_UNBLANK:
@@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
fb_info *info)
int i, j, rc = 0;
int start;

-   if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
+   if (oops_in_progress)
return -EBUSY;
-   }
+
+   drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
return -EBUSY;
@@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
struct drm_fb_helper *fb_helper = info->par;
struct fb_var_screeninfo *var = >var;

+   if (oops_in_progress)
+   return -EBUSY;
+
if (var->pixclock != 0) {
DRM_ERROR("PIXEL CLOCK SET\n");
return -EINVAL;
@@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo 
*var,
int ret = 0;
int i;

-   if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
+   if (oops_in_progress)
return -EBUSY;
-   }
+
+   drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
return -EBUSY;
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index eef54feb7545..b763f24e20ef 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
ret = drm_fb_helper_set_par(info);

if (ret == 0) {
-   /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong.  Ignore this for
-* now until we solve this for real.
-*/
mutex_lock(_helper->dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
mutex_unlock(_helper->dev->struct_mutex);
@@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
ret = drm_fb_helper_blank(blank, info);

if (ret == 0) {
-   /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong.  Ignore this for
-* now until we solve this for real.
-*/
mutex_lock(_helper->dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
mutex_unlock(_helper->dev->struct_mutex);
@@ -106,13 +92,6 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo 
*var,
ret 

[Intel-gfx] [PATCH 1/3] drm/fbdev: Return -EBUSY when oopsing

[Rob Clark]

On Tue, Jul 28, 2015 at 11:55 AM, Daniel Vetter  wrote:
> On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
>> On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter  
>> wrote:
>> > Trying to do anything with kms drivers when oopsing has become a
>> > failing proposition. But since we can end up in the fbdev code simply
>> > due to the console unblanking that's done unconditionally just
>> > removing our panic handler isn't enough. We need to block all fbdev
>> > callbacks when oopsing.
>> >
>> > There was already one in the blank handler, but it failed silently.
>> > That makes it impossible for drivers (like i915) who subclass these
>> > functions to figure this out.
>> >
>> > Instead consistently return -EBUSY so that everyone knows that we
>> > really don't want to be bothered right now. This also allows us to
>> > remove a pile of FIXMEs from the i915 fbdev code (since due to the
>> > failure code they now won't attempt to grab dangerous locks any more).
>>
>> I guess drivers that were keeping fbdev buffer pinned just for opps'
>> can stop doing that now..
>
> Well there's still the kgdb stuff, but we might want to nuke that too.
> Also fbdev assumes (at least afaik) that the mmap is always valid and it
> just writes to it. At least that's why we have the fbdev_set_suspend call
> to in suspend/resume to tell it that now it's really no longer cool to
> draw fbcon. But userspace doesn't have anything like that I think.

we couldn't put_pages but we could unpin from iommu/gtt/etc and unpin
the pages so they could be moved by mm at least.. but letting 'em get
swapped out, probably not..

BR,
-R

>> anyways, lgtm.. for the series:
>>
>> Reviewed-by: Rob Clark 
>
> Thanks for the review, all merged.
> -Daniel
>
>>
>> > Cc: Dave Airlie 
>> > Cc: Rodrigo Vivi 
>> > Signed-off-by: Daniel Vetter 
>> > ---
>> >  drivers/gpu/drm/drm_fb_helper.c| 24 
>> >  drivers/gpu/drm/i915/intel_fbdev.c | 21 -
>> >  2 files changed, 12 insertions(+), 33 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> > b/drivers/gpu/drm/drm_fb_helper.c
>> > index 73f90f7e2f74..77f570a470da 100644
>> > --- a/drivers/gpu/drm/drm_fb_helper.c
>> > +++ b/drivers/gpu/drm/drm_fb_helper.c
>> > @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, 
>> > int dpms_mode)
>> > int i, j;
>> >
>> > /*
>> > -* fbdev->blank can be called from irq context in case of a panic.
>> > -* Since we already have our own special panic handler which will
>> > -* restore the fbdev console mode completely, just bail out early.
>> > -*/
>> > -   if (oops_in_progress)
>> > -   return;
>> > -
>> > -   /*
>> >  * For each CRTC in this fb, turn the connectors on/off.
>> >  */
>> > drm_modeset_lock_all(dev);
>> > @@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, 
>> > int dpms_mode)
>> >   */
>> >  int drm_fb_helper_blank(int blank, struct fb_info *info)
>> >  {
>> > +   if (oops_in_progress)
>> > +   return -EBUSY;
>> > +
>> > switch (blank) {
>> > /* Display: On; HSync: On, VSync: On */
>> > case FB_BLANK_UNBLANK:
>> > @@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
>> > struct fb_info *info)
>> > int i, j, rc = 0;
>> > int start;
>> >
>> > -   if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
>> > +   if (oops_in_progress)
>> > return -EBUSY;
>> > -   }
>> > +
>> > +   drm_modeset_lock_all(dev);
>> > if (!drm_fb_helper_is_bound(fb_helper)) {
>> > drm_modeset_unlock_all(dev);
>> > return -EBUSY;
>> > @@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
>> > struct drm_fb_helper *fb_helper = info->par;
>> > struct fb_var_screeninfo *var = >var;
>> >
>> > +   if (oops_in_progress)
>> > +   return -EBUSY;
>> > +
>> > if (var->pixclock != 0) {
>> > DRM_ERROR("PIXEL CLOCK SET\n");
>> > return -EINVAL;
>> > @@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct 
>> > fb_var_screeninfo *var,
>> > int ret = 0;
>> > int i;
>> >
>> > -   if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
>> > +   if (oops_in_progress)
>> > return -EBUSY;
>> > -   }
>> > +
>> > +   drm_modeset_lock_all(dev);
>> > if (!drm_fb_helper_is_bound(fb_helper)) {
>> > drm_modeset_unlock_all(dev);
>> > return -EBUSY;
>> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
>> > b/drivers/gpu/drm/i915/intel_fbdev.c
>> > index eef54feb7545..b763f24e20ef 100644
>> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
>> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
>> > @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
>> > ret = drm_fb_helper_set_par(info);
>> >
>> > 

[Bug 91486] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91486

--- Comment #3 from Mike Lothian  ---
Created attachment 117415
  --> https://bugs.freedesktop.org/attachment.cgi?id=117415=edit
Xorg log when X wouldn't start

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

[Bug 91486] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91486

--- Comment #2 from Mike Lothian  ---
I'm going to try an older kernel just in case but I'm worried this might be
hardware failure

The last time I booted up X would start but then the machine would freeze up

Had to boot with radeon.dpm=0 radeon.runpm=0 radeon.modeset=0 to get X to start

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

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

More drm-misc, mostly fine-tuning of atomic helpers. They're mostly
driver-wide interface changes of the helpers and I need them for i915
work, so I plan to pull this tag into drm-intel-next too.

Cheers, Daniel


The following changes since commit dcd14dd957f02ef679c61325a2221a0574bdcab3:

  Merge tag 'topic/connector-locking-2015-07-23' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2015-07-24 14:30:29 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-07-28

for you to fetch changes up to 8c10342cb48f3140d9abeadcfd2fa6625d447282:

  drm/atomic: Update legacy DPMS state during modesets, v3. (2015-07-27 
16:23:29 +0200)


Maarten Lankhorst (4):
  drm/atomic: add connectors_changed to separate it from mode_changed, v2
  drm/atomic: pass old crtc state to atomic_begin/flush.
  drm: Make the connector dpms callback return a value, v2.
  drm/atomic: Update legacy DPMS state during modesets, v3.

Rodrigo Vivi (1):
  drm: Fix DP_TEST_COUNT_MASK

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   6 +-
 drivers/gpu/drm/drm_atomic_helper.c| 101 +
 drivers/gpu/drm/drm_crtc.c |   4 +-
 drivers/gpu/drm/drm_crtc_helper.c  |   9 ++-
 drivers/gpu/drm/drm_plane_helper.c |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   6 +-
 drivers/gpu/drm/i915/intel_crt.c   |   8 +-
 drivers/gpu/drm/i915/intel_display.c   |  27 +++
 drivers/gpu/drm/i915/intel_drv.h   |   2 +-
 drivers/gpu/drm/i915/intel_dvo.c   |   8 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   8 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c   |   6 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c   |   6 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c|   4 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |   6 +-
 drivers/gpu/drm/sti/sti_drm_crtc.c |   6 +-
 drivers/gpu/drm/tegra/dc.c |   6 +-
 drivers/gpu/drm/tegra/dsi.c|   3 +-
 drivers/gpu/drm/tegra/hdmi.c   |   5 +-
 drivers/gpu/drm/tegra/rgb.c|   5 +-
 drivers/gpu/drm/tegra/sor.c|   3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|   3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h|   2 +-
 include/drm/drm_atomic.h   |   3 +-
 include/drm/drm_atomic_helper.h|   4 +-
 include/drm/drm_crtc.h |  10 ++-
 include/drm/drm_crtc_helper.h  |   8 +-
 include/drm/drm_dp_helper.h|   2 +-
 29 files changed, 169 insertions(+), 99 deletions(-)

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

[Bug 91486] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91486

Mike Lothian  changed:

   What|Removed |Added

 CC||mike at fireburn.co.uk

--- Comment #1 from Mike Lothian  ---
I should add that I can get a DRI_PRIME=1 glxinfo to work (it does take longer
than usual) but when I to a DRI_PRIME=1 glxgears I just get garbage rendered
and the machine locks up shortly after this

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

[Bug 91486] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91486

Bug ID: 91486
   Summary: [drm:uvd_v1_0_start] *ERROR* UVD not responding,
trying to reset the VCPU!!!
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: mike at fireburn.co.uk

Created attachment 117414
  --> https://bugs.freedesktop.org/attachment.cgi?id=117414=edit
Dmesg

I've started getting the above errors when the GPU is initialised on my PRIME
system. It seems a bit suspicious that uvd v1 is being initialised as this is a
Radeon 6xxx series GPU. Since hitting this issue I can't boot into windows
without a BSOD pointing to the ati driver.

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] [1002:6741] (rev
ff)

I'm attaching the dmesg

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

[PATCH 1/3] drm/fbdev: Return -EBUSY when oopsing

[Rob Clark]

On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter  
wrote:
> Trying to do anything with kms drivers when oopsing has become a
> failing proposition. But since we can end up in the fbdev code simply
> due to the console unblanking that's done unconditionally just
> removing our panic handler isn't enough. We need to block all fbdev
> callbacks when oopsing.
>
> There was already one in the blank handler, but it failed silently.
> That makes it impossible for drivers (like i915) who subclass these
> functions to figure this out.
>
> Instead consistently return -EBUSY so that everyone knows that we
> really don't want to be bothered right now. This also allows us to
> remove a pile of FIXMEs from the i915 fbdev code (since due to the
> failure code they now won't attempt to grab dangerous locks any more).

I guess drivers that were keeping fbdev buffer pinned just for opps'
can stop doing that now..

anyways, lgtm.. for the series:

Reviewed-by: Rob Clark 

> Cc: Dave Airlie 
> Cc: Rodrigo Vivi 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_fb_helper.c| 24 
>  drivers/gpu/drm/i915/intel_fbdev.c | 21 -
>  2 files changed, 12 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 73f90f7e2f74..77f570a470da 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
> dpms_mode)
> int i, j;
>
> /*
> -* fbdev->blank can be called from irq context in case of a panic.
> -* Since we already have our own special panic handler which will
> -* restore the fbdev console mode completely, just bail out early.
> -*/
> -   if (oops_in_progress)
> -   return;
> -
> -   /*
>  * For each CRTC in this fb, turn the connectors on/off.
>  */
> drm_modeset_lock_all(dev);
> @@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
> dpms_mode)
>   */
>  int drm_fb_helper_blank(int blank, struct fb_info *info)
>  {
> +   if (oops_in_progress)
> +   return -EBUSY;
> +
> switch (blank) {
> /* Display: On; HSync: On, VSync: On */
> case FB_BLANK_UNBLANK:
> @@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
> fb_info *info)
> int i, j, rc = 0;
> int start;
>
> -   if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> +   if (oops_in_progress)
> return -EBUSY;
> -   }
> +
> +   drm_modeset_lock_all(dev);
> if (!drm_fb_helper_is_bound(fb_helper)) {
> drm_modeset_unlock_all(dev);
> return -EBUSY;
> @@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
> struct drm_fb_helper *fb_helper = info->par;
> struct fb_var_screeninfo *var = >var;
>
> +   if (oops_in_progress)
> +   return -EBUSY;
> +
> if (var->pixclock != 0) {
> DRM_ERROR("PIXEL CLOCK SET\n");
> return -EINVAL;
> @@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo 
> *var,
> int ret = 0;
> int i;
>
> -   if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
> +   if (oops_in_progress)
> return -EBUSY;
> -   }
> +
> +   drm_modeset_lock_all(dev);
> if (!drm_fb_helper_is_bound(fb_helper)) {
> drm_modeset_unlock_all(dev);
> return -EBUSY;
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index eef54feb7545..b763f24e20ef 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
> ret = drm_fb_helper_set_par(info);
>
> if (ret == 0) {
> -   /*
> -* FIXME: fbdev presumes that all callbacks also work from
> -* atomic contexts and relies on that for emergency oops
> -* printing. KMS totally doesn't do that and the locking here 
> is
> -* by far not the only place this goes wrong.  Ignore this for
> -* now until we solve this for real.
> -*/
> mutex_lock(_helper->dev->struct_mutex);
> intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> mutex_unlock(_helper->dev->struct_mutex);
> @@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info 
> *info)
> ret = drm_fb_helper_blank(blank, info);
>
> if (ret == 0) {
> -   /*
> -* FIXME: fbdev presumes that all callbacks also work from
> -* atomic contexts and relies on that for emergency oops
> -* printing. KMS totally doesn't do that and the locking 

[PATCH 1/2] drm/doc: Add hflip/vflip property descriptions in msm

[Daniel Vetter]

On Mon, Jul 27, 2015 at 06:57:33PM -0400, Jilai Wang wrote:
> Add plane properties hflip/vflip which are used in MDP driver to flip
> the input horizontally/vertically.
> 
> Signed-off-by: Jilai Wang 

Is the existing rotation prop with flip masks not enough?
-Daniel

> ---
>  Documentation/DocBook/drm.tmpl | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index d9f5613..bef6d34 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3501,8 +3501,8 @@ void intel_crt_init(struct drm_device *dev)
>   TBD
>   
>   
> - msm
> - Generic
> + msm
> + Generic
>   "premultiplied"
>   ENUM
>   { "false", "true" }
> @@ -3523,6 +3523,20 @@ void intel_crt_init(struct drm_device *dev)
>   Plane
>   property to set plane's z position during 
> blending
>   
> + 
> + "hflip"
> + ENUM
> + { "off", "on" }
> + Plane
> + property to flip the input horizontally
> + 
> + 
> + "vflip"
> + ENUM
> + { "off", "on" }
> + Plane
> + property to flip the input vertically
> + 
>   
>   
>  
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH RFC] drm/i2c: tda998x: dead-code or unhandled error condition ?

[Jean-Francois Moine]

On Wed, 10 Jun 2015 14:58:48 +0200
Nicholas Mc Guire  wrote:

> event API conformance testing with coccinelle spatches are being
> used to locate API usage inconsistencies this triggert with:
> ./drivers/gpu/drm/i2c/tda998x_drv.c:1062
> incorrect check for negative return
> 
> The return of wait_event_timeout is always >= 0, thus the negative 
> check was effectively being ignoring - as the timeout will be checked
> a few lines below the error condition being checked here seems to be
> wrong or this is simply dead code which would be my guess as the
> timeout condition check covers the wait-queue related failure condition.
> 
> Signed-off-by: Nicholas Mc Guire 

Acked-by: Jean-Francois Moine 

-- 
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91253

--- Comment #7 from Richard Bradfield  ---
Yes, I suggest you try it just to confirm that the issue doesn't reappear with
the new audio detect code in place.

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

[Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation Framework

[Benjamin Gaignard]

There is an API to do the same operation on kernel side than on userland.
You can get an dmabuf handle, select the allocator if required, and
secure it on kernel side.

Your question makes me realize that I have forget to add an
EXPORT_SYMBOL for smaf_create_handle function, I will fix that.

Benjamin

2015-07-28 4:22 GMT+02:00 Xiaoquan Li :
> Hi Benjamin,
>
> It looks like this framework only allows user space client to talk with trust 
> application, it there a plan to provide kernel side APIs for kernel space 
> client?
>
> Please correct me if my understanding is wrong.
>
> Thanks
>
> Xiaoquan
>
> -Original Message-
> From: Linaro-mm-sig [mailto:linaro-mm-sig-bounces at lists.linaro.org] On 
> Behalf Of Benjamin Gaignard
> Sent: Monday, July 27, 2015 6:12 PM
> To: linux-media at vger.kernel.org; Linux Kernel Mailing List; dri-devel at 
> lists.freedesktop.org; Hans Verkuil; Laurent Pinchart; Daniel Vetter; Rob 
> Clark; Thierry Reding; Sumit Semwal; Tom Cooksey; Daniel Stone
> Cc: Linaro MM SIG Mailman List
> Subject: Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation 
> Framework
>
> Hi all,
>
> This thread doesn't get any feedback...
>
> What would be great is to know if this framework proposal fir with
> your platform needs.
>
> Maybe I haven't copy the good mailing lists so if you think there is
> better ones do not hesitate to forward.
>
> Regards,
> Benjamin
>
>
> 2015-07-10 14:28 GMT+02:00 Benjamin Gaignard  linaro.org>:
>> version 3 changes:
>>  - Remove ioctl for allocator selection instead provide the name of
>>the targeted allocator with allocation request.
>>Selecting allocator from userland isn't the prefered way of working
>>but is needed when the first user of the buffer is a software component.
>>  - Fix issues in case of error while creating smaf handle.
>>  - Fix module license.
>>  - Update libsmaf and tests to care of the SMAF API evolution
>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>
>> version 2 changes:
>>  - Add one ioctl to allow allocator selection from userspace.
>>This is required for the uses case where the first user of
>>the buffer is a software IP which can't perform dma_buf attachement.
>>  - Add name and ranking to allocator structure to be able to sort them.
>>  - Create a tiny library to test SMAF:
>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>  - Fix one issue when try to secure buffer without secure module registered
>>
>> The outcome of the previous RFC about how do secure data path was the need
>> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>>
>> SMAF goal is to provide a framework that allow allocating and securing
>> memory by using dma_buf. Each platform have it own way to perform those two
>> features so SMAF design allow to register helper modules to perform them.
>>
>> To be sure to select the best allocation method for devices SMAF implement
>> deferred allocation mechanism: memory allocation is only done when the first
>> device effectively required it.
>> Allocator modules have to implement a match() to let SMAF know if they are
>> compatibles with devices needs.
>> This patch set provide an example of allocator module which use
>> dma_{alloc/free/mmap}_attrs() and check if at least one device have
>> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
>> I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
>> a better name could be found for this file.
>>
>> Secure modules are responsibles of granting and revoking devices access 
>> rights
>> on the memory. Secure module is also called to check if CPU map memory into
>> kernel and user address spaces.
>> An example of secure module implementation can be found here:
>> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
>> This code isn't yet part of the patch set because it depends on generic TEE
>> which is still under discussion (https://lwn.net/Articles/644646/)
>>
>> For allocation part of SMAF code I get inspirated by Sumit Semwal work about
>> constraint aware allocator.
>>
>> Benjamin Gaignard (2):
>>   create SMAF module
>>   SMAF: add CMA allocator
>>
>>  drivers/Kconfig|   2 +
>>  drivers/Makefile   |   1 +
>>  drivers/smaf/Kconfig   |  11 +
>>  drivers/smaf/Makefile  |   2 +
>>  drivers/smaf/smaf-cma.c| 200 +++
>>  drivers/smaf/smaf-core.c   | 735 
>> +
>>  include/linux/smaf-allocator.h |  54 +++
>>  include/linux/smaf-secure.h|  62 
>>  include/uapi/linux/smaf.h  |  52 +++
>>  9 files changed, 1119 insertions(+)
>>  create mode 100644 drivers/smaf/Kconfig
>>  create mode 100644 drivers/smaf/Makefile
>>  create mode 100644 drivers/smaf/smaf-cma.c
>>  create mode 100644 drivers/smaf/smaf-core.c
>>  create mode 100644 include/linux/smaf-allocator.h
>>  create mode 100644 include/linux/smaf-secure.h
>>  create mode 100644 

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91253

--- Comment #6 from Andreas Tunek  ---
I applied the patch you emailed me, should I try this one as well?

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

[PATCH 4/4] mm: remove direct calling of migration

[Gioh Kim]

2015-07-27 오후 10:58에 Vlastimil Babka 이(가) 쓴 글:
> On 07/13/2015 10:35 AM, Gioh Kim wrote:
>> From: Gioh Kim 
>>
>> Migration is completely generalized so that migrating mobile page
>> is processed with lru-pages in move_to_new_page.
>>
>> Signed-off-by: Gioh Kim 
>> Acked-by: Rafael Aquini 
>
> Why not just fold this to Patch 3? You already modify this hunk there, and 
> prior to patch 3, the hunk was balloon-pages specific. You made it look 
> generic only to remove it, which is unneeded code churn and I don't think it 
> adds anything wrt e.g. bisectability.
Yes, you have a point.
I'll be merged into 3/4 at next spin.

I wanted to show the process how migration is generalized with this patch.
On second thought it is not necessary.

>
>> ---
>>   mm/migrate.c | 15 ---
>>   1 file changed, 15 deletions(-)
>>
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index 53f0081d..e6644ac 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -844,21 +844,6 @@ static int __unmap_and_move(struct page *page, struct 
>> page *newpage,
>>   }
>>   }
>>
>> -if (unlikely(mobile_page(page))) {
>> -/*
>> - * A mobile page does not need any special attention from
>> - * physical to virtual reverse mapping procedures.
>> - * Skip any attempt to unmap PTEs or to remap swap cache,
>> - * in order to avoid burning cycles at rmap level, and perform
>> - * the page migration right away (proteced by page lock).
>> - */
>> -lock_page(newpage);
>> -rc = page->mapping->a_ops->migratepage(page->mapping,
>> -   newpage, page, mode);
>> -unlock_page(newpage);
>> -goto out_unlock;
>> -}
>> -
>>   /*
>>* Corner case handling:
>>* 1. When a new swap-cache page is read into, it is added to the LRU
>>
>
>

[PATCH 2/4] mm/compaction: enable mobile-page migration

[Gioh Kim]

> On Mon, Jul 27, 2015 at 4:55 PM, Vlastimil Babka  wrote:
>> On 07/13/2015 10:35 AM, Gioh Kim wrote:
>>>
>>> From: Gioh Kim 
>>>
>>> Add framework to register callback functions and check page mobility.
>>> There are some modes for page isolation so that isolate interface
>>> has arguments of page address and isolation mode while putback
>>> interface has only page address as argument.
>>
>>
>> Note that unlike what subject suggest, this doesn't really enable
>> mobile-page migration inside compaction, since that only happens with patch
>> 3. This might theoretically affect some cherry-pick backports that don't
>> care about balloon pages. I can imagine that can easily happen in the world
>> of mobile devices?
>> It would thus be somewhat cleaner if this patch was complete in that sense.

You have a point.
Current 2/4 patch is lack of calling migrate/isolate.
It is not complete without 3/4.

I'll add calling migrate/isolate() at next spin.


>>
>>> Signed-off-by: Gioh Kim 
>>> Acked-by: Rafael Aquini 
>>> ---
>>>fs/proc/page.c |  3 ++
>>>include/linux/compaction.h | 80
>>> ++
>>>include/linux/fs.h |  2 +
>>>include/linux/page-flags.h | 19 
>>>include/uapi/linux/kernel-page-flags.h |  1 +
>>>5 files changed, 105 insertions(+)
>>>
>>> diff --git a/fs/proc/page.c b/fs/proc/page.c
>>> index 7eee2d8..a4f5a00 100644
>>> --- a/fs/proc/page.c
>>> +++ b/fs/proc/page.c
>>> @@ -146,6 +146,9 @@ u64 stable_page_flags(struct page *page)
>>>  if (PageBalloon(page))
>>>  u |= 1 << KPF_BALLOON;
>>>
>>> +   if (PageMobile(page))
>>> +   u |= 1 << KPF_MOBILE;
>>
>>
>> PageMovable() would probably be as good a name and correspond to
>> MIGRATE_MOVABLE somewhat, unlike a completely new term. Whatever driver
>> starts to using this should probably change allocation flags to allocate
>> MIGRATE_MOVABLE, so that it works fine with what fragmentation avoidance
>> expects. Guess I should have said that earlier, but can you still
>> reconsider?
>
> Well, I've suggested to name it "mobile" because there's already a lot of 
> things
> called "movable". Mobile pages are special subset of movable pages: they
> are non-lru pages and define their own rules of moving in address
> space operations.
>
> Also there's a little pun: I guess main user will zram which is used
> mostly in embedded/mobile devices.

I like "mobile".
"movable" is for pages allocated with GFP_MOVABLE.
I think "movable" is a little ambiguous in this situation.

>
>>
>>> +
>>>  u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);
>>>
>>>  u |= kpf_copy_bit(k, KPF_SLAB,  PG_slab);
>>> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
>>> index aa8f61c..f693072 100644
>>> --- a/include/linux/compaction.h
>>> +++ b/include/linux/compaction.h
>>> @@ -1,6 +1,9 @@
>>>#ifndef _LINUX_COMPACTION_H
>>>#define _LINUX_COMPACTION_H
>>>
>>> +#include 
>>> +#include 
>>> +
>>>/* Return values for compact_zone() and try_to_compact_pages() */
>>>/* compaction didn't start as it was deferred due to past failures */
>>>#define COMPACT_DEFERRED  0
>>> @@ -51,6 +54,70 @@ extern void compaction_defer_reset(struct zone *zone,
>>> int order,
>>>  bool alloc_success);
>>>extern bool compaction_restarting(struct zone *zone, int order);
>>>
>>> +static inline bool mobile_page(struct page *page)
>>> +{
>>> +   return page->mapping && (PageMobile(page) || PageBalloon(page));
>>> +}
>>
>>
>> I would put this definition to linux/page-flags.h and rename it to
>> page_mobile (or better page_movable()), which is more common ordering.
>>
>>> +
>>> +static inline bool isolate_mobilepage(struct page *page, isolate_mode_t
>>> mode)
>>
>>
>> Does this have to be in compaction.h? The only user is compaction.c so
>> probably move it there, and if there ever is another module using this in
>> the future, we can move it to a more appropriate place and declare it in
>> e.g. mm/internal.h.

I think compaction.c is suitable.

>>
>>
>>> +{
>>> +   bool ret = false;
>>> +
>>> +   /*
>>> +* Avoid burning cycles with pages that are yet under
>>> __free_pages(),
>>> +* or just got freed under us.
>>> +*
>>> +* In case we 'win' a race for a mobile page being freed under us
>>> and
>>> +* raise its refcount preventing __free_pages() from doing its job
>>> +* the put_page() at the end of this block will take care of
>>> +* release this page, thus avoiding a nasty leakage.
>>> +*/
>>> +   if (unlikely(!get_page_unless_zero(page)))
>>> +   goto out;
>>> +
>>> +   /*
>>> +* As mobile pages are not isolated from LRU lists, concurrent
>>> +* compaction threads can race against page migration functions
>>> +* as well as race against the 

[Intel-gfx] [PULL] topic/crc-pmic

[Kumar, Shobhit]

On Monday 27 July 2015 04:51 PM, Thierry Reding wrote:
> On Thu, Jul 23, 2015 at 09:38:46AM +0200, Daniel Vetter wrote:
> [...]
>> On Thu, Jul 23, 2015 at 9:31 AM, Daniel Vetter  
>> wrote:
> [...]
>>> Shobhit Kumar (8):
> [...]
>>>pwm: crc: Add Crystalcove (CRC) PWM driver
>
> Would you mind removing this from your branch? I ended up manually
> applying a couple of changes that I had requested but ended up not
> getting addressed.


Sorry if I missed, but I thought I had addressed all your comments in my 
last patch and did not see any further comments from you.

Regards
Shobhit

>
> When you drop it, let me know so I can push my branch to -next and
> have it not collide with your tree immediately. I assume it's in a
> branch that feeds into linux-next?
>
> Thierry
>
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

[Bug 91444] regression bisected radeonsi: don't change pipe_resource in resource_copy_region

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91444

--- Comment #6 from Shawn Starr  ---
Marek's has fixed this in
http://cgit.freedesktop.org/~mareko/mesa/commit/?id=21f4eb11d76d45c8b4099e0df36d1263901c39a2

This has been tested, works for me now.

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

[Bug 91481] [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91481

Bug ID: 91481
   Summary: [Patch?] DisplayPort MST (Multistream Transport)
hotplug kernel memory fault
   Product: DRI
   Version: XOrg git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adam_richter2004 at yahoo.com

Created attachment 117412
  --> https://bugs.freedesktop.org/attachment.cgi?id=117412=edit
Path to make drm_dp_send_link_address set link_address_sent before hotplug
handler changes the pointer to it

When I "hot plug" insert a DisplayPort multistream transport ("MST") hub into a
computer that is running a Linux 4.2-rc4 kernel or any recent version, I get a
kernel memory fault in drm_dp_add_port.  In earlier kernels, I traced it to the
line after drm_dp_add_port's call to drm_dp_send_link_address:

 drm_dp_send_link_address(mstb->mgr, port->mstb);
port->mstb->link_address_sent = true;

I believe that the problem is that drm_dp_send_link_address can call a hotplug
handler, which can change port->mstb so that it cannot be dereferenced (I think
it is set to NULL, but I have forgotten).

Since drm_dp_send_link_address is a static function in this file, its address
is never taken, and there are only two call sites, both of which set
link_address_sent to true, the patch that I have attached changes
drm_dp_send_link_address so that it sets that flag, reducing duplication of
code, and also allowing drm_dp_send_link_address to skip setting the flag if
sending the link address fails.

An intentional behavior change introduced by this patch is that the
mstb->link_address_sent is not set if sending the link address was aborted due
to the memory allocation in drm_dp_send_link_address failing.

Perhaps it should also not be set if the action receives a NAK reply, but I
haven't studied the code and DisplayPort documentation enough to guess. 
Whoever examines this patch should feel free to revise it as they see fit.

I should also warn that after I made this change in linux-4.2-rc4, the
resulting kernel eventually got another kernel memory fault in i2c_transfer
(called by drm_do_probe_ddc_edid), but I believe that that is a separate issue.

I am happy to answer questions about this patch.  If nobody sees any problems
with it, I would ask that whoever takes this bug report submit the patch
upstream.

Thanks for considering this bug report and proposed patch.

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

[Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation Framework

[Xiaoquan Li]

Hi Benjamin,

It looks like this framework only allows user space client to talk with trust 
application, it there a plan to provide kernel side APIs for kernel space 
client?

Please correct me if my understanding is wrong.

Thanks

Xiaoquan

-Original Message-
From: Linaro-mm-sig [mailto:linaro-mm-sig-boun...@lists.linaro.org] On Behalf 
Of Benjamin Gaignard
Sent: Monday, July 27, 2015 6:12 PM
To: linux-media at vger.kernel.org; Linux Kernel Mailing List; dri-devel at 
lists.freedesktop.org; Hans Verkuil; Laurent Pinchart; Daniel Vetter; Rob 
Clark; Thierry Reding; Sumit Semwal; Tom Cooksey; Daniel Stone
Cc: Linaro MM SIG Mailman List
Subject: Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation 
Framework

Hi all,

This thread doesn't get any feedback...

What would be great is to know if this framework proposal fir with
your platform needs.

Maybe I haven't copy the good mailing lists so if you think there is
better ones do not hesitate to forward.

Regards,
Benjamin


2015-07-10 14:28 GMT+02:00 Benjamin Gaignard :
> version 3 changes:
>  - Remove ioctl for allocator selection instead provide the name of
>the targeted allocator with allocation request.
>Selecting allocator from userland isn't the prefered way of working
>but is needed when the first user of the buffer is a software component.
>  - Fix issues in case of error while creating smaf handle.
>  - Fix module license.
>  - Update libsmaf and tests to care of the SMAF API evolution
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>
> version 2 changes:
>  - Add one ioctl to allow allocator selection from userspace.
>This is required for the uses case where the first user of
>the buffer is a software IP which can't perform dma_buf attachement.
>  - Add name and ranking to allocator structure to be able to sort them.
>  - Create a tiny library to test SMAF:
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>  - Fix one issue when try to secure buffer without secure module registered
>
> The outcome of the previous RFC about how do secure data path was the need
> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>
> SMAF goal is to provide a framework that allow allocating and securing
> memory by using dma_buf. Each platform have it own way to perform those two
> features so SMAF design allow to register helper modules to perform them.
>
> To be sure to select the best allocation method for devices SMAF implement
> deferred allocation mechanism: memory allocation is only done when the first
> device effectively required it.
> Allocator modules have to implement a match() to let SMAF know if they are
> compatibles with devices needs.
> This patch set provide an example of allocator module which use
> dma_{alloc/free/mmap}_attrs() and check if at least one device have
> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
> I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
> a better name could be found for this file.
>
> Secure modules are responsibles of granting and revoking devices access rights
> on the memory. Secure module is also called to check if CPU map memory into
> kernel and user address spaces.
> An example of secure module implementation can be found here:
> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
> This code isn't yet part of the patch set because it depends on generic TEE
> which is still under discussion (https://lwn.net/Articles/644646/)
>
> For allocation part of SMAF code I get inspirated by Sumit Semwal work about
> constraint aware allocator.
>
> Benjamin Gaignard (2):
>   create SMAF module
>   SMAF: add CMA allocator
>
>  drivers/Kconfig|   2 +
>  drivers/Makefile   |   1 +
>  drivers/smaf/Kconfig   |  11 +
>  drivers/smaf/Makefile  |   2 +
>  drivers/smaf/smaf-cma.c| 200 +++
>  drivers/smaf/smaf-core.c   | 735 
> +
>  include/linux/smaf-allocator.h |  54 +++
>  include/linux/smaf-secure.h|  62 
>  include/uapi/linux/smaf.h  |  52 +++
>  9 files changed, 1119 insertions(+)
>  create mode 100644 drivers/smaf/Kconfig
>  create mode 100644 drivers/smaf/Makefile
>  create mode 100644 drivers/smaf/smaf-cma.c
>  create mode 100644 drivers/smaf/smaf-core.c
>  create mode 100644 include/linux/smaf-allocator.h
>  create mode 100644 include/linux/smaf-secure.h
>  create mode 100644 include/uapi/linux/smaf.h
>
> --
> 1.9.1
>



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
Linaro-mm-sig mailing list
Linaro-mm-sig at lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig