[git pull] drm fixes for 4.13-rc7

[Dave Airlie]

Hi Linus,

Fixes for rc7, nothing too crazy, some core, i915, and sunxi fixes,
Intel CI has been responsible for some of these fixes being required.

Dave.

The following changes since commit 14ccee78fc82f5512908f4424f541549a5705b89:

  Linux 4.13-rc6 (2017-08-20 14:13:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc7

for you to fetch changes up to da6119797705c2270f17b287660a1e7bd782a1eb:

  Merge tag 'drm-misc-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-08-25
09:29:38 +1000)


drm fixes for 4.13-rc7, i915, core, imx and sun4i


Andy Shevchenko (1):
  drm/i915/bxt: use NULL for GPIO connection ID

Arnd Bergmann (1):
  gpu: ipu-v3: add DRM dependency

Balasubramaniam, Hari Chand (1):
  drm/i915: Initialize 'data' in intel_dsi_dcs_backlight.c

Chris Wilson (2):
  drm/i915: Clear lost context-switch interrupts across reset
  drm: Release driver tracking before making the object available again

Dave Airlie (5):
  Merge tag 'sunxi-drm-fixes-for-4.13' of
https://git.kernel.org/.../mripard/linux into drm-fixes
  Merge tag 'imx-drm-fixes-2017-08-18' of
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-08-18' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes

Jani Nikula (2):
  drm/i915/vbt: ignore extraneous child devices for a port
  Merge tag 'gvt-fixes-2017-08-23' of
https://github.com/01org/gvt-linux into drm-intel-fixes

Jeffy Chen (1):
  drm/rockchip: Fix suspend crash when drm is not bound

Jonathan Liu (1):
  drm/sun4i: Implement drm_driver lastclose to restore fbdev console

Maarten Lankhorst (2):
  drm/atomic: Handle -EDEADLK with out-fences correctly
  drm/atomic: If the atomic check fails, return its value first

Nikhil Mahale (1):
  drm: Fix framebuffer leak

Philipp Zabel (1):
  drm/imx: ipuv3-plane: fix YUV framebuffer scanout on the base plane

Rodrigo Vivi (1):
  drm/i915/cnl: Fix LSPCON support.

Sean Paul (1):
  Merge origin/master into drm-misc-fixes

fred gao (1):
  drm/i915/gvt: Fix the kernel null pointer error

 drivers/gpu/drm/drm_atomic.c   | 11 ---
 drivers/gpu/drm/drm_gem.c  |  6 +++---
 drivers/gpu/drm/drm_plane.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  2 +-
 drivers/gpu/drm/i915/intel_bios.c  | 15 +--
 drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c |  2 +-
 drivers/gpu/drm/i915/intel_dsi_vbt.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 23 ++-
 drivers/gpu/drm/i915/intel_lspcon.c|  4 ++--
 drivers/gpu/drm/imx/ipuv3-plane.c  |  6 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 12 ++--
 drivers/gpu/drm/sun4i/sun4i_drv.c  |  8 
 drivers/gpu/ipu-v3/Kconfig |  1 +
 13 files changed, 69 insertions(+), 24 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196635

--- Comment #13 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
yes.
But I really think the problem is application-layer:
I do not see any errors in dmesg when running clinfo,
but when I run the application I'm developing, I see the following errors in
dmesg:
[31637.263268] amdgpu :41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0014 address=0xff9f4000 flags=0x]
[31637.263379] amdgpu :41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0014 address=0xff9e4000 flags=0x]
... and the application hangs
the interesting part here is: to make sure the driver does not "accidentally
work", I added a polaris device to the system.  The amdgpu recognised the
polaris, fiji and SI, but only the SI gives these faults.

do you know how I can figure out whether this is a kernel / midline /
application layer problem?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/9] drm/exynos: mixer: fix chroma comment in vp_video_buffer()

[Inki Dae]

2017년 08월 22일 23:19에 Tobias Jakobi 이(가) 쓴 글:
> The current comment sounds like the division op is done to
> compensate for some hardware erratum. But the chroma plane
> having half the height of the luma plane is just the way
> NV12/NV21 is defined, so clarify this behaviour.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index a998a8dd783c..c6d6f6d42900 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -532,7 +532,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   /* setting size of input image */
>   vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
>   VP_IMG_VSIZE(fb->height));
> - /* chroma height has to reduced by 2 to avoid chroma distorions */
> + /* the chroma plane for NV12/NV21 is half the height of the luma plane 
> */

WARNING: line over 80 characters
#86: FILE: drivers/gpu/drm/exynos/exynos_mixer.c:535:
+   /* the chroma plane for NV12/NV21 is half the height of the luma plane 
*/

I just removed a word, 'the', in front of 'chroma' word.

Thanks,
Inki Dae


>   vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
>   VP_IMG_VSIZE(fb->height / 2));
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 05/10] drm/exynos/mic: use mode info stored in CRTC to detect i80 mode

[Inki Dae]

2017년 08월 24일 22:33에 Andrzej Hajda 이(가) 쓴 글:
> MIC driver should use info from CRTC to check mode of work instead of
> illegally peeking into nodes of other devices.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 44 
> +++--
>  1 file changed, 4 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 16bbee8..128ce176 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -21,9 +21,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +#include 

Build error happened at here. It should be modified to '#include 
"exynos_drm_drv.h"'.
I can fix it.

Thanks,
Inki Dae
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101976] glmark2 random blank or background only screen freeze over mesa3d 17.1 and 17.3 with radeon rx550 AMD POLARIS12

[bugzilla-daemon]

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

--- Comment #10 from Pablo Estigarribia  ---
also tested game Insurgency that had same problem as glmark2 and it works now! 

seems that dpm is buggy on this radeon card, probably is better to disable it
by default or put it on high performance for a more stable usage for users.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #34 from Ben Widawsky  ---
Just some thoughts...

The corruption are x-tiled cachelines, looks like stale ones. I don't know what
the vertical lines are. It looks to me like the memory is just misbehaving. I
wonder if when you plug in the machine if BIOS tries to crank up DDR, or
Graphics voltage. Is there some BIOS setting or update to tweak what happens on
AC?

Is this desktop environment using sprite planes? If the compositor is using all
one plane (which I think is likely), and display was at fault, everything would
be corrupt.


So please see if there is anything that can be done in BIOS to tell it to not
behave differently when on AC.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101976] glmark2 random blank or background only screen freeze over mesa3d 17.1 and 17.3 with radeon rx550 AMD POLARIS12

[bugzilla-daemon]

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

--- Comment #9 from Pablo Estigarribia  ---
On latest test th glmark2 passed but changing dpm from auto to high with: 

echo "high" > /sys/class/drm/card0/device/power_dpm_force_performance_level

as root. 

glmark2
===
glmark2 2014.03
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Gallium 0.4 on AMD POLARIS12 (DRM 3.15.0 /
4.12.8-300.fc26.x86_64, LLVM 4.0.0)
GL_VERSION:3.0 Mesa 17.1.7
===
[build] use-vbo=false: FPS: 3486 FrameTime: 0.287 ms
[build] use-vbo=true: FPS: 5095 FrameTime: 0.196 ms
[texture] texture-filter=nearest: FPS: 4927 FrameTime: 0.203 ms
[texture] texture-filter=linear: FPS: 5014 FrameTime: 0.199 ms
[texture] texture-filter=mipmap: FPS: 4899 FrameTime: 0.204 ms
[shading] shading=gouraud: FPS: 4960 FrameTime: 0.202 ms
[shading] shading=blinn-phong-inf: FPS: 4979 FrameTime: 0.201 ms
[shading] shading=phong: FPS: 4945 FrameTime: 0.202 ms
[shading] shading=cel: FPS: 4880 FrameTime: 0.205 ms
[bump] bump-render=high-poly: FPS: 5064 FrameTime: 0.197 ms
[bump] bump-render=normals: FPS: 4824 FrameTime: 0.207 ms
[bump] bump-render=height: FPS: 4688 FrameTime: 0.213 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 5140 FrameTime: 0.195 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 3688 FrameTime: 0.271 ms
[pulsar] light=false:quads=5:texture=false: FPS: 4306 FrameTime: 0.232 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS:
2557 FrameTime: 0.391 ms
[desktop] effect=shadow:windows=4: FPS: 2273 FrameTime: 0.440 ms
[buffer]
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:
FPS: 557 FrameTime: 1.795 ms
[buffer]
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:
FPS: 779 FrameTime: 1.284 ms
[buffer]
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:
FPS: 636 FrameTime: 1.572 ms
[ideas] speed=duration: FPS: 1468 FrameTime: 0.681 ms
[jellyfish] : FPS: 3937 FrameTime: 0.254 ms
[terrain] : FPS: 636 FrameTime: 1.572 ms
[shadow] : FPS: 3587 FrameTime: 0.279 ms
[refract] : FPS: 1310 FrameTime: 0.763 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 4893 FrameTime: 0.204 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 4779 FrameTime: 0.209 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 4807 FrameTime: 0.208 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 4830 FrameTime: 0.207
ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 4475 FrameTime:
0.223 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 4424
FrameTime: 0.226 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 4343
FrameTime: 0.230 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 4441
FrameTime: 0.225 ms
===
  glmark2 Score: 3806 
===


OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD POLARIS12 (DRM 3.15.0 /
4.12.8-300.fc26.x86_64, LLVM 4.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.7
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 02/10] drm/exynos: use helper to set possible crtcs

[Inki Dae]

2017년 08월 24일 22:33에 Andrzej Hajda 이(가) 쓴 글:
> All encoders share the same code to set encoders possible_crtcs field.
> The patch creates helper to abstract out this code.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_dp.c   | 15 +--
>  drivers/gpu/drm/exynos/exynos_drm_core.c |  1 +
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 21 ++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h | 10 +++---
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c  | 12 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  | 13 -
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c | 15 +--
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 25 +
>  8 files changed, 53 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 385537b..39629e7 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -155,7 +155,7 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>   struct exynos_dp_device *dp = dev_get_drvdata(dev);
>   struct drm_encoder *encoder = >encoder;
>   struct drm_device *drm_dev = data;
> - int pipe, ret;
> + int ret;
>  
>   /*
>* Just like the probe function said, we don't need the
> @@ -179,20 +179,15 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>   return ret;
>   }
>  
> - pipe = exynos_drm_crtc_get_pipe_from_type(drm_dev,
> -   EXYNOS_DISPLAY_TYPE_LCD);
> - if (pipe < 0)
> - return pipe;
> -
> - encoder->possible_crtcs = 1 << pipe;
> -
> - DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
> -
>   drm_encoder_init(drm_dev, encoder, _dp_encoder_funcs,
>DRM_MODE_ENCODER_TMDS, NULL);
>  
>   drm_encoder_helper_add(encoder, _dp_encoder_helper_funcs);
>  
> + ret = exynos_drm_set_possible_crtcs(encoder, EXYNOS_DISPLAY_TYPE_LCD);
> + if (ret < 0)
> + return ret;
> +
>   dp->plat_data.encoder = encoder;
>  
>   return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
> b/drivers/gpu/drm/exynos/exynos_drm_core.c
> index edbd98f..b0c0621 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
> @@ -13,6 +13,7 @@
>   */
>  
>  #include 
> +
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_crtc.h"
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index c37078f..ac544de 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "exynos_drm_crtc.h"
>  #include "exynos_drm_drv.h"
> @@ -191,16 +192,30 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
> drm_device *drm_dev,
>   return ERR_PTR(ret);
>  }
>  
> -int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
> +struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device 
> *drm_dev,

You don't have to modify this function because no user to use this function 
here.
Moving this change to actual user, patch 4, would be better. Anyway trivial 
thing so I will merge it as-is.


Thanks,
Inki Dae
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 08/10] drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode

[Inki Dae]

2017년 08월 24일 22:33에 Andrzej Hajda 이(가) 쓴 글:
> Since panel's mode of work is propagated properly from panel to DECON,
> there is no need to use redundant private device tree property.
> The only issue with such approach is that check for required interrupts
> should be postponed until panel communicate its requirements, ie to
> mode validation phase - mode_valid callback.

Same patch will be required for other Exynos SoCs for consistency later.


Thanks,
Inki Dae

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 40 
> +--
>  1 file changed, 25 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 0f5acce..da183e0 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -34,9 +34,8 @@
>  #define WINDOWS_NR   3
>  #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>  
> -#define IFTYPE_I80   (1 << 0)
> -#define I80_HW_TRG   (1 << 1)
> -#define IFTYPE_HDMI  (1 << 2)
> +#define I80_HW_TRG   (1 << 0)
> +#define IFTYPE_HDMI  (1 << 1)
>  
>  static const char * const decon_clks_name[] = {
>   "pclk",
> @@ -93,7 +92,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
>   u32 val;
>  
>   val = VIDINTCON0_INTEN;
> - if (ctx->out_type & IFTYPE_I80)
> + if (crtc->i80_mode)
>   val |= VIDINTCON0_FRAMEDONE;
>   else
>   val |= VIDINTCON0_INTFRMEN | VIDINTCON0_FRAMESEL_FP;
> @@ -142,7 +141,7 @@ static u32 decon_get_frame_count(struct decon_context 
> *ctx, bool end)
>  
>   switch (status & (VIDCON1_VSTATUS_MASK | VIDCON1_I80_ACTIVE)) {
>   case VIDCON1_VSTATUS_VS:
> - if (!(ctx->out_type & IFTYPE_I80))
> + if (!(ctx->crtc->i80_mode))
>   --frm;
>   break;
>   case VIDCON1_VSTATUS_BP:
> @@ -169,7 +168,7 @@ static u32 decon_get_vblank_counter(struct 
> exynos_drm_crtc *crtc)
>  
>  static void decon_setup_trigger(struct decon_context *ctx)
>  {
> - if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
> + if (!ctx->crtc->i80_mode && !(ctx->out_type & I80_HW_TRG))
>   return;
>  
>   if (!(ctx->out_type & I80_HW_TRG)) {
> @@ -209,7 +208,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   val = VIDOUT_LCD_ON;
>   if (interlaced)
>   val |= VIDOUT_INTERLACE_EN_F;
> - if (ctx->out_type & IFTYPE_I80) {
> + if (crtc->i80_mode) {
>   val |= VIDOUT_COMMAND_IF;
>   } else {
>   val |= VIDOUT_RGB_IF;
> @@ -225,7 +224,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   VIDTCON2_HOZVAL(m->hdisplay - 1);
>   writel(val, ctx->addr + DECON_VIDTCON2);
>  
> - if (!(ctx->out_type & IFTYPE_I80)) {
> + if (!crtc->i80_mode) {
>   int vbp = m->crtc_vtotal - m->crtc_vsync_end;
>   int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
>  
> @@ -513,6 +512,22 @@ static void decon_clear_channels(struct exynos_drm_crtc 
> *crtc)
>   clk_disable_unprepare(ctx->clks[i]);
>  }
>  
> +static enum drm_mode_status decon_mode_valid(struct exynos_drm_crtc *crtc,
> + const struct drm_display_mode *mode)
> +{
> + struct decon_context *ctx = crtc->ctx;
> +
> + ctx->irq = crtc->i80_mode ? ctx->irq_lcd_sys : ctx->irq_vsync;
> +
> + if (ctx->irq)
> + return MODE_OK;
> +
> + dev_info(ctx->dev, "Sink requires %s mode, but appropriate interrupt is 
> not provided.\n",
> + crtc->i80_mode ? "command" : "video");
> +
> + return MODE_BAD;
> +}
> +
>  static const struct exynos_drm_crtc_ops decon_crtc_ops = {
>   .enable = decon_enable,
>   .disable= decon_disable,
> @@ -522,6 +537,7 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
>   .atomic_begin   = decon_atomic_begin,
>   .update_plane   = decon_update_plane,
>   .disable_plane  = decon_disable_plane,
> + .mode_valid = decon_mode_valid,
>   .atomic_flush   = decon_atomic_flush,
>  };
>  
> @@ -715,11 +731,8 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>   ctx->out_type = (unsigned long)of_device_get_match_data(dev);
>   spin_lock_init(>vblank_lock);
>  
> - if (ctx->out_type & IFTYPE_HDMI) {
> + if (ctx->out_type & IFTYPE_HDMI)
>   ctx->first_win = 1;
> - } else if (of_get_child_by_name(dev->of_node, "i80-if-timings")) {
> - ctx->out_type |= IFTYPE_I80;
> - }
>  
>   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
>   struct clk *clk;
> @@ -753,9 +766,6 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>   return ret;
>   ctx->irq_lcd_sys = ret;
>  
> - ctx->irq = 

Re: [PATCH v2 03/10] drm/exynos/dsi: refactor panel detection logic

[Inki Dae]

2017년 08월 24일 22:33에 Andrzej Hajda 이(가) 쓴 글:
> Description of drm_helper_hpd_irq_event clearly states that drivers
> supporting hotplug events per connector should use different helper -
> drm_kms_helper_hotplug_event. To achieve it following changes have
> been performed:
> - moved down all DSI ops - they require exynos_dsi_disable function
> to be defined earlier,
> - simplified exynos_dsi_detect - there is no real detection, it just
> returns if panel is attached,
> - DSI attach/detach callbacks attaches/detaches DRM panel and sets
> connector status and other context fields accordingly, all this is
> performed under mutex, as these callbacks are asynchronous.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 203 
> 
>  1 file changed, 102 insertions(+), 101 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 6b46df6..063bac3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -254,7 +254,6 @@ struct exynos_dsi {
>   struct drm_encoder encoder;
>   struct mipi_dsi_host dsi_host;
>   struct drm_connector connector;
> - struct device_node *panel_node;
>   struct drm_panel *panel;
>   struct device *dev;
>  
> @@ -1329,12 +1328,13 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
>   return 0;
>  }
>  
> -static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
> +static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
> +   struct device *panel)
>  {
>   int ret;
>   int te_gpio_irq;
>  
> - dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
> + dsi->te_gpio = of_get_named_gpio(panel->of_node, "te-gpios", 0);
>   if (dsi->te_gpio == -ENOENT)
>   return 0;
>  
> @@ -1374,85 +1374,6 @@ static void exynos_dsi_unregister_te_irq(struct 
> exynos_dsi *dsi)
>   }
>  }
>  
> -static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> -   struct mipi_dsi_device *device)
> -{
> - struct exynos_dsi *dsi = host_to_dsi(host);
> -
> - dsi->lanes = device->lanes;
> - dsi->format = device->format;
> - dsi->mode_flags = device->mode_flags;
> - dsi->panel_node = device->dev.of_node;
> -
> - /*
> -  * This is a temporary solution and should be made by more generic way.
> -  *
> -  * If attached panel device is for command mode one, dsi should register
> -  * TE interrupt handler.
> -  */
> - if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO)) {
> - int ret = exynos_dsi_register_te_irq(dsi);
> -
> - if (ret)
> - return ret;
> - }
> -
> - if (dsi->connector.dev)
> - drm_helper_hpd_irq_event(dsi->connector.dev);
> -
> - return 0;
> -}
> -
> -static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
> -   struct mipi_dsi_device *device)
> -{
> - struct exynos_dsi *dsi = host_to_dsi(host);
> -
> - exynos_dsi_unregister_te_irq(dsi);
> -
> - dsi->panel_node = NULL;
> -
> - if (dsi->connector.dev)
> - drm_helper_hpd_irq_event(dsi->connector.dev);
> -
> - return 0;
> -}
> -
> -static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
> - const struct mipi_dsi_msg *msg)

I fixed below error.

ERROR: code indent should use tabs where possible
#364: FILE: drivers/gpu/drm/exynos/exynos_drm_dsi.c:1581:
+^I^I^I^Iconst struct mipi_dsi_msg *msg)$


Thanks,
Inki Dae
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Ong, Hean Loong]

Hi Laurent,

The encoder resides as a hardware logic as part of the FPGA fabric. The
software driver has no direct access to the encoder. The VIP is created
in such a way that the software i.e Linux Driver only streams data
through the VIP. What happens beyond the VIP Frame buffer directly
boils down to the FGPA logic design that is provided in the dev kit.

In this example the hardware A10 dev kit has a Display Port IP attached
to the VIP therefore from the drivers perspective we only know that the
endpoint is a Display Port

The system design uses the VIP FRame Buffer II as the default display
interface for various FPGA display IP (HDMI/DP). The FPGA bridge design
only provides the drivers to access the VIP.

Note there is also a soft Processor running on the FPGA that drives the
video signal transceivers for the Display Port or any other display
IP. 

The encoder used for the Intel FPGA VIP are hardware based therefore
the video device that is concerned here is the VIP Frame Buffer device
which streams data to whatever FPGA display hardware.

To describe the hardware encoder do I need to create it as part of the
device tree node or a explanation of it would suffice ?

On Thu, 2017-08-24 at 12:39 +0300, Laurent Pinchart wrote:
> Hi Hean Loong,
> 
> On Thursday, 24 August 2017 08:41:50 EEST Ong, Hean Loong wrote:
> > 
> > Hi Laurent,
> > 
> > I removed the examples for the HDMI in the draft below. The
> > connections
> > between the VIP and Display Port IP or any display connector are
> > determined by HW logic. There are currently no SW defined encoders
> > or
> > connectors that is connected to the AVALON-ST other than the Intel
> > VIP
> > Frame Buffer II. Therefore there are no examples for the Display
> > Port
> > encoder and connector.
> But there must be an encoder, even if its default configuration makes
> it 
> usable without a softwarer driver at the moment. As the encoder is
> there in 
> hardware, it should be described in DT.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

[Ard Biesheuvel]

On 24 August 2017 at 01:57, Dave Airlie  wrote:
>> Yeah, maybe it's time to disconnect the "default display device" idea
>> from the VGA arbiter.  I have no idea what (if any) dependencies X has
>> on the legacy VGA resources.  I assume X works fine on power, where it
>> sounds like those resources are rarely or never available.
>
> The question on non-x86 archs, is what is the correct device to default to.
>
> On x86 we use the legacy VGA resources as a pointer, as this is the device
> the BIOS appeared on at boot so hopefully should be one you can see stuff on.
>
> On non-x86 I've no idea how to decide if there are multiple devices, maybe the
> firmware needs to tag something for the kernel if there are. Otherwise
> you'd just
> be picking something in probe order.
>
> I think the idea of these patches is to separate default display
> device from the arbiter.
>
> X uses the arbiter on x86 if required (it's horrible, and it's rare we
> have to nowadays),
> but for finding the default device it justs uses the sysfs boot_vga flag.
>

Part of the problem is that X refuses to start if there is only one
display device to begin with in case it hasn't taken ownership of the
VGA legacy resources.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/15] remoteproc: make device_type const

[Bjorn Andersson]

On Sat 19 Aug 01:22 PDT 2017, Bhumika Goyal wrote:

> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 

Applied, thanks.

Regards,
Bjorn

> ---
>  drivers/remoteproc/remoteproc_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 364ef28..48b2c5d 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1360,7 +1360,7 @@ static void rproc_type_release(struct device *dev)
>   kfree(rproc);
>  }
>  
> -static struct device_type rproc_type = {
> +static const struct device_type rproc_type = {
>   .name   = "remoteproc",
>   .release= rproc_type_release,
>  };
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

[Bjorn Helgaas]

On Thu, Aug 24, 2017 at 10:57:26AM +1000, Dave Airlie wrote:
> > Yeah, maybe it's time to disconnect the "default display device" idea
> > from the VGA arbiter.  I have no idea what (if any) dependencies X has
> > on the legacy VGA resources.  I assume X works fine on power, where it
> > sounds like those resources are rarely or never available.
> 
> The question on non-x86 archs, is what is the correct device to default to.
> 
> On x86 we use the legacy VGA resources as a pointer, as this is the device
> the BIOS appeared on at boot so hopefully should be one you can see stuff on.
> 
> On non-x86 I've no idea how to decide if there are multiple devices, maybe the
> firmware needs to tag something for the kernel if there are. Otherwise
> you'd just
> be picking something in probe order.
> 
> I think the idea of these patches is to separate default display
> device from the arbiter.
> 
> X uses the arbiter on x86 if required (it's horrible, and it's rare we
> have to nowadays),
> but for finding the default device it justs uses the sysfs boot_vga flag.

The sysfs boot_vga thing comes from PCI.  The name suggests that it's
a VGA device and can use the legacy VGA resources.

If we want to indicate a general default display device that need not
be "VGA", it'd be really nice if we could pick a name that did not
include "vga".

Even if we could only do it inside the kernel, I think it would reduce
confusion if we could separate out the "VGA"-specific stuff like the
arbiter and names like "vga_set_default_device()" so that systems with
a non-legacy VGA default display device didn't have to use "VGA"
interfaces that don't make sense for them.

Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/15] PCI: make device_type const

[Bjorn Helgaas]

On Sat, Aug 19, 2017 at 01:52:19PM +0530, Bhumika Goyal wrote:
> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 

Applied to pci/misc for v4.14, thanks!

> ---
>  drivers/pci/endpoint/pci-epf-core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/endpoint/pci-epf-core.c 
> b/drivers/pci/endpoint/pci-epf-core.c
> index 6877d6a..9d0de12 100644
> --- a/drivers/pci/endpoint/pci-epf-core.c
> +++ b/drivers/pci/endpoint/pci-epf-core.c
> @@ -27,7 +27,7 @@
>  #include 
>  
>  static struct bus_type pci_epf_bus_type;
> -static struct device_type pci_epf_type;
> +static const struct device_type pci_epf_type;
>  
>  /**
>   * pci_epf_linkup() - Notify the function driver that EPC device has
> @@ -275,7 +275,7 @@ static void pci_epf_dev_release(struct device *dev)
>   kfree(epf);
>  }
>  
> -static struct device_type pci_epf_type = {
> +static const struct device_type pci_epf_type = {
>   .release= pci_epf_dev_release,
>  };
>  
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/syncobj: Add a signal ioctl

[Jason Ekstrand]

This IOCTL provides a mechanism for userspace to trigger a sync object
directly.  There are other ways that userspace can trigger a syncobj
such as submitting a dummy batch somewhere or hanging on to a triggered
sync_file and doing an import.  This just provides an easy way to
manually trigger the sync object without weird hacks.

The motivation for this IOCTL is Vulkan fences.  Vulkan lets you create
a fence already in the signaled state so that you can wait on it
immediatly without stalling.  We could also handle this with a new
create flag to ask the driver to create a syncobj that is already
signaled but the IOCTL seemed a bit cleaner and more generic.

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/drm_internal.h |  2 ++
 drivers/gpu/drm/drm_ioctl.c|  2 ++
 drivers/gpu/drm/drm_syncobj.c  | 71 ++
 include/uapi/drm/drm.h |  6 
 4 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 83f1615..fbc3f30 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -171,3 +171,5 @@ int drm_syncobj_wait_ioctl(struct drm_device *dev, void 
*data,
   struct drm_file *file_private);
 int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4185483..4d8f548 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -661,6 +661,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 7dfdb98..8d3112e 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -831,3 +831,74 @@ drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
 
return 0;
 }
+
+struct drm_syncobj_null_fence {
+   struct dma_fence base;
+   spinlock_t lock;
+};
+
+static const char *drm_syncobj_null_fence_get_name(struct dma_fence *fence)
+{
+return "syncobjnull";
+}
+
+static bool drm_syncobj_null_fence_enable_signaling(struct dma_fence *fence)
+{
+dma_fence_enable_sw_signaling(fence);
+return !dma_fence_is_signaled(fence);
+}
+
+static const struct dma_fence_ops drm_syncobj_null_fence_ops = {
+   .get_driver_name = drm_syncobj_null_fence_get_name,
+   .get_timeline_name = drm_syncobj_null_fence_get_name,
+   .enable_signaling = drm_syncobj_null_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+   .release = NULL,
+};
+
+static struct dma_fence *drm_syncobj_create_null_fence(void)
+{
+   struct drm_syncobj_null_fence *fence;
+   fence = kzalloc(sizeof(*fence), GFP_KERNEL);
+   if (fence == NULL)
+   return NULL;
+
+   spin_lock_init(>lock);
+   dma_fence_init(>base, _syncobj_null_fence_ops,
+  >lock, 0, 0);
+   return >base;
+}
+
+int
+drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private)
+{
+   struct drm_syncobj_signal *args = data;
+   struct drm_syncobj *syncobj;
+   struct dma_fence *null_fence;
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -ENODEV;
+
+   if (args->flags != 0)
+   return -EINVAL;
+
+   syncobj = drm_syncobj_find(file_private, args->handle);
+   if (!syncobj)
+   return -ENOENT;
+
+   null_fence = drm_syncobj_create_null_fence();
+   if (!null_fence) {
+   drm_syncobj_put(syncobj);
+   return -ENOMEM;
+   }
+
+   dma_fence_signal(null_fence);
+
+   drm_syncobj_replace_fence(syncobj, null_fence);
+
+   dma_fence_put(null_fence);
+   drm_syncobj_put(syncobj);
+
+   return 0;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index f8ec8fe..350a6a2 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -735,6 +735,11 @@ struct drm_syncobj_reset {
__u32 flags;
 };
 
+struct drm_syncobj_signal {
+   __u32 handle;
+   __u32 flags;
+};
+
 #if defined(__cplusplus)
 }
 #endif
@@ -859,6 +864,7 @@ extern "C" {
 #define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE DRM_IOWR(0xC2, struct 
drm_syncobj_handle)
 #define DRM_IOCTL_SYNCOBJ_WAIT DRM_IOWR(0xC3, struct drm_syncobj_wait)
 #define DRM_IOCTL_SYNCOBJ_RESETDRM_IOWR(0xC4, 

Re: [PATCH v3] drm/i915: Deal with upside-down mounted LCD panels

[kbuild test robot]

Hi Hans,

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

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-i915-Deal-with-upside-down-mounted-LCD-panels/20170825-061654
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x009-201734 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_display.c: In function 
'intel_fixup_initial_subpixel_order':
>> drivers/gpu/drm/i915/intel_display.c:2804:2: error: enumeration value 
>> 'SubPixelUnknown' not handled in switch [-Werror=switch]
 switch (connector->display_info.subpixel_order) {
 ^~
>> drivers/gpu/drm/i915/intel_display.c:2804:2: error: enumeration value 
>> 'SubPixelNone' not handled in switch [-Werror=switch]
   Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
   Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
   Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:set_bit
   Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:clear_bit
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:ffs
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
   Cyclomatic Complexity 1 include/linux/bitops.h:fls_long
   Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
   Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
   Cyclomatic Complexity 1 include/linux/log2.h:__roundup_pow_of_two
   Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
   Cyclomatic Complexity 1 include/linux/list.h:__list_del
   Cyclomatic Complexity 2 include/linux/list.h:__list_del_entry
   Cyclomatic Complexity 1 include/linux/list.h:list_del
   Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 include/linux/err.h:ERR_CAST
   Cyclomatic Complexity 2 include/linux/err.h:PTR_ERR_OR_ZERO
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_read
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_inc
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_dec
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_dec_and_test
   Cyclomatic Complexity 2 arch/x86/include/asm/atomic.h:atomic_try_cmpxchg
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_or
   Cyclomatic Complexity 3 arch/x86/include/asm/atomic.h:__atomic_add_unless
   Cyclomatic Complexity 1 arch/x86/include/asm/atomic64_64.h:atomic64_read
   Cyclomatic Complexity 1 include/linux/atomic.h:atomic_add_unless
   Cyclomatic Complexity 1 include/asm-generic/atomic-long.h:atomic_long_read
   Cyclomatic Complexity 1 include/linux/lockdep.h:lock_is_held
   Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
   Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_save_flags
   Cyclomatic Complexity 1 include/linux/math64.h:div_u64_rem
   Cyclomatic Complexity 1 include/linux/math64.h:div_u64
   Cyclomatic Complexity 1 
arch/x86/include/asm/irqflags.h:arch_irqs_disabled_flags
   Cyclomatic Complexity 1 arch/x86/include/asm/processor.h:rep_nop
   Cyclomatic Complexity 1 arch/x86/include/asm/processor.h:cpu_relax
   Cyclomatic Complexity 1 include/linux/mutex.h:__mutex_owner
   Cyclomatic Complexity 1 include/linux/mutex.h:mutex_is_locked
   Cyclomatic Complexity 1 arch/x86/include/asm/preempt.h:preempt_count
   Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_add
   Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_sub
   Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_lock
   Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_unlock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_irq
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irq
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore
   Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
   Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
   Cyclomatic Complexity 1 include/linux/jiffies.h:_usecs_to_jiffies
   Cyclomatic Complexity 3 include/linux/jiffies.h:usecs_to_jiffies
   Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_lock_acquire
   Cyclomatic Complexity 1 include/

Re: [PATCH v3] drm/i915: Deal with upside-down mounted LCD panels

[kbuild test robot]

Hi Hans,

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

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-i915-Deal-with-upside-down-mounted-LCD-panels/20170825-061654
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x001-201734 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_display.c: In function 
'intel_fixup_initial_subpixel_order':
>> drivers/gpu/drm/i915/intel_display.c:2804:2: warning: enumeration value 
>> 'SubPixelUnknown' not handled in switch [-Wswitch]
 switch (connector->display_info.subpixel_order) {
 ^~
>> drivers/gpu/drm/i915/intel_display.c:2804:2: warning: enumeration value 
>> 'SubPixelNone' not handled in switch [-Wswitch]
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/dmi.h:4,
from drivers/gpu/drm/i915/intel_display.c:27:
   drivers/gpu/drm/i915/intel_display.c: At top level:
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:390:2: note: in expansion of macro 'if'
 if (p_size == (size_t)-1 && q_size == (size_t)-1)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:380:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:378:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr_inv' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:369:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr_inv' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:367:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:358:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:356:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memcmp' which is not static
   __f

[Bug 101026] RX 550 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

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

--- Comment #9 from dwagner  ---
Ok, then nothing left to fix for this report, it seems.
@Liam Murphy: Good to close this report then?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101026] RX 550 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

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

--- Comment #8 from Alex Deucher  ---
(In reply to dwagner from comment #7)
> 
> Does the xserver have its own, flawed EDID parser?

Yes, the xserver has it's own edid parser.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 93301] ns2_linux32: radeon VM fault on Hawaii (+mmap errors)

[bugzilla-daemon]

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

--- Comment #28 from famo  ---
I just want to report that with new mesa and cache NS2 runs as smooth as
butter, thanks to the devs!

System:Host: cray Kernel: 4.12.4-1-CHAKRA x86_64 (64 bit) Desktop: KDE
Plasma 5.10.4 Distro: Chakra
Machine:   Device: desktop Mobo: ASUSTeK model: A88XM-PLUS v: Rev X.0x UEFI:
American Megatrends v: 3003 date: 03/04/2017
CPU:   Quad core AMD A10-7850K Radeon R7 12 Compute Cores 4C+8G (-MCP-)
cache: 8192 KB 
   clock speeds: max: 4200 MHz 1: 4200 MHz 2: 3000 MHz 3: 3000 MHz 4:
3000 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Fiji [Radeon R9 FURY / NANO
Series]
   Display Server: x11 (X.Org 1.19.3) driver: amdgpu Resolution:
2560x1440@119.88hz
   OpenGL: renderer: Gallium 0.4 on AMD FIJI (DRM 3.15.0 /
4.12.4-1-CHAKRA, LLVM 4.0.1)
   version: 4.5 Mesa 17.1.5
Audio: Card-1 Advanced Micro Devices [AMD] FCH Azalia Controller driver:
snd_hda_intel
   Card-2 Advanced Micro Devices [AMD/ATI] Fiji HDMI/DP Audio
Controller driver: snd_hda_intel
   Sound: Advanced Linux Sound Architecture v: k4.12.4-1-CHAKRA
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
Sensors:   System Temperatures: cpu: 44.0C mobo: 34.0C gpu: 41.0
   Fan Speeds (in rpm): fan-1: 826 fan-2: 841 fan-3: 717
Info:  Processes: 213 Uptime: 11:34 Memory: 4278.6/15994.4MB Client: Shell
(bash) inxi: 2.3.23

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101026] RX 550 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

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

--- Comment #7 from dwagner  ---
(In reply to Alex Deucher from comment #6)
> (In reply to dwagner from comment #5)
> > [   133.973] (--) AMDGPU(0): HDMI max TMDS frequency 30KHz
> 
> The message is from the xserver, not the driver.  It's warning you because
> the clock for the mode exceeds the max TMDS clock as stated by the EDID.

Hmmm - when I "cat /usr/lib/firmware/edid/LG_EG9609_edid.bin | parse-edid", the
output contains:

  # Maximum pixel clock is 600MHz

Does the xserver have its own, flawed EDID parser?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/12] drm: Check that the plane supports the request format+modifier combo

[ville . syrjala]

From: Ville Syrjälä 

Currently we only check that the plane supports the pixel format of the
fb we're about to feed to it. Extend it to check also the modifier, and
more specifically that the combination of the format and modifier is
supported.

Cc: dri-devel@lists.freedesktop.org
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Cc: Daniel Stone 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic.c|  8 +---
 drivers/gpu/drm/drm_crtc.c  |  8 +---
 drivers/gpu/drm/drm_crtc_internal.h |  4 ++--
 drivers/gpu/drm/drm_plane.c | 31 +--
 4 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2fd383d7253a..51cd05a7360b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -884,12 +884,14 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
}
 
/* Check whether this plane supports the fb pixel format. */
-   ret = drm_plane_check_pixel_format(plane, state->fb->format->format);
+   ret = drm_plane_check_pixel_format(plane, state->fb->format->format,
+  state->fb->modifier);
if (ret) {
struct drm_format_name_buf format_name;
-   DRM_DEBUG_ATOMIC("Invalid pixel format %s\n",
+   DRM_DEBUG_ATOMIC("Invalid pixel format %s, modifier 0x%llx\n",
 drm_get_format_name(state->fb->format->format,
-_name));
+_name),
+state->fb->modifier);
return ret;
}
 
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5af25ce5bf7c..dd54deb75c0d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -625,12 +625,14 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
 */
if (!crtc->primary->format_default) {
ret = drm_plane_check_pixel_format(crtc->primary,
-  fb->format->format);
+  fb->format->format,
+  fb->modifier);
if (ret) {
struct drm_format_name_buf format_name;
-   DRM_DEBUG_KMS("Invalid pixel format %s\n",
+   DRM_DEBUG_KMS("Invalid pixel format %s, 
modifier 0x%llx\n",
  
drm_get_format_name(fb->format->format,
- 
_name));
+ _name),
+ fb->modifier);
goto out;
}
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index a43582076b20..81865841b656 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -194,8 +194,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 /* drm_plane.c */
 int drm_plane_register_all(struct drm_device *dev);
 void drm_plane_unregister_all(struct drm_device *dev);
-int drm_plane_check_pixel_format(const struct drm_plane *plane,
-u32 format);
+int drm_plane_check_pixel_format(struct drm_plane *plane,
+u32 format, u64 modifier);
 
 /* drm_bridge.c */
 void drm_bridge_detach(struct drm_bridge *bridge);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 7a00351d5b5d..c63a81e32e23 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -555,16 +555,33 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
return 0;
 }
 
-int drm_plane_check_pixel_format(const struct drm_plane *plane, u32 format)
+int drm_plane_check_pixel_format(struct drm_plane *plane,
+u32 format, u64 modifier)
 {
unsigned int i;
 
for (i = 0; i < plane->format_count; i++) {
if (format == plane->format_types[i])
-   return 0;
+   break;
+   }
+   if (i == plane->format_count)
+   return -EINVAL;
+
+   if (!plane->modifier_count)
+   return 0;
+
+   for (i = 0; i < plane->modifier_count; i++) {
+   if (modifier == plane->modifiers[i])
+   break;
}
+   if (i == plane->modifier_count)
+   return -EINVAL;
 
-   return -EINVAL;
+   if (plane->funcs->format_mod_supported &&
+   

[PATCH 10/12] drm: Fix modifiers_property kernel doc

[ville . syrjala]

From: Ville Syrjälä 

The member is called 'modifiers_property' instead of 'modifiers'. Adjust
the kernel docs to match.

Cc: dri-devel@lists.freedesktop.org
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Cc: Daniel Stone 
Signed-off-by: Ville Syrjälä 
---
 include/drm/drm_mode_config.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 1b37368416c8..6040c4b73e6d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -758,7 +758,7 @@ struct drm_mode_config {
bool allow_fb_modifiers;
 
/**
-* @modifiers: Plane property to list support modifier/format
+* @modifiers_property: Plane property to list support modifier/format
 * combination.
 */
struct drm_property *modifiers_property;
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][drm-next] drm/amdgpu: remove duplicate return statement

[Alex Deucher]

On Wed, Aug 23, 2017 at 2:24 PM, Felix Kuehling  wrote:
> I must have added that accidentally when cherry-picking an internal
> patch for upstreaming. Thanks for catching it.
>
> Reviewed-by: Felix Kuehling 

Applied.  thanks!

Alex

>
> Regards,
>   Felix
>
>
> On 2017-08-23 09:17 AM, Colin King wrote:
>> From: Colin Ian King 
>>
>> Remove a redundant identical return statement, it has no use.
>>
>> Detected by CoverityScan, CID#1454586 ("Structurally dead code")
>>
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
>> index fb6e5dbd5a03..309f2419c6d8 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
>> @@ -155,7 +155,6 @@ static const struct kfd2kgd_calls kfd2kgd = {
>>  struct kfd2kgd_calls *amdgpu_amdkfd_gfx_8_0_get_functions(void)
>>  {
>>   return (struct kfd2kgd_calls *)
>> - return (struct kfd2kgd_calls *)
>>  }
>>
>>  static inline struct amdgpu_device *get_amdgpu_device(struct kgd_dev *kgd)
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: check memory allocation failure

[Alex Deucher]

On Wed, Aug 23, 2017 at 4:39 AM, Christian König
 wrote:
> Am 23.08.2017 um 07:52 schrieb Christophe JAILLET:
>>
>> Check memory allocation failure and return -ENOMEM in such a case.
>>
>> 'num_post_dep_syncobjs' still has to be set to 0 before the test in order
>> to have it initialized if 'amdgpu_cs_parser_fini()' is called to free
>> resources.
>>
>> The calling graph would be, in such a case!
>> failure in amdgpu_cs_process_syncobj_out_dep()
>>---> error code returned by amdgpu_cs_dependencies()
>>   --> amdgpu_cs_parser_fini() is called
>>
>> Signed-off-by: Christophe JAILLET 
>
>
> Reviewed-by: Christian König 

Applied.  thanks!

Alex

>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> index 15d4a28d73bb..baa90df90aea 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@ -1079,6 +1079,9 @@ static int amdgpu_cs_process_syncobj_out_dep(struct
>> amdgpu_cs_parser *p,
>>  GFP_KERNEL);
>> p->num_post_dep_syncobjs = 0;
>>   + if (!p->post_dep_syncobjs)
>> +   return -ENOMEM;
>> +
>> for (i = 0; i < num_deps; ++i) {
>> p->post_dep_syncobjs[i] = drm_syncobj_find(p->filp,
>> deps[i].handle);
>> if (!p->post_dep_syncobjs[i])
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/5] vfs: add flags parameter to ->mmap() in 'struct file_operations'

[Dan Williams]

On Thu, Aug 24, 2017 at 9:58 AM, Christoph Hellwig  wrote:
> On Wed, Aug 23, 2017 at 04:48:40PM -0700, Dan Williams wrote:
>> We are running running short of vma->vm_flags. We can avoid needing a
>> new VM_* flag in some cases if the original @flags submitted to mmap(2)
>> is made available to the ->mmap() 'struct file_operations'
>> implementation. For example, the proposed addition of MAP_DIRECT can be
>> implemented without taking up a new vm_flags bit. Another motivation to
>> avoid vm_flags is that they appear in /proc/$pid/smaps, and we have seen
>> software that tries to dangerously (TOCTOU) read smaps to infer the
>> behavior of a virtual address range.
>>
>> This conversion was performed by the following semantic patch. There
>> were a few manual edits for oddities like proc_reg_mmap.
>>
>> Thanks to Julia for helping me with coccinelle iteration to cover cases
>> where the mmap routine is defined in a separate file from the 'struct
>> file_operations' instance that consumes it.
>
> How are we going to check that an instance actually supports any
> of those flags?

In patch 3 I validate the flags by introducing an
"mmap_supported_mask" field to 'struct file_operations'. It will be
zero by default for almost all implementations and zero means "support
the legacy mmap flags".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/sii8620: Fix memory corruption

[Andrzej Hajda]

On 21.08.2017 12:32, Maciej Purski wrote:
> Function sii8620_mt_read_devcap_reg_recv() used to read array index
> from a wrong msg register, which caused writing out of array
> bounds. It led to writing on other fields of struct sii8620.
>
> Signed-off-by: Maciej Purski 
> Fixes: e9c6da270 ("drm/bridge/sii8620: add reading device capability
>registers")
> ---

Queued to drm-misc-fixes.

Regards
Andrzej

>  drivers/gpu/drm/bridge/sil-sii8620.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 2d51a22..5131bfb 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -597,9 +597,9 @@ static void sii8620_mt_read_devcap(struct sii8620 *ctx, 
> bool xdevcap)
>  static void sii8620_mt_read_devcap_reg_recv(struct sii8620 *ctx,
>   struct sii8620_mt_msg *msg)
>  {
> - u8 reg = msg->reg[0] & 0x7f;
> + u8 reg = msg->reg[1] & 0x7f;
>  
> - if (msg->reg[0] & 0x80)
> + if (msg->reg[1] & 0x80)
>   ctx->xdevcap[reg] = msg->ret;
>   else
>   ctx->devcap[reg] = msg->ret;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rename u32 in __u32 in uapi

[Ben Widawsky]

On 17-08-24 17:55:35, Emil Velikov wrote:

On 24 August 2017 at 16:08, Lionel Landwerlin
 wrote:

All other fields use __


Fairly sure I mentioned it at some point - I might have been tad vague
though :-\

Thanks for the fix, Lionel.
Reviewed-by: Emil Velikov 


I'm sure it was fixed at some point.

   v5:
   Rename modifiers to modifiers_property (Ville)
   Use sizeof(__u32) instead to reflect UAPI nature (Ville)
   Make BUILD_BUG_ON for blob header size

Reviewed-by: Ben Widawsky 



-Emil

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/5] vfs: add flags parameter to ->mmap() in 'struct file_operations'

[Christoph Hellwig]

On Wed, Aug 23, 2017 at 04:48:40PM -0700, Dan Williams wrote:
> We are running running short of vma->vm_flags. We can avoid needing a
> new VM_* flag in some cases if the original @flags submitted to mmap(2)
> is made available to the ->mmap() 'struct file_operations'
> implementation. For example, the proposed addition of MAP_DIRECT can be
> implemented without taking up a new vm_flags bit. Another motivation to
> avoid vm_flags is that they appear in /proc/$pid/smaps, and we have seen
> software that tries to dangerously (TOCTOU) read smaps to infer the
> behavior of a virtual address range.
> 
> This conversion was performed by the following semantic patch. There
> were a few manual edits for oddities like proc_reg_mmap.
> 
> Thanks to Julia for helping me with coccinelle iteration to cover cases
> where the mmap routine is defined in a separate file from the 'struct
> file_operations' instance that consumes it.

How are we going to check that an instance actually supports any
of those flags?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rename u32 in __u32 in uapi

[Emil Velikov]

On 24 August 2017 at 16:08, Lionel Landwerlin
 wrote:
> All other fields use __
>
Fairly sure I mentioned it at some point - I might have been tad vague
though :-\

Thanks for the fix, Lionel.
Reviewed-by: Emil Velikov 

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/15] [media] i2c: make device_type const

[Guennadi Liakhovetski]

On Sat, 19 Aug 2017, Bhumika Goyal wrote:

> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 

Acked-by: Guennadi Liakhovetski 

Thanks
Guennadi

> ---
>  drivers/media/i2c/soc_camera/mt9t031.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/soc_camera/mt9t031.c 
> b/drivers/media/i2c/soc_camera/mt9t031.c
> index 714fb35..4802d30 100644
> --- a/drivers/media/i2c/soc_camera/mt9t031.c
> +++ b/drivers/media/i2c/soc_camera/mt9t031.c
> @@ -592,7 +592,7 @@ static int mt9t031_runtime_resume(struct device *dev)
>   .runtime_resume = mt9t031_runtime_resume,
>  };
>  
> -static struct device_type mt9t031_dev_type = {
> +static const struct device_type mt9t031_dev_type = {
>   .name   = "MT9T031",
>   .pm = _dev_pm_ops,
>  };
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 0/5] MAP_DIRECT and block-map-atomic files

[Dan Williams]

On Thu, Aug 24, 2017 at 9:08 AM, Christoph Hellwig  wrote:
> This seems to be missing patches 1 and 3.

Sorry, I didn't cc you directly on those. They're on the list:

https://patchwork.kernel.org/patch/9918657/
https://patchwork.kernel.org/patch/9918663/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:drm-next-4.14-wip 22/26] drivers/gpu//drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of 'ttm_populate_and_map_pages'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.14-wip
head:   c758030e1ef4a616b0be7c382dddf78dbb00aa57
commit: 32e5d3aa64d35ccb3ed94315e4504a3907a5fb77 [22/26] drm/ttm: Add helper 
functions to populate/map in one call (v2)
config: i386-randconfig-x074-201734 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 32e5d3aa64d35ccb3ed94315e4504a3907a5fb77
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/gpu//drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of 
>> 'ttm_populate_and_map_pages'
int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
^~
   In file included from drivers/gpu//drm/ttm/ttm_page_alloc.c:49:0:
   include/drm/ttm/ttm_page_alloc.h:120:19: note: previous definition of 
'ttm_populate_and_map_pages' was here
static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
  ^~
>> drivers/gpu//drm/ttm/ttm_page_alloc.c:950:6: error: redefinition of 
>> 'ttm_unmap_and_unpopulate_pages'
void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt 
*tt)
 ^~
   In file included from drivers/gpu//drm/ttm/ttm_page_alloc.c:49:0:
   include/drm/ttm/ttm_page_alloc.h:125:20: note: previous definition of 
'ttm_unmap_and_unpopulate_pages' was here
static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, 
struct ttm_dma_tt *tt)
   ^~

vim +/ttm_populate_and_map_pages +923 drivers/gpu//drm/ttm/ttm_page_alloc.c

   922  
 > 923  int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt 
 > *tt)
   924  {
   925  unsigned i;
   926  int r;
   927  
   928  r = ttm_pool_populate(>ttm);
   929  if (r)
   930  return r;
   931  
   932  for (i = 0; i < tt->ttm.num_pages; i++) {
   933  tt->dma_address[i] = dma_map_page(dev, tt->ttm.pages[i],
   9340, PAGE_SIZE,
   935DMA_BIDIRECTIONAL);
   936  if (dma_mapping_error(dev, tt->dma_address[i])) {
   937  while (i--) {
   938  dma_unmap_page(dev, tt->dma_address[i],
   939 PAGE_SIZE, 
DMA_BIDIRECTIONAL);
   940  tt->dma_address[i] = 0;
   941  }
   942  ttm_pool_unpopulate(>ttm);
   943  return -EFAULT;
   944  }
   945  }
   946  return 0;
   947  }
   948  EXPORT_SYMBOL(ttm_populate_and_map_pages);
   949  
 > 950  void ttm_unmap_and_unpopulate_pages(struct device *dev, struct 
 > ttm_dma_tt *tt)
   951  {
   952  unsigned i;
   953  
   954  for (i = 0; i < tt->ttm.num_pages; i++) {
   955  if (tt->dma_address[i]) {
   956  dma_unmap_page(dev, tt->dma_address[i],
   957 PAGE_SIZE, DMA_BIDIRECTIONAL);
   958  }
   959  }
   960  ttm_pool_unpopulate(>ttm);
   961  }
   962  EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
   963  

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


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/10] drm/exynos/decon5433: use readl_poll_timeout helpers

[Andrzej Hajda]

On 24.08.2017 15:54, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> Linux core provide helpers for polling with timeout, lets use them.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20 
>>  1 file changed, 8 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> index 5792ca88..237b4c9 100644
>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -407,24 +408,19 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
>> *crtc)
>>  
>>  static void decon_swreset(struct decon_context *ctx)
>>  {
>> -unsigned int tries;
>>  unsigned long flags;
>> +u32 val;
>> +int ret;
>>  
>>  writel(0, ctx->addr + DECON_VIDCON0);
>> -for (tries = 2000; tries; --tries) {
>> -if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_STOP_STATUS)
>> -break;
>> -udelay(10);
>> -}
>> +readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
>> +   ~val & VIDCON0_STOP_STATUS, 12, 2);
> Wouldn't it be more consistent to also check for a timeout here?

Timeout here is not an error, ie it happens for example in interlace mode.

Regards
Andrzej

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 0/5] MAP_DIRECT and block-map-atomic files

[Christoph Hellwig]

This seems to be missing patches 1 and 3.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102391] x11-libs/libdrm-2.4.83: fatal error: uve_ib.h: No such file or directory

[bugzilla-daemon]

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

Bug ID: 102391
   Summary: x11-libs/libdrm-2.4.83: fatal error: uve_ib.h: No such
file or directory
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: freedesk...@lermytte.be

Created attachment 133754
  --> https://bugs.freedesktop.org/attachment.cgi?id=133754=edit
build.log

WIth the source tarball from https://dri.freedesktop.org/libdrm/${P}.tar.bz2, I
get, on a Gentoo system:

(...)
Making all in radeon
libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wextra -Wsign-compare
-Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -Wpacked -Wswitch-enum -Wmissing-format-attribute
-Wstrict-aliasing=2 -Winit-self -Wdeclaration-after-statement
-Wold-style-definition -Wno-unused-parameter -Wno-attributes -Wno-long-long
-Winline -Wshadow -Wno-missing-field-initializers -I
/var/tmp/portage/x11-libs/libdrm-2.4.83/work/libdrm-2.4.83/include/drm -I
/var/tmp/portage/x11-libs/libdrm-2.4.83/work/libdrm-2.4.83 -O2 -march=native
-pipe -fomit-frame-pointer -Wl,-O1 -o .libs/radeon_ttm rbo.o radeon_ttm.o 
-Wl,--as-needed ../../.libs/libdrm.so -lm
Making all in amdgpu
/var/tmp/portage/x11-libs/libdrm-2.4.83/work/libdrm-2.4.83/tests/amdgpu/basic_tests.c:
In function ‘amdgpu_userptr_test’:
/var/tmp/portage/x11-libs/libdrm-2.4.83/work/libdrm-2.4.83/tests/amdgpu/basic_tests.c:1369:2:
warning: ignoring return value of ‘posix_memalign’, declared with attribute
warn_unused_result [-Wunused-result]
  posix_memalign(, sysconf(_SC_PAGE_SIZE), BUFFER_SIZE);
  ^
/var/tmp/portage/x11-libs/libdrm-2.4.83/work/libdrm-2.4.83/tests/amdgpu/uvd_enc_tests.c:39:20:
fatal error: uve_ib.h: No such file or directory
 #include "uve_ib.h"
^
compilation terminated.
make[3]: *** [amdgpu_test-uvd_enc_tests.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1

Full build log in attachment

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rename u32 in __u32 in uapi

[Lionel Landwerlin]

Forgot to Cc the appropriate people :/

On 24/08/17 16:08, Lionel Landwerlin wrote:

All other fields use __

Cc: Ben Widawsky 
Fixes: db1689aa61b ("drm: Create a format/modifier blob")
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson 
---
  include/uapi/drm/drm_mode.h | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index a2bb7161f020..54fc38c3c3f1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -715,24 +715,24 @@ struct drm_mode_atomic {
  struct drm_format_modifier_blob {
  #define FORMAT_BLOB_CURRENT 1
/* Version of this blob format */
-   u32 version;
+   __u32 version;
  
  	/* Flags */

-   u32 flags;
+   __u32 flags;
  
  	/* Number of fourcc formats supported */

-   u32 count_formats;
+   __u32 count_formats;
  
  	/* Where in this blob the formats exist (in bytes) */

-   u32 formats_offset;
+   __u32 formats_offset;
  
  	/* Number of drm_format_modifiers */

-   u32 count_modifiers;
+   __u32 count_modifiers;
  
  	/* Where in this blob the modifiers exist (in bytes) */

-   u32 modifiers_offset;
+   __u32 modifiers_offset;
  
-	/* u32 formats[] */

+   /* __u32 formats[] */
/* struct drm_format_modifier modifiers[] */
  };
  



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: rename u32 in __u32 in uapi

[Lionel Landwerlin]

All other fields use __

Cc: Ben Widawsky 
Fixes: db1689aa61b ("drm: Create a format/modifier blob")
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson 
---
 include/uapi/drm/drm_mode.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index a2bb7161f020..54fc38c3c3f1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -715,24 +715,24 @@ struct drm_mode_atomic {
 struct drm_format_modifier_blob {
 #define FORMAT_BLOB_CURRENT 1
/* Version of this blob format */
-   u32 version;
+   __u32 version;
 
/* Flags */
-   u32 flags;
+   __u32 flags;
 
/* Number of fourcc formats supported */
-   u32 count_formats;
+   __u32 count_formats;
 
/* Where in this blob the formats exist (in bytes) */
-   u32 formats_offset;
+   __u32 formats_offset;
 
/* Number of drm_format_modifiers */
-   u32 count_modifiers;
+   __u32 count_modifiers;
 
/* Where in this blob the modifiers exist (in bytes) */
-   u32 modifiers_offset;
+   __u32 modifiers_offset;
 
-   /* u32 formats[] */
+   /* __u32 formats[] */
/* struct drm_format_modifier modifiers[] */
 };
 
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

[bugzilla-daemon]

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

--- Comment #3 from jeremi.jasin...@gmail.com ---
Created attachment 133751
  --> https://bugs.freedesktop.org/attachment.cgi?id=133751=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
Please attach your dmesg output as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

[bugzilla-daemon]

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

--- Comment #1 from jeremi.jasin...@gmail.com ---
Created attachment 133750
  --> https://bugs.freedesktop.org/attachment.cgi?id=133750=edit
xorg.log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

[bugzilla-daemon]

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

Bug ID: 102389
   Summary: Random black screen on RX 470, HDMI 4k-60Hz
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jeremi.jasin...@gmail.com

I am using amd-staging on arch linux -
https://aur.archlinux.org/packages/linux-amd-staging-git/ and AMD RX 470.

I have 4k monitor (AOC U2879VF), which display port connector has broken, so
i'm forced to use HDMI. On dp there were no problem, unfortunately while using
HDMI 4k 60Hz I get random black screen, lasting for 1-2 seconds, while using my
computer (watching movie, playing games, or browsing internet). 

The black screens happens since at least 4.11 amd-staging-git version.

I attached dmesg log, and xorg log. If you need something else please tell me.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

Matt Turner  changed:

   What|Removed |Added

Summary|[KBL] gfx corruption on |gfx corruption on windowed
   |windowed 3d-apps running on |3d-apps running on dGPU
   |dGPU|

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes

[Sean Paul]

Hi Dave,
One fix which is cc:stable from Chris this week. The patch fixes a race where
the driver could still be tracking a gem object while its handle has already
been recycled.

drm-misc-fixes-2017-08-24:
Core Changes:
- Release driver tracking before making the object available again (Chris)

Cc: Chris Wilson 

Cheers, Sean


The following changes since commit a0ffc51e20e90e0c1c2491de2b4b03f48b6caaba:

  drm/atomic: If the atomic check fails, return its value first (2017-08-15 
12:38:05 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-08-24

for you to fetch changes up to fe4600a548f2763dec91b3b27a1245c370ceee2a:

  drm: Release driver tracking before making the object available again 
(2017-08-22 16:03:43 +0300)


Core Changes:
- Release driver tracking before making the object available again (Chris)

Cc: Chris Wilson 


Chris Wilson (1):
  drm: Release driver tracking before making the object available again

 drivers/gpu/drm/drm_gem.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/10] drm/exynos/decon5433: use readl_poll_timeout helpers

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> Linux core provide helpers for polling with timeout, lets use them.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 5792ca88..237b4c9 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -407,24 +408,19 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
> *crtc)
>  
>  static void decon_swreset(struct decon_context *ctx)
>  {
> - unsigned int tries;
>   unsigned long flags;
> + u32 val;
> + int ret;
>  
>   writel(0, ctx->addr + DECON_VIDCON0);
> - for (tries = 2000; tries; --tries) {
> - if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_STOP_STATUS)
> - break;
> - udelay(10);
> - }
> + readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
> +~val & VIDCON0_STOP_STATUS, 12, 2);
Wouldn't it be more consistent to also check for a timeout here?

With best wishes,
Tobias



>   writel(VIDCON0_SWRESET, ctx->addr + DECON_VIDCON0);
> - for (tries = 2000; tries; --tries) {
> - if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_SWRESET)
> - break;
> - udelay(10);
> - }
> + ret = readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
> +  ~val & VIDCON0_SWRESET, 12, 2);
>  
> - WARN(tries == 0, "failed to software reset DECON\n");
> + WARN(ret < 0, "failed to software reset DECON\n");
>  
>   spin_lock_irqsave(>vblank_lock, flags);
>   ctx->frame_id = 0;
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 10/10] arm64: dts: exynos: remove i80-if-timings nodes

[Andrzej Hajda]

Since i80/command mode is determined in runtime by propagating info
from panel this property can be removed.

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e2b0da2..105b293 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -280,9 +280,6 @@
 
  {
status = "okay";
-
-   i80-if-timings {
-   };
 };
 
 _tv {
@@ -1116,9 +1113,6 @@
 
  {
status = "okay";
-
-   i80-if-timings {
-   };
 };
 
 _system_controller {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 08/10] drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode

[Andrzej Hajda]

Since panel's mode of work is propagated properly from panel to DECON,
there is no need to use redundant private device tree property.
The only issue with such approach is that check for required interrupts
should be postponed until panel communicate its requirements, ie to
mode validation phase - mode_valid callback.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 40 +--
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 0f5acce..da183e0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -34,9 +34,8 @@
 #define WINDOWS_NR 3
 #define MIN_FB_WIDTH_FOR_16WORD_BURST  128
 
-#define IFTYPE_I80 (1 << 0)
-#define I80_HW_TRG (1 << 1)
-#define IFTYPE_HDMI(1 << 2)
+#define I80_HW_TRG (1 << 0)
+#define IFTYPE_HDMI(1 << 1)
 
 static const char * const decon_clks_name[] = {
"pclk",
@@ -93,7 +92,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
u32 val;
 
val = VIDINTCON0_INTEN;
-   if (ctx->out_type & IFTYPE_I80)
+   if (crtc->i80_mode)
val |= VIDINTCON0_FRAMEDONE;
else
val |= VIDINTCON0_INTFRMEN | VIDINTCON0_FRAMESEL_FP;
@@ -142,7 +141,7 @@ static u32 decon_get_frame_count(struct decon_context *ctx, 
bool end)
 
switch (status & (VIDCON1_VSTATUS_MASK | VIDCON1_I80_ACTIVE)) {
case VIDCON1_VSTATUS_VS:
-   if (!(ctx->out_type & IFTYPE_I80))
+   if (!(ctx->crtc->i80_mode))
--frm;
break;
case VIDCON1_VSTATUS_BP:
@@ -169,7 +168,7 @@ static u32 decon_get_vblank_counter(struct exynos_drm_crtc 
*crtc)
 
 static void decon_setup_trigger(struct decon_context *ctx)
 {
-   if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
+   if (!ctx->crtc->i80_mode && !(ctx->out_type & I80_HW_TRG))
return;
 
if (!(ctx->out_type & I80_HW_TRG)) {
@@ -209,7 +208,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
val = VIDOUT_LCD_ON;
if (interlaced)
val |= VIDOUT_INTERLACE_EN_F;
-   if (ctx->out_type & IFTYPE_I80) {
+   if (crtc->i80_mode) {
val |= VIDOUT_COMMAND_IF;
} else {
val |= VIDOUT_RGB_IF;
@@ -225,7 +224,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);
 
-   if (!(ctx->out_type & IFTYPE_I80)) {
+   if (!crtc->i80_mode) {
int vbp = m->crtc_vtotal - m->crtc_vsync_end;
int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
 
@@ -513,6 +512,22 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
clk_disable_unprepare(ctx->clks[i]);
 }
 
+static enum drm_mode_status decon_mode_valid(struct exynos_drm_crtc *crtc,
+   const struct drm_display_mode *mode)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   ctx->irq = crtc->i80_mode ? ctx->irq_lcd_sys : ctx->irq_vsync;
+
+   if (ctx->irq)
+   return MODE_OK;
+
+   dev_info(ctx->dev, "Sink requires %s mode, but appropriate interrupt is 
not provided.\n",
+   crtc->i80_mode ? "command" : "video");
+
+   return MODE_BAD;
+}
+
 static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable= decon_disable,
@@ -522,6 +537,7 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.atomic_begin   = decon_atomic_begin,
.update_plane   = decon_update_plane,
.disable_plane  = decon_disable_plane,
+   .mode_valid = decon_mode_valid,
.atomic_flush   = decon_atomic_flush,
 };
 
@@ -715,11 +731,8 @@ static int exynos5433_decon_probe(struct platform_device 
*pdev)
ctx->out_type = (unsigned long)of_device_get_match_data(dev);
spin_lock_init(>vblank_lock);
 
-   if (ctx->out_type & IFTYPE_HDMI) {
+   if (ctx->out_type & IFTYPE_HDMI)
ctx->first_win = 1;
-   } else if (of_get_child_by_name(dev->of_node, "i80-if-timings")) {
-   ctx->out_type |= IFTYPE_I80;
-   }
 
for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
struct clk *clk;
@@ -753,9 +766,6 @@ static int exynos5433_decon_probe(struct platform_device 
*pdev)
return ret;
ctx->irq_lcd_sys = ret;
 
-   ctx->irq = (ctx->out_type & IFTYPE_I80) ? ctx->irq_lcd_sys
-   : ctx->irq_vsync;
-
ret = decon_conf_irq(ctx, "te", decon_te_irq_handler,
IRQF_TRIGGER_RISING);
if (ret < 0)
-- 
2.7.4

[PATCH v2 07/10] drm/exynos: add mode_valid callback to exynos_drm

[Andrzej Hajda]

crtc::mode_valid callback is required to implement proper pipeline
validation for command/video modes. Since Exynos uses private
framework such callback should be added to it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index ac544de..6ce0821 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -84,7 +84,19 @@ static void exynos_crtc_atomic_flush(struct drm_crtc *crtc,
exynos_crtc->ops->atomic_flush(exynos_crtc);
 }
 
+static enum drm_mode_status exynos_crtc_mode_valid(struct drm_crtc *crtc,
+   const struct drm_display_mode *mode)
+{
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+
+   if (exynos_crtc->ops->mode_valid)
+   return exynos_crtc->ops->mode_valid(exynos_crtc, mode);
+
+   return MODE_OK;
+}
+
 static const struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
+   .mode_valid = exynos_crtc_mode_valid,
.atomic_check   = exynos_crtc_atomic_check,
.atomic_begin   = exynos_crtc_atomic_begin,
.atomic_flush   = exynos_crtc_atomic_flush,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 9e77809..d53435b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -117,6 +117,7 @@ struct exynos_drm_plane_config {
  * @disable: disable the device
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
+ * @mode_valid: specific driver callback for mode validation
  * @atomic_check: validate state
  * @atomic_begin: prepare device to receive an update
  * @atomic_flush: mark the end of device update
@@ -132,6 +133,8 @@ struct exynos_drm_crtc_ops {
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
u32 (*get_vblank_counter)(struct exynos_drm_crtc *crtc);
+   enum drm_mode_status (*mode_valid)(struct exynos_drm_crtc *crtc,
+   const struct drm_display_mode *mode);
int (*atomic_check)(struct exynos_drm_crtc *crtc,
struct drm_crtc_state *state);
void (*atomic_begin)(struct exynos_drm_crtc *crtc);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 09/10] dt-bindings: exynos5433-decon: remove i80-if-timings property

[Andrzej Hajda]

Since i80/command mode is determined in runtime by propagating info
from panel this property can be removed.

Signed-off-by: Andrzej Hajda 
---
 .../devicetree/bindings/display/exynos/exynos5433-decon.txt  | 12 
 1 file changed, 12 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt
index 549c538..fc25882 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt
@@ -25,12 +25,6 @@ Required properties:
 size-cells must 1 and 0, respectively.
 - port: contains an endpoint node which is connected to the endpoint in the mic
node. The reg value muset be 0.
-- i80-if-timings: specify whether the panel which is connected to decon uses
- i80 lcd interface or mipi video interface. This node contains
- no timing information as that of fimd does. Because there is
- no register in decon to specify i80 interface timing value,
- it is not needed, but make it remain to use same kind of node
- in fimd and exynos7 decon.
 
 Example:
 SoC specific DT entry:
@@ -59,9 +53,3 @@ decon: decon@1380 {
};
};
 };
-
-Board specific DT entry:
- {
-   i80-if-timings {
-   };
-};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 03/10] drm/exynos/dsi: refactor panel detection logic

[Andrzej Hajda]

Description of drm_helper_hpd_irq_event clearly states that drivers
supporting hotplug events per connector should use different helper -
drm_kms_helper_hotplug_event. To achieve it following changes have
been performed:
- moved down all DSI ops - they require exynos_dsi_disable function
to be defined earlier,
- simplified exynos_dsi_detect - there is no real detection, it just
returns if panel is attached,
- DSI attach/detach callbacks attaches/detaches DRM panel and sets
connector status and other context fields accordingly, all this is
performed under mutex, as these callbacks are asynchronous.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 203 
 1 file changed, 102 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 6b46df6..063bac3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,7 +254,6 @@ struct exynos_dsi {
struct drm_encoder encoder;
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
-   struct device_node *panel_node;
struct drm_panel *panel;
struct device *dev;
 
@@ -1329,12 +1328,13 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
return 0;
 }
 
-static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
+static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
+ struct device *panel)
 {
int ret;
int te_gpio_irq;
 
-   dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
+   dsi->te_gpio = of_get_named_gpio(panel->of_node, "te-gpios", 0);
if (dsi->te_gpio == -ENOENT)
return 0;
 
@@ -1374,85 +1374,6 @@ static void exynos_dsi_unregister_te_irq(struct 
exynos_dsi *dsi)
}
 }
 
-static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
- struct mipi_dsi_device *device)
-{
-   struct exynos_dsi *dsi = host_to_dsi(host);
-
-   dsi->lanes = device->lanes;
-   dsi->format = device->format;
-   dsi->mode_flags = device->mode_flags;
-   dsi->panel_node = device->dev.of_node;
-
-   /*
-* This is a temporary solution and should be made by more generic way.
-*
-* If attached panel device is for command mode one, dsi should register
-* TE interrupt handler.
-*/
-   if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO)) {
-   int ret = exynos_dsi_register_te_irq(dsi);
-
-   if (ret)
-   return ret;
-   }
-
-   if (dsi->connector.dev)
-   drm_helper_hpd_irq_event(dsi->connector.dev);
-
-   return 0;
-}
-
-static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
- struct mipi_dsi_device *device)
-{
-   struct exynos_dsi *dsi = host_to_dsi(host);
-
-   exynos_dsi_unregister_te_irq(dsi);
-
-   dsi->panel_node = NULL;
-
-   if (dsi->connector.dev)
-   drm_helper_hpd_irq_event(dsi->connector.dev);
-
-   return 0;
-}
-
-static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
-   const struct mipi_dsi_msg *msg)
-{
-   struct exynos_dsi *dsi = host_to_dsi(host);
-   struct exynos_dsi_transfer xfer;
-   int ret;
-
-   if (!(dsi->state & DSIM_STATE_ENABLED))
-   return -EINVAL;
-
-   if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
-   ret = exynos_dsi_init(dsi);
-   if (ret)
-   return ret;
-   dsi->state |= DSIM_STATE_INITIALIZED;
-   }
-
-   ret = mipi_dsi_create_packet(, msg);
-   if (ret < 0)
-   return ret;
-
-   xfer.rx_len = msg->rx_len;
-   xfer.rx_payload = msg->rx_buf;
-   xfer.flags = msg->flags;
-
-   ret = exynos_dsi_transfer(dsi, );
-   return (ret < 0) ? ret : xfer.rx_done;
-}
-
-static const struct mipi_dsi_host_ops exynos_dsi_ops = {
-   .attach = exynos_dsi_host_attach,
-   .detach = exynos_dsi_host_detach,
-   .transfer = exynos_dsi_host_transfer,
-};
-
 static void exynos_dsi_enable(struct drm_encoder *encoder)
 {
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
@@ -1508,25 +1429,7 @@ static void exynos_dsi_disable(struct drm_encoder 
*encoder)
 static enum drm_connector_status
 exynos_dsi_detect(struct drm_connector *connector, bool force)
 {
-   struct exynos_dsi *dsi = connector_to_dsi(connector);
-
-   if (!dsi->panel) {
-   dsi->panel = of_drm_find_panel(dsi->panel_node);
-   if (dsi->panel)
-   drm_panel_attach(dsi->panel, >connector);
-   } else if (!dsi->panel_node) {
-   struct drm_encoder *encoder;
-
-   encoder = platform_get_drvdata(to_platform_device(dsi->dev));
-   

[PATCH v2 06/10] drm/exynos/decon5433: refactor irq requesting code

[Andrzej Hajda]

To allow runtime validation of mode of work irq request
code should be split into two separate phases:
- irq reqesting,
- irq checking.
Following patches will move 2nd phase to mode validation phase.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 54 +++
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 237b4c9..0f5acce 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -58,6 +58,8 @@ struct decon_context {
struct regmap   *sysreg;
struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
unsigned intirq;
+   unsigned intirq_vsync;
+   unsigned intirq_lcd_sys;
unsigned intte_irq;
unsigned long   out_type;
int first_win;
@@ -670,19 +672,22 @@ static const struct of_device_id 
exynos5433_decon_driver_dt_match[] = {
 MODULE_DEVICE_TABLE(of, exynos5433_decon_driver_dt_match);
 
 static int decon_conf_irq(struct decon_context *ctx, const char *name,
-   irq_handler_t handler, unsigned long int flags, bool required)
+   irq_handler_t handler, unsigned long int flags)
 {
struct platform_device *pdev = to_platform_device(ctx->dev);
int ret, irq = platform_get_irq_byname(pdev, name);
 
if (irq < 0) {
-   if (irq == -EPROBE_DEFER)
+   switch (irq) {
+   case -EPROBE_DEFER:
return irq;
-   if (required)
-   dev_err(ctx->dev, "cannot get %s IRQ\n", name);
-   else
-   irq = 0;
-   return irq;
+   case -ENODATA:
+   case -ENXIO:
+   return 0;
+   default:
+   dev_err(ctx->dev, "IRQ %s get failed, %d\n", name, irq);
+   return irq;
+   }
}
irq_set_status_flags(irq, IRQ_NOAUTOEN);
ret = devm_request_irq(ctx->dev, irq, handler, flags, "drm_decon", ctx);
@@ -738,25 +743,26 @@ static int exynos5433_decon_probe(struct platform_device 
*pdev)
return PTR_ERR(ctx->addr);
}
 
-   if (ctx->out_type & IFTYPE_I80) {
-   ret = decon_conf_irq(ctx, "lcd_sys", decon_irq_handler, 0, 
true);
-   if (ret < 0)
-   return ret;
-   ctx->irq = ret;
+   ret = decon_conf_irq(ctx, "vsync", decon_irq_handler, 0);
+   if (ret < 0)
+   return ret;
+   ctx->irq_vsync = ret;
 
-   ret = decon_conf_irq(ctx, "te", decon_te_irq_handler,
-IRQF_TRIGGER_RISING, false);
-   if (ret < 0)
-   return ret;
-   if (ret) {
-   ctx->te_irq = ret;
-   ctx->out_type &= ~I80_HW_TRG;
-   }
-   } else {
-   ret = decon_conf_irq(ctx, "vsync", decon_irq_handler, 0, true);
-   if (ret < 0)
+   ret = decon_conf_irq(ctx, "lcd_sys", decon_irq_handler, 0);
+   if (ret < 0)
+   return ret;
+   ctx->irq_lcd_sys = ret;
+
+   ctx->irq = (ctx->out_type & IFTYPE_I80) ? ctx->irq_lcd_sys
+   : ctx->irq_vsync;
+
+   ret = decon_conf_irq(ctx, "te", decon_te_irq_handler,
+   IRQF_TRIGGER_RISING);
+   if (ret < 0)
return ret;
-   ctx->irq = ret;
+   if (ret) {
+   ctx->te_irq = ret;
+   ctx->out_type &= ~I80_HW_TRG;
}
 
if (ctx->out_type & I80_HW_TRG) {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 05/10] drm/exynos/mic: use mode info stored in CRTC to detect i80 mode

[Andrzej Hajda]

MIC driver should use info from CRTC to check mode of work instead of
illegally peeking into nodes of other devices.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 44 +++--
 1 file changed, 4 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 16bbee8..128ce176 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -21,9 +21,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+#include 
+
 /* Sysreg registers for MIC */
 #define DSD_CFG_MUX0x1004
 #define MIC0_RGB_MUX   (1 << 0)
@@ -85,12 +88,6 @@
 
 #define MIC_BS_SIZE_2D(x)  ((x) & 0x3fff)
 
-enum {
-   ENDPOINT_DECON_NODE,
-   ENDPOINT_DSI_NODE,
-   NUM_ENDPOINTS
-};
-
 static char *clk_names[] = { "pclk_mic0", "sclk_rgb_vclk_to_mic0" };
 #define NUM_CLKS   ARRAY_SIZE(clk_names)
 static DEFINE_MUTEX(mic_mutex);
@@ -229,36 +226,6 @@ static void mic_set_reg_on(struct exynos_mic *mic, bool 
enable)
writel(reg, mic->reg + MIC_OP);
 }
 
-static int parse_dt(struct exynos_mic *mic)
-{
-   int ret = 0, i, j;
-   struct device_node *remote_node;
-   struct device_node *nodes[3];
-
-   /*
-* The order of endpoints does matter.
-* The first node must be for decon and the second one must be for dsi.
-*/
-   for (i = 0, j = 0; i < NUM_ENDPOINTS; i++) {
-   remote_node = of_graph_get_remote_node(mic->dev->of_node, i, 0);
-   if (!remote_node) {
-   ret = -EPIPE;
-   goto exit;
-   }
-   nodes[j++] = remote_node;
-
-   if (i == ENDPOINT_DECON_NODE &&
-   of_get_child_by_name(remote_node, "i80-if-timings"))
-   mic->i80_mode = 1;
-   }
-
-exit:
-   while (--j > -1)
-   of_node_put(nodes[j]);
-
-   return ret;
-}
-
 static void mic_disable(struct drm_bridge *bridge) { }
 
 static void mic_post_disable(struct drm_bridge *bridge)
@@ -286,6 +253,7 @@ static void mic_mode_set(struct drm_bridge *bridge,
 
mutex_lock(_mutex);
drm_display_mode_to_videomode(mode, >vm);
+   mic->i80_mode = to_exynos_crtc(bridge->encoder->crtc)->i80_mode;
mutex_unlock(_mutex);
 }
 
@@ -417,10 +385,6 @@ static int exynos_mic_probe(struct platform_device *pdev)
 
mic->dev = dev;
 
-   ret = parse_dt(mic);
-   if (ret)
-   goto err;
-
ret = of_address_to_resource(dev->of_node, 0, );
if (ret) {
DRM_ERROR("mic: Failed to get mem region for MIC\n");
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 02/10] drm/exynos: use helper to set possible crtcs

[Andrzej Hajda]

All encoders share the same code to set encoders possible_crtcs field.
The patch creates helper to abstract out this code.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_dp.c   | 15 +--
 drivers/gpu/drm/exynos/exynos_drm_core.c |  1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 21 ++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.h | 10 +++---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  | 12 
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  | 13 -
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 15 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c | 25 +
 8 files changed, 53 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index 385537b..39629e7 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -155,7 +155,7 @@ static int exynos_dp_bind(struct device *dev, struct device 
*master, void *data)
struct exynos_dp_device *dp = dev_get_drvdata(dev);
struct drm_encoder *encoder = >encoder;
struct drm_device *drm_dev = data;
-   int pipe, ret;
+   int ret;
 
/*
 * Just like the probe function said, we don't need the
@@ -179,20 +179,15 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
return ret;
}
 
-   pipe = exynos_drm_crtc_get_pipe_from_type(drm_dev,
- EXYNOS_DISPLAY_TYPE_LCD);
-   if (pipe < 0)
-   return pipe;
-
-   encoder->possible_crtcs = 1 << pipe;
-
-   DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
-
drm_encoder_init(drm_dev, encoder, _dp_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
 
drm_encoder_helper_add(encoder, _dp_encoder_helper_funcs);
 
+   ret = exynos_drm_set_possible_crtcs(encoder, EXYNOS_DISPLAY_TYPE_LCD);
+   if (ret < 0)
+   return ret;
+
dp->plat_data.encoder = encoder;
 
return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index edbd98f..b0c0621 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+
 #include "exynos_drm_drv.h"
 #include "exynos_drm_crtc.h"
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index c37078f..ac544de 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"
@@ -191,16 +192,30 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
drm_device *drm_dev,
return ERR_PTR(ret);
 }
 
-int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
+struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device *drm_dev,
   enum exynos_drm_output_type out_type)
 {
struct drm_crtc *crtc;
 
drm_for_each_crtc(crtc, drm_dev)
if (to_exynos_crtc(crtc)->type == out_type)
-   return drm_crtc_index(crtc);
+   return to_exynos_crtc(crtc);
 
-   return -EPERM;
+   return ERR_PTR(-EPERM);
+}
+
+int exynos_drm_set_possible_crtcs(struct drm_encoder *encoder,
+   enum exynos_drm_output_type out_type)
+{
+   struct exynos_drm_crtc *crtc = exynos_drm_crtc_get_by_type(encoder->dev,
+   out_type);
+
+   if (IS_ERR(crtc))
+   return PTR_ERR(crtc);
+
+   encoder->possible_crtcs = drm_crtc_mask(>base);
+
+   return 0;
 }
 
 void exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index ef58b64..dec4461 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -15,21 +15,25 @@
 #ifndef _EXYNOS_DRM_CRTC_H_
 #define _EXYNOS_DRM_CRTC_H_
 
+
 #include "exynos_drm_drv.h"
 
 struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
struct drm_plane *plane,
-   enum exynos_drm_output_type type,
+   enum exynos_drm_output_type out_type,
const struct exynos_drm_crtc_ops *ops,
void *context);
 void exynos_drm_crtc_wait_pending_update(struct exynos_drm_crtc *exynos_crtc);
 void exynos_drm_crtc_finish_update(struct exynos_drm_crtc *exynos_crtc,
   struct exynos_drm_plane *exynos_plane);
 
-/* This function gets 

[PATCH v2 00/10] drm/exynos: panel mode info propagation

[Andrzej Hajda]

Hi Inki,

This patchset beside cleanup/refactoring patches (01-03) adds code to propagate
info provided by MIPI-DSI panels about its mode of work (video/command mode).
The propagation is performed for whole pipeline as every its elements uses it.

Changes in v2:
- added mode_valid callback to exynos_drm,
- replace atomic_check with mode_valid for mode validation,
- split mode propagation patch in decon5433 into smaller parts,
- removed te_irq variable rename,
- added patch removing i80 timing node from dts,
- adjusted commit messages.

Regards
Andrzej


Andrzej Hajda (10):
  drm/exynos/decon5433: use readl_poll_timeout helpers
  drm/exynos: use helper to set possible crtcs
  drm/exynos/dsi: refactor panel detection logic
  drm/exynos/dsi: propagate info about command mode from panel
  drm/exynos/mic: use mode info stored in CRTC to detect i80 mode
  drm/exynos/decon5433: refactor irq requesting code
  drm/exynos: add mode_valid callback to exynos_drm
  drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode
  dt-bindings: exynos5433-decon: remove i80-if-timings property
  arm64: dts: exynos: remove i80-if-timings nodes

 .../bindings/display/exynos/exynos5433-decon.txt   |  12 --
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi |   6 -
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 108 +-
 drivers/gpu/drm/exynos/exynos_dp.c |  15 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |  33 +++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |  10 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c|  12 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   4 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 218 ++---
 drivers/gpu/drm/exynos/exynos_drm_mic.c|  44 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  15 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  25 +--
 13 files changed, 237 insertions(+), 266 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 01/10] drm/exynos/decon5433: use readl_poll_timeout helpers

[Andrzej Hajda]

Linux core provide helpers for polling with timeout, lets use them.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5792ca88..237b4c9 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -407,24 +408,19 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
*crtc)
 
 static void decon_swreset(struct decon_context *ctx)
 {
-   unsigned int tries;
unsigned long flags;
+   u32 val;
+   int ret;
 
writel(0, ctx->addr + DECON_VIDCON0);
-   for (tries = 2000; tries; --tries) {
-   if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_STOP_STATUS)
-   break;
-   udelay(10);
-   }
+   readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
+  ~val & VIDCON0_STOP_STATUS, 12, 2);
 
writel(VIDCON0_SWRESET, ctx->addr + DECON_VIDCON0);
-   for (tries = 2000; tries; --tries) {
-   if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_SWRESET)
-   break;
-   udelay(10);
-   }
+   ret = readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
+~val & VIDCON0_SWRESET, 12, 2);
 
-   WARN(tries == 0, "failed to software reset DECON\n");
+   WARN(ret < 0, "failed to software reset DECON\n");
 
spin_lock_irqsave(>vblank_lock, flags);
ctx->frame_id = 0;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 04/10] drm/exynos/dsi: propagate info about command mode from panel

[Andrzej Hajda]

mipi_dsi framework provides information about panel's mode of work.
This info should be propagated upstream to configure all elements of
the pipeline. As CRTC is the common denominator of the pipeline we can
put such info into its structures.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a93de32..9e77809 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -162,6 +162,7 @@ struct exynos_drm_crtc {
const struct exynos_drm_crtc_ops*ops;
void*ctx;
struct exynos_drm_clk   *pipe_clk;
+   booli80_mode : 1;
 };
 
 static inline void exynos_drm_pipe_clk_enable(struct exynos_drm_crtc *crtc,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 063bac3..8c06a62 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1543,6 +1543,8 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host 
*host,
drm_panel_attach(dsi->panel, >connector);
dsi->connector.status = connector_status_connected;
}
+   exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
+   !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
 
mutex_unlock(>mode_config.mutex);
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102387] Assertion failure with UE4Editor and sb enabled

[bugzilla-daemon]

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

Gert Wollny  changed:

   What|Removed |Added

 Attachment #133745|TGSI and byte code of the   |TGSI and byte code of the
description|buggy shader|offending  shader

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102387] Assertion failure with UE4Editor and sb enabled

[bugzilla-daemon]

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

Bug ID: 102387
   Summary: Assertion failure with UE4Editor and sb enabled
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: gw.foss...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 133745
  --> https://bugs.freedesktop.org/attachment.cgi?id=133745=edit
TGSI and byte code of the buggy shader

When running UE4Editor (4.17) on BARTS with -opengl3 and mesa (1e696b9) is
compiled in debug mode I get the following assertion failure on one shader
(attached), that then leads to UE4Editor shutting down: 

  error at : MUL_IEEE R17.x.5F@R124.x,R14.x.5F@R124.x, R90.x.22||F@R2.w
   : expected operand value R90.x.22||F@R2.w, gpr contains t39||FP@R2.w
  sb/sb_ra_checker.cpp:46:run: Assertion `sh.errors.empty()' failed.

Sometimes it happens right away, when loading the assets, sometimes I have to
load a specific level. I guess it depends on what assets are actually
displayed.  

If I disable the assertion then I can use UE4Editor (I still need to add a
patch to work around to a problem introduced by another shader that for some
bug in UE4 exceeds the limits of the GPRs, but this has nothing to do which
this assertion failure).

Best, 
Gert

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] omapdrm fixes for v4.14

[Tomi Valkeinen]

Hi Dave,

Please pull omapdrm fixes for 4.14. One is for a compilation issue
introduced in my previous omapdrm-4.14 pull request. The rest I have
been playing around a while, and are not proper fixes but workarounds.
I'm not happy about those but I don't have better fixes.

 Tomi

The following changes since commit 2419672f4c96ca678a95d0f733f44d3ee036b5c8:

  drm/omap: Potential NULL deref in omap_crtc_duplicate_state() (2017-08-16 
16:21:18 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
tags/omapdrm-4.14-fixes

for you to fetch changes up to d1bbc823781f9b325fb25b4af83cf1afd314e6d5:

  ARM: OMAP2+: fix missing variable declaration (2017-08-24 15:17:25 +0300)


omapdrm fixes for 4.14

* fix compilation when compiling omapfb driver
* WA for OMAP3 endless sync lost issue
* WA for OMAP5 DSI PLL issue
* fix analog TV out modecheck


Arnd Bergmann (1):
  ARM: OMAP2+: fix missing variable declaration

Tomi Valkeinen (3):
  drm/omap: fix analog tv-out modecheck
  drm/omap: fix i886 work-around
  drm/omap: work-around for omap3 display enable

 arch/arm/mach-omap2/display.c   |  1 +
 drivers/gpu/drm/omapdrm/dss/dss.h   |  3 ++
 drivers/gpu/drm/omapdrm/dss/pll.c   | 29 ++-
 drivers/gpu/drm/omapdrm/dss/venc.c  | 65 ++---
 drivers/gpu/drm/omapdrm/dss/video-pll.c |  2 +
 drivers/gpu/drm/omapdrm/omap_drv.c  | 47 +++-
 6 files changed, 107 insertions(+), 40 deletions(-)

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM Format Modifiers in v4l2

[Brian Starkey]

On Thu, Aug 24, 2017 at 01:37:35PM +0200, Hans Verkuil wrote:

On 08/24/17 13:14, Brian Starkey wrote:

Hi Hans,

On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:

On 08/21/2017 06:01 PM, Daniel Vetter wrote:

On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey  wrote:

Hi all,

I couldn't find this topic talked about elsewhere, but apologies if
it's a duplicate - I'll be glad to be steered in the direction of a
thread.

We'd like to support DRM format modifiers in v4l2 in order to share
the description of different (mostly proprietary) buffer formats
between e.g. a v4l2 device and a DRM device.

DRM format modifiers are defined in include/uapi/drm/drm_fourcc.h and
are a vendor-namespaced 64-bit value used to describe various
vendor-specific buffer layouts. They are combined with a (DRM) FourCC
code to give a complete description of the data contained in a buffer.

The same modifier definition is used in the Khronos EGL extension
EGL_EXT_image_dma_buf_import_modifiers, and is supported in the
Wayland linux-dmabuf protocol.


This buffer information could of course be described in the
vendor-specific part of V4L2_PIX_FMT_*, but this would duplicate the
information already defined in drm_fourcc.h. Additionally, there
would be quite a format explosion where a device supports a dozen or
more formats, all of which can use one or more different
layouts/compression schemes.

So, I'm wondering if anyone has views on how/whether this could be
incorporated?

I spoke briefly about this to Laurent at LPC last year, and he
suggested v4l2_control as one approach.

I also wondered if could be added in v4l2_pix_format_mplane - looks
like there's 8 bytes left before it exceeds the 200 bytes, or could go
in the reserved portion of v4l2_plane_pix_format.

Thanks for any thoughts,


One problem is that the modifers sometimes reference the DRM fourcc
codes. v4l has a different (and incompatible set) of fourcc codes,
whereas all the protocols and specs (you can add DRI3.1 for Xorg to
that list btw) use both drm fourcc and drm modifiers.

This might or might not make this proposal unworkable, but it's
something I'd at least review carefully.

Otherwise I think it'd be great if we could have one namespace for all
modifiers, that's pretty much why we have them. Please also note that
for drm_fourcc.h we don't require an in-kernel user for a new modifier
since a bunch of them might need to be allocated just for
userspace-to-userspace buffer sharing (e.g. in EGL/vk). One example
for this would be compressed surfaces with fast-clearing, which is
planned for i915 (but current hw can't scan it out). And we really
want to have one namespace for everything.


Who sets these modifiers? Kernel or userspace? Or can it be set by both?
I assume any userspace code that sets/reads this is code specific for that
hardware?


I think normally the modifier would be set by userspace. However it
might not necessarily be device-specific code. In DRM the intention is
for userspace to query the set of modifiers which are supported, and
then use them without necessarily knowing exactly what they mean
(insofar as that is possible).

e.g. if I have two devices which support MODIFIER_FOO, I could attempt
to share a buffer between them which uses MODIFIER_FOO without
necessarily knowing exactly what it is/does.



I think Laurent's suggestion of using a 64 bit V4L2 control for this makes
the most sense.

Especially if you can assume that whoever sets this knows the hardware.

I think this only makes sense if you pass buffers from one HW device to another.

Because you cannot expect generic video capture code to be able to interpret
all the zillion different combinations of modifiers.


I don't quite follow this last bit. The control could report the set
of supported modifiers.


What I mean was: an application can use the modifier to give buffers from
one device to another without needing to understand it.

But a generic video capture application that processes the video itself
cannot be expected to know about the modifiers. It's a custom HW specific
format that you only use between two HW devices or with software written
for that hardware.



Yes, makes sense.



However, in DRM the API lets you get the supported formats for each
modifier as-well-as the modifier list itself. I'm not sure how exactly
to provide that in a control.


We have support for a 'menu' of 64 bit integers: V4L2_CTRL_TYPE_INTEGER_MENU.
You use VIDIOC_QUERYMENU to enumerate the available modifiers.

So enumerating these modifiers would work out-of-the-box.


Right. So I guess the supported set of formats could be somehow
enumerated in the menu item string. In DRM the pairs are (modifier +
bitmask) where bits represent formats in the supported formats list
(commit db1689aa61bd in drm-next). Printing a hex representation of
the bitmask would be functional but I concede not very pretty.

Cheers,
-Brian



Regards,

Hans

Re: [PATCH 2/2] drm/ttm: Remove needless 'extern' on functions in header.

[Tom St Denis]

On 24/08/17 07:53 AM, Christian König wrote:

Am 24.08.2017 um 12:48 schrieb Tom St Denis:

Minor tidy up.

Signed-off-by: Tom St Denis 


Thanks and sorry that I thought you added this, I really need more sleep.

Patch is Reviewed-by: Christian König .


No worries.  For a second there I thought I was writing patches too 
early for me :)


Should be an AMD rule that no patches before sun up in the summer... 
Alas in Winter here in Canada that'd cut productivity down to 20% hehehe.


Cheers,
Tom
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ttm: Remove needless 'extern' on functions in header.

[Christian König]

Am 24.08.2017 um 12:48 schrieb Tom St Denis:

Minor tidy up.

Signed-off-by: Tom St Denis 


Thanks and sorry that I thought you added this, I really need more sleep.

Patch is Reviewed-by: Christian König .

Christian.


---
  include/drm/ttm/ttm_page_alloc.h | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 4400c08169cd..19bdd907613c 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -47,7 +47,7 @@ void ttm_page_alloc_fini(void);
   *
   * Add backing pages to all of @ttm
   */
-extern int ttm_pool_populate(struct ttm_tt *ttm);
+int ttm_pool_populate(struct ttm_tt *ttm);
  
  /**

   * ttm_pool_unpopulate:
@@ -56,12 +56,12 @@ extern int ttm_pool_populate(struct ttm_tt *ttm);
   *
   * Free all pages of @ttm
   */
-extern void ttm_pool_unpopulate(struct ttm_tt *ttm);
+void ttm_pool_unpopulate(struct ttm_tt *ttm);
  
  /**

   * Output the state of pools to debugfs file
   */
-extern int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
+int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
  
  
  #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)

@@ -78,10 +78,10 @@ void ttm_dma_page_alloc_fini(void);
  /**
   * Output the state of pools to debugfs file
   */
-extern int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data);
+int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data);
  
-extern int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);

-extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
+int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
+void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
  
  
  /**



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/ttm: Add dummy *populate_and_*map_pages() functions

[Christian König]

Am 24.08.2017 um 12:48 schrieb Tom St Denis:

On non IOTLB/IOMMU builds these functions would be undefined.

Signed-off-by: Tom St Denis 
---
  include/drm/ttm/ttm_page_alloc.h | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 8695918ea629..4400c08169cd 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -116,6 +116,16 @@ static inline void ttm_dma_unpopulate(struct ttm_dma_tt 
*ttm_dma,
  struct device *dev)
  {
  }
+
+static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
+{
+   return 0;


We should probably return -ENOMEM here, just like the dummy 
ttm_dma_populate() does.


With that fixed the patch is Reviewed-by: Christian König 
.


Regards,
Christian.


+}
+
+static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct 
ttm_dma_tt *tt)
+{
+}
+
  #endif
  
  #endif



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[ANNOUNCE] libdrm 2.4.83

[Daniel Stone]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Boyuan Zhang (1):
  tests/amdgpu: add uvd encode unit tests

Chih-Wei Huang (2):
  android: add rules to build amdgpu.ids
  android: amdgpu: fix build break

Daniel Stone (1):
  configure.ac: Bump version to 2.4.83

Emil Velikov (1):
  xf86drm: continue with next device if drmProcessUsbDevice fails

Eric Engestrom (4):
  radeon: add fallthrough annotation
  freedreno: remove dead error path
  freedreno/msm: remove dead error path
  freedreno: prevent deadlock in error path

Flora Cui (1):
  test/amdgpu: fix test failure for SI

Gurchetan Singh (1):
  xf86drm: continue after drmProcessPlatformDevice failure

Hawking Zhang (2):
  tests/amdgpu: bypass UVD CS tests on raven
  tests/amdgpu: bypass VCE tests on raven

Jan Vesely (2):
  amdgpu: Add FX-9800P Bristol Ridge iGPU id
  drmsltest: Check expected neighbours

Jason Ekstrand (1):
  drm: Pull new modifier uapi into drm_fourcc and drm_mode

Monk Liu (3):
  amdgpu: fix missing mutex unlock before return
  amdgpu: fix race issue between two bo functions(v2)
  amdgpu: merge and cleanup amdgpu_bo_free

Philipp Zabel (1):
  etnaviv: fix etna_bo_from_name

git tag: libdrm-2.4.83

https://dri.freedesktop.org/libdrm/libdrm-2.4.83.tar.bz2
MD5:  23800953ed7564988872e1e8c61fde31  libdrm-2.4.83.tar.bz2
SHA1: f78d392684d6e482e8c0a85d355619ac64c4ad6a  libdrm-2.4.83.tar.bz2
SHA256: 03a52669da60ead62548a35bc430aafb6c2d8dd21ec9dba3a90f96eff5fe36d6  
libdrm-2.4.83.tar.bz2
SHA512: 
8f894ff61939bca03ac857506a84bbbcbe2367e60c91a0f2388bfce5ae81e12ba2f96fe1c962416cf9e2d25ef04b98b5437c7015497789561311a72607b3bfcb
  libdrm-2.4.83.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.83.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.83.tar.gz
MD5:  d6debc2bde08a0bfff61fe848d760f6d  libdrm-2.4.83.tar.gz
SHA1: b80228d235805e46f0d8e62ab1f7231ebd2fd67e  libdrm-2.4.83.tar.gz
SHA256: 2ff5f626a14ec5bd680f7769cac9a8eb1e40c36cf5ca554d2c4e5d91bab3d81d  
libdrm-2.4.83.tar.gz
SHA512: 
0ca90a30808cafdf7178b482e5121968bcaac9a48b4f4f969a88c3584043a24b9734ea2b747b46fc72053df15fc1f81e658176ad637a72a0c935450753ab6a7a
  libdrm-2.4.83.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.83.tar.gz.sig

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJZnr1BAAoJEMzE8H+sZB7/U0kP/2YTIzOlwOW0mZZ1H0KbBST3
gvg5ywaJDHnUp0jHO+qM589La2hDaLRSUvRvwtjU8phqNcJkl5RJxyy6PhCGQ0OY
auJv5j82gQArrTyIsMeEZEhXjq9SmB5ntQk/HmV60Ct3xH6y88pDYjvPqZ31Q0CM
kvRKtmV80KTp1uDVo8x+FifdeZtL7+SBllgYgTk46YCZj1NtFe4w0FsPn1OQjMMy
52JIVxBOvR2Jk5Y8AlOdWTRTdJbku080eaumGuHKvo7ESy98GJmBHdvpRZVDWyle
9FVxz10TXPUmUMxubysv3o4oiOfZOlkvo/wRPozcQ1+ph3grF7c+GNgXF8bq9Qd2
meTWJMBEq/sQ+jvEZlJt/9cDpJhg/tC0O5X65PErzECEoY5DJkdsRQ2moPWjS4C/
miMGrK9ufqZdcXG0OxKW5wyIdus6gYV3RJXlwveoKkjUOvdqxcepJiPWlxL4sDJJ
gDfs0qs2Pi1V/XNCFMeyBqNxFTt9c5zJbLkz83e6cDG8CeKecDaK9Dy/v0COmKfe
K/r8OoPVr+xY0dFY63Jua3Xa146vL57+T/xNjEJgtndCODvR4MOfkzN7u40wuG8q
U+9wIQAyoVkg2HTcszt4Ynz/TEFWvotHo0gC/srQuOaek6xS9zJGYhv87kqNRVzk
uTjAC5zDXjHp6ZNtRmII
=W/DQ
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM Format Modifiers in v4l2

[Hans Verkuil]

On 08/24/17 13:14, Brian Starkey wrote:
> Hi Hans,
> 
> On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:
>> On 08/21/2017 06:01 PM, Daniel Vetter wrote:
>>> On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey  
>>> wrote:
 Hi all,

 I couldn't find this topic talked about elsewhere, but apologies if
 it's a duplicate - I'll be glad to be steered in the direction of a
 thread.

 We'd like to support DRM format modifiers in v4l2 in order to share
 the description of different (mostly proprietary) buffer formats
 between e.g. a v4l2 device and a DRM device.

 DRM format modifiers are defined in include/uapi/drm/drm_fourcc.h and
 are a vendor-namespaced 64-bit value used to describe various
 vendor-specific buffer layouts. They are combined with a (DRM) FourCC
 code to give a complete description of the data contained in a buffer.

 The same modifier definition is used in the Khronos EGL extension
 EGL_EXT_image_dma_buf_import_modifiers, and is supported in the
 Wayland linux-dmabuf protocol.


 This buffer information could of course be described in the
 vendor-specific part of V4L2_PIX_FMT_*, but this would duplicate the
 information already defined in drm_fourcc.h. Additionally, there
 would be quite a format explosion where a device supports a dozen or
 more formats, all of which can use one or more different
 layouts/compression schemes.

 So, I'm wondering if anyone has views on how/whether this could be
 incorporated?

 I spoke briefly about this to Laurent at LPC last year, and he
 suggested v4l2_control as one approach.

 I also wondered if could be added in v4l2_pix_format_mplane - looks
 like there's 8 bytes left before it exceeds the 200 bytes, or could go
 in the reserved portion of v4l2_plane_pix_format.

 Thanks for any thoughts,
>>>
>>> One problem is that the modifers sometimes reference the DRM fourcc
>>> codes. v4l has a different (and incompatible set) of fourcc codes,
>>> whereas all the protocols and specs (you can add DRI3.1 for Xorg to
>>> that list btw) use both drm fourcc and drm modifiers.
>>>
>>> This might or might not make this proposal unworkable, but it's
>>> something I'd at least review carefully.
>>>
>>> Otherwise I think it'd be great if we could have one namespace for all
>>> modifiers, that's pretty much why we have them. Please also note that
>>> for drm_fourcc.h we don't require an in-kernel user for a new modifier
>>> since a bunch of them might need to be allocated just for
>>> userspace-to-userspace buffer sharing (e.g. in EGL/vk). One example
>>> for this would be compressed surfaces with fast-clearing, which is
>>> planned for i915 (but current hw can't scan it out). And we really
>>> want to have one namespace for everything.
>>
>> Who sets these modifiers? Kernel or userspace? Or can it be set by both?
>> I assume any userspace code that sets/reads this is code specific for that
>> hardware?
> 
> I think normally the modifier would be set by userspace. However it
> might not necessarily be device-specific code. In DRM the intention is
> for userspace to query the set of modifiers which are supported, and
> then use them without necessarily knowing exactly what they mean
> (insofar as that is possible).
> 
> e.g. if I have two devices which support MODIFIER_FOO, I could attempt
> to share a buffer between them which uses MODIFIER_FOO without
> necessarily knowing exactly what it is/does.
> 
>>
>> I think Laurent's suggestion of using a 64 bit V4L2 control for this makes
>> the most sense.
>>
>> Especially if you can assume that whoever sets this knows the hardware.
>>
>> I think this only makes sense if you pass buffers from one HW device to 
>> another.
>>
>> Because you cannot expect generic video capture code to be able to interpret
>> all the zillion different combinations of modifiers.
> 
> I don't quite follow this last bit. The control could report the set
> of supported modifiers.

What I mean was: an application can use the modifier to give buffers from
one device to another without needing to understand it.

But a generic video capture application that processes the video itself
cannot be expected to know about the modifiers. It's a custom HW specific
format that you only use between two HW devices or with software written
for that hardware.

> 
> However, in DRM the API lets you get the supported formats for each
> modifier as-well-as the modifier list itself. I'm not sure how exactly
> to provide that in a control.

We have support for a 'menu' of 64 bit integers: V4L2_CTRL_TYPE_INTEGER_MENU.
You use VIDIOC_QUERYMENU to enumerate the available modifiers.

So enumerating these modifiers would work out-of-the-box.

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH 2/2] drm/ttm: Remove needless 'extern' on functions in header.

[Tom St Denis]

Minor tidy up.

Signed-off-by: Tom St Denis 
---
 include/drm/ttm/ttm_page_alloc.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 4400c08169cd..19bdd907613c 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -47,7 +47,7 @@ void ttm_page_alloc_fini(void);
  *
  * Add backing pages to all of @ttm
  */
-extern int ttm_pool_populate(struct ttm_tt *ttm);
+int ttm_pool_populate(struct ttm_tt *ttm);
 
 /**
  * ttm_pool_unpopulate:
@@ -56,12 +56,12 @@ extern int ttm_pool_populate(struct ttm_tt *ttm);
  *
  * Free all pages of @ttm
  */
-extern void ttm_pool_unpopulate(struct ttm_tt *ttm);
+void ttm_pool_unpopulate(struct ttm_tt *ttm);
 
 /**
  * Output the state of pools to debugfs file
  */
-extern int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
+int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
 
 
 #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
@@ -78,10 +78,10 @@ void ttm_dma_page_alloc_fini(void);
 /**
  * Output the state of pools to debugfs file
  */
-extern int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data);
+int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data);
 
-extern int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
-extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
+int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
+void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
 
 
 /**
-- 
2.12.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/ttm: Add dummy *populate_and_*map_pages() functions

[Tom St Denis]

On non IOTLB/IOMMU builds these functions would be undefined.

Signed-off-by: Tom St Denis 
---
 include/drm/ttm/ttm_page_alloc.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 8695918ea629..4400c08169cd 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -116,6 +116,16 @@ static inline void ttm_dma_unpopulate(struct ttm_dma_tt 
*ttm_dma,
  struct device *dev)
 {
 }
+
+static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
+{
+   return 0;
+}
+
+static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct 
ttm_dma_tt *tt)
+{
+}
+
 #endif
 
 #endif
-- 
2.12.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM Format Modifiers in v4l2

[Brian Starkey]

Hi Hans,

On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:

On 08/21/2017 06:01 PM, Daniel Vetter wrote:

On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey  wrote:

Hi all,

I couldn't find this topic talked about elsewhere, but apologies if
it's a duplicate - I'll be glad to be steered in the direction of a
thread.

We'd like to support DRM format modifiers in v4l2 in order to share
the description of different (mostly proprietary) buffer formats
between e.g. a v4l2 device and a DRM device.

DRM format modifiers are defined in include/uapi/drm/drm_fourcc.h and
are a vendor-namespaced 64-bit value used to describe various
vendor-specific buffer layouts. They are combined with a (DRM) FourCC
code to give a complete description of the data contained in a buffer.

The same modifier definition is used in the Khronos EGL extension
EGL_EXT_image_dma_buf_import_modifiers, and is supported in the
Wayland linux-dmabuf protocol.


This buffer information could of course be described in the
vendor-specific part of V4L2_PIX_FMT_*, but this would duplicate the
information already defined in drm_fourcc.h. Additionally, there
would be quite a format explosion where a device supports a dozen or
more formats, all of which can use one or more different
layouts/compression schemes.

So, I'm wondering if anyone has views on how/whether this could be
incorporated?

I spoke briefly about this to Laurent at LPC last year, and he
suggested v4l2_control as one approach.

I also wondered if could be added in v4l2_pix_format_mplane - looks
like there's 8 bytes left before it exceeds the 200 bytes, or could go
in the reserved portion of v4l2_plane_pix_format.

Thanks for any thoughts,


One problem is that the modifers sometimes reference the DRM fourcc
codes. v4l has a different (and incompatible set) of fourcc codes,
whereas all the protocols and specs (you can add DRI3.1 for Xorg to
that list btw) use both drm fourcc and drm modifiers.

This might or might not make this proposal unworkable, but it's
something I'd at least review carefully.

Otherwise I think it'd be great if we could have one namespace for all
modifiers, that's pretty much why we have them. Please also note that
for drm_fourcc.h we don't require an in-kernel user for a new modifier
since a bunch of them might need to be allocated just for
userspace-to-userspace buffer sharing (e.g. in EGL/vk). One example
for this would be compressed surfaces with fast-clearing, which is
planned for i915 (but current hw can't scan it out). And we really
want to have one namespace for everything.


Who sets these modifiers? Kernel or userspace? Or can it be set by both?
I assume any userspace code that sets/reads this is code specific for that
hardware?


I think normally the modifier would be set by userspace. However it
might not necessarily be device-specific code. In DRM the intention is
for userspace to query the set of modifiers which are supported, and
then use them without necessarily knowing exactly what they mean
(insofar as that is possible).

e.g. if I have two devices which support MODIFIER_FOO, I could attempt
to share a buffer between them which uses MODIFIER_FOO without
necessarily knowing exactly what it is/does.



I think Laurent's suggestion of using a 64 bit V4L2 control for this makes
the most sense.

Especially if you can assume that whoever sets this knows the hardware.

I think this only makes sense if you pass buffers from one HW device to another.

Because you cannot expect generic video capture code to be able to interpret
all the zillion different combinations of modifiers.


I don't quite follow this last bit. The control could report the set
of supported modifiers.

However, in DRM the API lets you get the supported formats for each
modifier as-well-as the modifier list itself. I'm not sure how exactly
to provide that in a control.

Thanks,
-Brian



Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [radeon-alex:drm-next-4.14-wip 39/44] drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of function 'ttm_populate_and_map_pages'

[Tom St Denis]

On 24/08/17 02:43 AM, Christian König wrote:

The problem is here:

#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)


extern int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device 
*dev);
extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct 
device *dev);


We have forgotten to provide dummies for non SWIOTLB/IOMMU systems and 
xtensa doesn't seem to have this.


And BTW please drop the "extern" keyword here, that is the default for 
functions anyway.


The functions I added don't have extern.  That being said I can write 
two patches one that adds dummy functions and one that removes the 
needless externs.


Cheers,
Tom
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

On Mon, Aug 21, 2017 at 03:45:21PM +0100, Vladimir Murzin wrote:
> On 10/08/17 13:15, Vladimir Murzin wrote:
> > On 26/07/17 11:27, Russell King - ARM Linux wrote:
> >> I suspect the above failure is down to either (a) not having enough
> >> memory available to allocate a 1920x1080 frame buffer, or (b) not
> >> (yet) being able to program the hdlcd pixel clock for this platform,
> >> which is currently hard-coded in DT at 23.75MHz.
> > 
> > Given it is NOMMU it is likely (a). Usually, tweaking FORCE_MAX_ZONEORDER
> > helped me in such cases.
> 
> Ok, with CONFIG_FORCE_MAX_ZONEORDER=12 I see
> 
> [5.242423] [drm] found ARM HDLCD version r0p0
> [5.493835] tda998x 2-0070: found TDA19988
> [5.527771] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x1470f8)
> [5.535819] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [5.543478] [drm] No driver support for vblank timestamp query.
> [7.443189] hdlcd 40205000.hdlcd: fb0:  frame buffer device
> [7.501975] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on 
> minor 0
> 
> when display is connected.
> 
> To make fb-test [1] happy I had to apply following diff:
> 
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index 9a18e1b..d4cb1b1 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -10,6 +10,7 @@ config DRM_HDLCD
> select DRM_ARM
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
> +   select FB_PROVIDE_GET_FB_UNMAPPED_AREA if !MMU
> help
>   Choose this option if you have an ARM High Definition Colour LCD
>   controller.
> 
> (The only user of FB_PROVIDE_GET_FB_UNMAPPED_AREA is NOMMU only 
> drivers/gpu/drm/stm/)
> 
> However, I do not see anything on the screen. I'm probably missing something
> obvious, so if you have an idea, please let me know and I can test the patch.

Do you have fbdev/fbcon enabled? If not, then you need some userspace that
makes use of the DRM interface. I usually play with the tests from
libdrm, you can start with modetest.

Best regards,
Liviu

> 
> [1] https://github.com/prpplague/fb-test-app.git 
> 
> Thanks
> Vladimir
> 
> > 
> > Cheers
> > Vladimir
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 

-- 

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

Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf

[Brian Starkey]

Hi,

Thanks for the CC.

On Fri, Aug 18, 2017 at 06:13:14PM +0200, Noralf Tr??nnes wrote:

(cc affected parties)


Den 18.08.2017 09.46, skrev Daniel Vetter:

On Thu, Aug 17, 2017 at 06:21:30PM +0200, Noralf Tr??nnes wrote:

Reject mapping an imported dma-buf since is's an invalid use-case.

Cc: Philipp Zabel 
Cc: Laurent Pinchart 
Cc: Sean Paul 
Cc: Daniel Vetter 
Signed-off-by: Noralf Tr??nnes 

I think acks from someone using mali would be good too. amdgpu already has
such checks, so I think on the desktop side we're ok.



This looks like it would break anyone running the Mali-4xx series GPUs
with the Arm graphics stack (e.g. Hikey board).

I don't know where that sits in terms of policy.

Cheers,
-Brian


Acked-by: Daniel Vetter 

But I think this one here definitely needs a few more acks. I could break
uabi if we're unlucky, so let's not rush it.


Ok, I've CC'ed the affected parties to increase the odds that they look
at this. These are the drivers using drm_gem_dumb_map_offset()
(hopefully I got the list right):

arc
atmel-hlcdc
cirrus
exynos
fsl-dcu
gma500
hdlcd
imx
kirin
mali-dp
mediatek
meson
mxsfb
pl111
rcar-du
rockchip
shmobile
sti
stm
sun4i
tegra
tilcd
vc4
zte


Noralf.


-Daniel


---
 drivers/gpu/drm/drm_gem.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ad4e9cf..8da5801 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -333,6 +333,12 @@ int drm_gem_dumb_map_offset(struct drm_file *file, struct 
drm_device *dev,
if (!obj)
return -ENOENT;
+   /* Don't allow imported objects to be mapped */
+   if (obj->import_attach) {
+   ret = -EINVAL;
+   goto out;
+   }
+
ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
--
2.7.4




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] Allwinner sun4i DRM changes for 4.14, take 2

[Daniel Vetter]

On Thu, Aug 24, 2017 at 11:22:30AM +0200, Maxime Ripard wrote:
> Hi David,
> 
> Here is a single patch that was sent recently. It could wait for 4.15,
> but it's also minor enough so that's there's no point in delaying it
> either.

Just casually mentioning that drm-misc solves this by keeping the feature
merging always open ... Entirely gets rid of late pulls for convenience
because not other place :-)
-Daniel
> 
> Thanks!
> Maxime
> 
> The following changes since commit 998140d26723bcddef5857e39077898b0d1bdb8f:
> 
>   sun4i_hdmi: add CEC support (2017-07-18 18:27:50 +0200)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git 
> tags/sunxi-drm-for-4.14-2
> 
> for you to fetch changes up to 0bd46d703e0892c6519132c012910982e3e65535:
> 
>   drm/sun4i: use of_graph_get_remote_endpoint() (2017-08-23 16:28:39 +0200)
> 
> 
> sun4i DRM changes for 4.14, take 2
> 
> A single patch switching to a new OF helper.
> 
> 
> Kuninori Morimoto (1):
>   drm/sun4i: use of_graph_get_remote_endpoint()
> 
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com



> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Laurent Pinchart]

Hi Hean Loong,

On Thursday, 24 August 2017 08:41:50 EEST Ong, Hean Loong wrote:
> Hi Laurent,
> 
> I removed the examples for the HDMI in the draft below. The connections
> between the VIP and Display Port IP or any display connector are
> determined by HW logic. There are currently no SW defined encoders or
> connectors that is connected to the AVALON-ST other than the Intel VIP
> Frame Buffer II. Therefore there are no examples for the Display Port
> encoder and connector.

But there must be an encoder, even if its default configuration makes it 
usable without a softwarer driver at the moment. As the encoder is there in 
hardware, it should be described in DT.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] Allwinner sun4i DRM changes for 4.14, take 2

[Maxime Ripard]

Hi David,

Here is a single patch that was sent recently. It could wait for 4.15,
but it's also minor enough so that's there's no point in delaying it
either.

Thanks!
Maxime

The following changes since commit 998140d26723bcddef5857e39077898b0d1bdb8f:

  sun4i_hdmi: add CEC support (2017-07-18 18:27:50 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git 
tags/sunxi-drm-for-4.14-2

for you to fetch changes up to 0bd46d703e0892c6519132c012910982e3e65535:

  drm/sun4i: use of_graph_get_remote_endpoint() (2017-08-23 16:28:39 +0200)


sun4i DRM changes for 4.14, take 2

A single patch switching to a new OF helper.


Kuninori Morimoto (1):
  drm/sun4i: use of_graph_get_remote_endpoint()

 drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/bridge/sii8620: add remote control support

[Maciej Purski]

MHL specification defines Remote Control Protocol(RCP) to
send input events between MHL devices.
The driver now recognizes RCP messages and reacts to them
by reporting key events to input subsystem, allowing
a user to control a device using TV remote control.

Signed-off-by: Maciej Purski 
---

Changes in v2:
- use RC subsystem (including CEC keymap)
- RC device initialized in attach drm_bridge callback and
  removed in detach callback. This is necessary, because RC_CORE,
  which is needed during rc_dev init, is loaded after sii8620.
  DRM bridge is binded later which solves the problem.
- add RC_CORE dependency

Changes in v3:
- fix error handling in init_rcp and in attach callback

Changes in v4:
- usage of rc-core API compatible with upcoming changes
- fix error handling in init_rcp
- fix commit message
---
 drivers/gpu/drm/bridge/Kconfig   |  2 +-
 drivers/gpu/drm/bridge/sil-sii8620.c | 96 ++--
 include/drm/bridge/mhl.h |  4 ++
 3 files changed, 96 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..6ef901c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -71,7 +71,7 @@ config DRM_PARADE_PS8622
 
 config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
-   depends on OF
+   depends on OF && RC_CORE
select DRM_KMS_HELPER
help
  Silicon Image SII8620 HDMI/MHL bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2d51a22..ecb26c4 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include 
+
 #include "sil-sii8620.h"
 
 #define SII8620_BURST_BUF_LEN 288
@@ -58,6 +60,7 @@ enum sii8620_mt_state {
 struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+   struct rc_dev *rc_dev;
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -431,6 +434,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 code)
sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
 }
 
+static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)
+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
+}
+
+static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
+}
+
 static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
struct sii8620_mt_msg *msg)
 {
@@ -1753,6 +1766,25 @@ static void sii8620_send_features(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
 }
 
+static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
+{
+   bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
+
+   scancode &= MHL_RCP_KEY_ID_MASK;
+
+   if (!ctx->rc_dev) {
+   dev_dbg(ctx->dev, "RCP input device not initialized\n");
+   return false;
+   }
+
+   if (pressed)
+   rc_keydown(ctx->rc_dev, RC_PROTO_CEC, scancode, 0);
+   else
+   rc_keyup(ctx->rc_dev);
+
+   return true;
+}
+
 static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
 {
u8 ints[MHL_INT_SIZE];
@@ -1804,19 +1836,25 @@ static void sii8620_msc_mt_done(struct sii8620 *ctx)
 
 static void sii8620_msc_mr_msc_msg(struct sii8620 *ctx)
 {
-   struct sii8620_mt_msg *msg = sii8620_msc_msg_first(ctx);
+   struct sii8620_mt_msg *msg;
u8 buf[2];
 
-   if (!msg)
-   return;
-
sii8620_read_buf(ctx, REG_MSC_MR_MSC_MSG_RCVD_1ST_DATA, buf, 2);
 
switch (buf[0]) {
case MHL_MSC_MSG_RAPK:
+   msg = sii8620_msc_msg_first(ctx);
+   if (!msg)
+   return;
msg->ret = buf[1];
ctx->mt_state = MT_STATE_DONE;
break;
+   case MHL_MSC_MSG_RCP:
+   if (!sii8620_rcp_consume(ctx, buf[1]))
+   sii8620_mt_rcpe(ctx,
+   MHL_RCPE_STATUS_INEFFECTIVE_KEY_CODE);
+   sii8620_mt_rcpk(ctx, buf[1]);
+   break;
default:
dev_err(ctx->dev, "%s message type %d,%d not supported",
__func__, buf[0], buf[1]);
@@ -2102,11 +2140,57 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
 }
 
+static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
+{
+   struct rc_dev *rc_dev;
+   int ret;
+
+   rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
+   if (!rc_dev) {
+   dev_err(ctx->dev, "Failed to allocate RC device\n");
+   ctx->error = -ENOMEM;
+   return;
+   }
+
+   rc_dev->input_phys = "sii8620/input0";
+   rc_dev->input_id.bustype = 

Re: [v2] timers: Fix excessive granularity of new timers after a nohz idle

[Thierry Reding]

On Wed, Aug 23, 2017 at 04:38:14PM +0800, jeffy wrote:
> Hi Thierry,
> 
> i hit a compile error with this patch:
> 
>   CC  drivers/gpu/drm/tegra/trace.o
> In file included from drivers/gpu/drm/tegra/trace.h:68:0,
>  from drivers/gpu/drm/tegra/trace.c:2:
> ./include/trace/define_trace.h:88:43: fatal error: ./trace.h: No such file
> or directory
> compilation terminated.
> scripts/Makefile.build:311: recipe for target
> 'drivers/gpu/drm/tegra/trace.o' failed
> 
> 
> On 08/22/2017 04:43 PM, Nicholas Piggin wrote:
> > +++ b/drivers/gpu/drm/tegra/Makefile
> > @@ -24,4 +24,6 @@ tegra-drm-$(CONFIG_ARCH_TEGRA_186_SOC) += \
> > parker/dsi.o \
> > parker/sor.o
> > 
> > +tegra-drm-y += trace.o
> > +
> 
> maybe we need this:
> 
> +++ b/drivers/gpu/drm/tegra/Makefile
> @@ -19,4 +19,6 @@ tegra-drm-y := \
> 
>  tegra-drm-y += trace.o
> 
> +CFLAGS_trace.o := -I$(src)
> +
>  obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o

Dmitry had also reported this earlier and I think the right fix is this,
which is now in today's linux-next:

commit 702800b5d6f45b18db6b6d6b1057af6fd1c75e20
Author: Thierry Reding 
Date:   Wed Aug 23 19:13:26 2017 +0200

drm/tegra: trace: Fix path to include

The TRACE_INCLUDE_FILE macro needs to specify the path relative to the
define_trace.h header rather than relative to the file defining it.

Reported-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
Signed-off-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102300] Missing 1920x1080_59.94Hz mode (Second monitor shows black screen but has signal)

[bugzilla-daemon]

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

--- Comment #8 from f...@mt2015.com ---
(In reply to Michel Dänzer from comment #7)
> According to the log file, the ASUS monitor only lists the 60 Hz 1920x1080
> mode in its EDID. So it seems clear that's what the monitor wants to be fed,
> but for some reason we don't seem to be generating it properly.
> 
> Any chance you can try if a kernel built from the amd-staging-4.12 or
> amd-staging-drm-next branch of https://cgit.freedesktop.org/~agd5f/linux/
> with CONFIG_DRM_AMD_DC=y works better?

Thank you, It works :) 

I thought amdgpu-staging kernel was only needed for their PRO driver, so i
never had the idea to try it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97556] amdgpu fan behavior doesn't match windows

[bugzilla-daemon]

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

--- Comment #6 from Dimitrios Liappis  ---
I have the same issue on an Asus Radeon RX-550[1] and amdgpu.

The fan is on all the time.
By default pwm1_enable shows 1, however, even when I write 2 to it nothing
changes.

Interestingly enough, `fan1_input` reports no such device, whereas, temp1_input
seems to show the right temp. This seems to be corroborated by the sensors
output where temp is correctly reported but not fan speed.

[root@MS-7885 hwmon0]# pwd
/sys/devices/pci:00/:00:03.0/:03:00.0/hwmon/hwmon0

[root@MS-7885 hwmon0]# cat temp1_input && echo && sensors
32000

amdgpu-pci-0300
Adapter: PCI adapter
fan1: N/A
temp1:+32.0°C  (crit =  +0.0°C, hyst =  +0.0°C)
...

[1]:
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa
PRO [Radeon RX 550] (rev c7) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 0513
Physical Slot: 4
Flags: bus master, fast devsel, latency 0, IRQ 37, NUMA node 0
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at f000 (64-bit, prefetchable) [size=2M]
I/O ports at e000 [size=256]
Memory at fbe0 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

Capabilities: [150] Advanced Error Reporting
Capabilities: [200] #15
Capabilities: [270] #19
Capabilities: [2b0] Address Translation Service (ATS)
Capabilities: [2c0] Page Request Interface (PRI)
Capabilities: [2d0] Process Address Space ID (PASID)
Capabilities: [320] Latency Tolerance Reporting
Capabilities: [328] Alternative Routing-ID Interpretation (ARI)
Capabilities: [370] L1 PM Substates
Kernel driver in use: amdgpu
Kernel modules: amdgpu

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, drm/i915 fixes for v4.13-rc7. A mixed bag of fixes, with black
screen fixes from me and Andy, and a couple of GVT fixes. In retrospect
could have gone without the CNL specific fix, but it's trivial.

I expect this to be the last round of drm/i915 fixes for v4.13 (fingers
crossed). Rodrigo will be taking over fixes for the v4.14 development
cycle, and I'll be taking over features and eventually fixes for
v4.15. We'll be rotating maintainers between Rodrigo, Joonas and myself,
each covering one kernel release at a time from features to following
through with next-fixes and fixes. We'll keep you posted about who's
doing what in the pull requests.


BR,
Jani.

The following changes since commit 781cc76e0c2469cb7ac12ba238a4ea006978e321:

  drm/i915: Avoid the gpu reset vs. modeset deadlock (2017-08-14 19:28:46 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-08-24

for you to fetch changes up to e7c50e1156b6418004187104b1135e88921efa50:

  Merge tag 'gvt-fixes-2017-08-23' of https://github.com/01org/gvt-linux into 
drm-intel-fixes (2017-08-23 11:48:05 +0300)


drm/i915 fixes for v4.13-rc7


Andy Shevchenko (1):
  drm/i915/bxt: use NULL for GPIO connection ID

Balasubramaniam, Hari Chand (1):
  drm/i915: Initialize 'data' in intel_dsi_dcs_backlight.c

Chris Wilson (1):
  drm/i915: Clear lost context-switch interrupts across reset

Jani Nikula (2):
  drm/i915/vbt: ignore extraneous child devices for a port
  Merge tag 'gvt-fixes-2017-08-23' of https://github.com/01org/gvt-linux 
into drm-intel-fixes

Rodrigo Vivi (1):
  drm/i915/cnl: Fix LSPCON support.

fred gao (1):
  drm/i915/gvt: Fix the kernel null pointer error

 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  2 +-
 drivers/gpu/drm/i915/intel_bios.c  | 15 +--
 drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c |  2 +-
 drivers/gpu/drm/i915/intel_dsi_vbt.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 23 ++-
 drivers/gpu/drm/i915/intel_lspcon.c|  4 ++--
 6 files changed, 36 insertions(+), 12 deletions(-)

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

Re: [radeon-alex:drm-next-4.14-wip 39/44] drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of function 'ttm_populate_and_map_pages'

[Christian König]

The problem is here:

#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)


extern int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device 
*dev);
extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct 
device *dev);


We have forgotten to provide dummies for non SWIOTLB/IOMMU systems and 
xtensa doesn't seem to have this.


And BTW please drop the "extern" keyword here, that is the default for 
functions anyway.


Regards,
Christian.

Am 23.08.2017 um 23:16 schrieb StDenis, Tom:

Odd.  I mean I had build tested it even though I don't have radeon cards to 
devel with (other than my tahiti I guess but I rarely use that).

Tom

From: Deucher, Alexander
Sent: Wednesday, August 23, 2017 17:12
To: StDenis, Tom; kbuild test robot
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Koenig, Christian
Subject: RE: [radeon-alex:drm-next-4.14-wip 39/44] 
drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of 
function 'ttm_populate_and_map_pages'


-Original Message-
From: StDenis, Tom
Sent: Wednesday, August 23, 2017 5:08 PM
To: kbuild test robot
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander;
Koenig, Christian
Subject: Re: [radeon-alex:drm-next-4.14-wip 39/44]
drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of
function 'ttm_populate_and_map_pages'

The only way this would be possible if if the commit
d1c99475f269a85e0a1916c949526cb22b157271 didn't make it into the public
staging tree.

It's there:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.14-wip=49ad04f2eae72fe928716efe557c73d1f346b9fd
Built fine here.

Alex


Tom



From: kbuild test robot 
Sent: Wednesday, August 23, 2017 16:52
To: StDenis, Tom
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander;
Koenig, Christian
Subject: [radeon-alex:drm-next-4.14-wip 39/44]
drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of
function 'ttm_populate_and_map_pages'

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.14-wip
head:   9f7373596843431b63965965f1059d39600db3a2
commit: 217dcd53c963af28d04c357aed922f1faa20 [39/44] drm/radeon:
use new TTM populate/dma map helper functions
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
 wget https://raw.githubusercontent.com/01org/lkp-
tests/master/sbin/make.cross -O ~/bin/make.cross
 chmod +x ~/bin/make.cross
 git checkout 217dcd53c963af28d04c357aed922f1faa20
 # save the attached .config to linux build tree
 make.cross ARCH=xtensa

All errors (new ones prefixed by >>):

drivers/gpu/drm/radeon/radeon_ttm.c: In function
'radeon_ttm_tt_populate':

drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration

of function 'ttm_populate_and_map_pages' [-Werror=implicit-function-
declaration]
  return ttm_populate_and_map_pages(rdev->dev, >ttm);
  ^
drivers/gpu/drm/radeon/radeon_ttm.c: In function
'radeon_ttm_tt_unpopulate':

drivers/gpu/drm/radeon/radeon_ttm.c:796:2: error: implicit declaration

of function 'ttm_unmap_and_unpopulate_pages' [-Werror=implicit-
function-declaration]
  ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
  ^
cc1: some warnings being treated as errors

vim +/ttm_populate_and_map_pages +763
drivers/gpu/drm/radeon/radeon_ttm.c

762
  > 763  return ttm_populate_and_map_pages(rdev->dev, >ttm);
764  }
765
766  static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
767  {
768  struct radeon_device *rdev;
769  struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
770  bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
771
772  if (gtt && gtt->userptr) {
773  kfree(ttm->sg);
774  ttm->page_flags &= ~TTM_PAGE_FLAG_SG;
775  return;
776  }
777
778  if (slave)
779  return;
780
781  rdev = radeon_get_rdev(ttm->bdev);
782  #if IS_ENABLED(CONFIG_AGP)
783  if (rdev->flags & RADEON_IS_AGP) {
784  ttm_agp_tt_unpopulate(ttm);
785  return;
786  }
787  #endif
788
789  #ifdef CONFIG_SWIOTLB
790  if (swiotlb_nr_tbl()) {
791  ttm_dma_unpopulate(>ttm, rdev->dev);
792  return;
793  }
794  #endif
795
  > 796  ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
797  }
798

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



___
dri-devel mailing list
dri-devel@lists.freedesktop.org