[PATCH] drm: Fix typo in lastclose description

[Gwan-gyeong Mun]

ownershipe -> ownership

Signed-off-by: Mun Gwan-gyeong 
---
 include/drm/drm_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index d23dcdd1bd95..64cb5975613c 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -140,7 +140,7 @@ struct drm_driver {
 *
 * All legacy drivers use this callback to de-initialize the hardware.
 * This is purely because of the shadow-attach model, where the DRM
-* kernel driver does not really own the hardware. Instead ownershipe is
+* kernel driver does not really own the hardware. Instead ownership is
 * handled with the help of userspace through an inheritedly racy dance
 * to set/unset the VT into raw mode.
 *
-- 
2.16.2

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

Re: Aspirant for GSOC 2018 for Nouveau Vulkan driver

[Anusha Srivastava]

Hi Martin,

Any update on this ?
Regards,
Anusha Srivastava


On 28 February 2018 at 23:37, Anusha Srivastava  wrote:
> Hi,
>
> I would like to participate in  GSOC 2018 with Xorg to contribute to
> project "Initial Nouveau Vulkan driver'
> I would need some help in how to get started with the same.
>
> Regards,
> Anusha Srivastava
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

--- Comment #181 from Sandeep  ---
I was able to reliably reproduce the bug with openarena on my XFX R9 390 -
here's a link to a trace file (1.8 GB) -
https://drive.google.com/file/d/1YbOtWheR9RJdqnwya1rMNw1NphVptAUX/view?usp=sharing

-- 
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 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

[bugzilla-daemon]

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

--- Comment #17 from Sandeep  ---
Definitely seems to be DPM related, I used the following command to force DPM
performance level, and Left 4 Dead 2 and OpenArena worked fine with no hangs.

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

Works fine if I set "low" as well.

The system hangs if I set "auto".

Well, atleast I have a trace that reproduces 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 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

[bugzilla-daemon]

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

--- Comment #16 from Sandeep  ---
Ok, I was able to successfully reproduce using a trace from OpenArena.

I'll try uploading the file and paste a link here.

-- 
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 105262] [R600] [BISECTED] ttf fonts are invisible in many programs

[bugzilla-daemon]

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

--- Comment #11 from Roland Scheidegger  ---
Created attachment 137762
  --> https://bugs.freedesktop.org/attachment.cgi?id=137762=edit
copy over export color mask

Would this patch help?
I think the r600 code forgot to copy over the export mask (at least the eg code
does 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 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

[bugzilla-daemon]

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

--- Comment #15 from Sandeep  ---
Trying to get an apitrace trace so that I can reproduce consistently.

Found out that I can reproduce reliably with OpenArena. Will try to create a
trace now.

-- 
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] drm/vc4: Add support for SAND modifier.

[Eric Anholt]

From: Dave Stevenson 

This is the format generated by VC4's H.264 engine, and preferred by
the ISP as well.  By displaying SAND buffers directly, we can avoid
needing to use the ISP to rewrite the SAND H.264 output to linear
before display.

This is a joint effort by Dave Stevenson (who wrote the initial patch
and DRM demo) and Eric Anholt (drm_fourcc.h generalization, safety
checks, RGBA support).

Signed-off-by: Dave Stevenson 
Signed-off-by: Eric Anholt 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Boris Brezillon 
Cc: Maxime Ripard 
---

Ccing a couple of folks who are likely to have opinions about
drm_fourcc.h additions (Do we have enough docs?  Are the macros OK?),
and Bootlin who are likely reviewers.

The plan is to use these modifiers in VC4 GL imports as well, and for
buffers coming from the v4l2 mmal camera driver.  You can find a demo
using this in KMS planes at
https://github.com/anholt/drm_mmal/commit/sand for now.

 drivers/gpu/drm/vc4/vc4_plane.c | 84 +
 drivers/gpu/drm/vc4/vc4_regs.h  |  6 +++
 include/uapi/drm/drm_fourcc.h   | 59 +
 3 files changed, 142 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index c4c7af11fec5..97de9c7821c7 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -520,10 +520,12 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
struct drm_framebuffer *fb = state->fb;
u32 ctl0_offset = vc4_state->dlist_count;
const struct hvs_format *format = 
vc4_get_hvs_format(fb->format->format);
+   u64 base_format_mod = fourcc_mod_broadcom_mod(fb->modifier);
int num_planes = drm_format_num_planes(format->drm);
u32 scl0, scl1, pitch0;
u32 lbm_size, tiling;
unsigned long irqflags;
+   u32 hvs_format = format->hvs;
int ret, i;
 
ret = vc4_plane_setup_clipping_and_scaling(state);
@@ -563,7 +565,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
scl1 = vc4_get_scl_field(state, 0);
}
 
-   switch (fb->modifier) {
+   switch (base_format_mod) {
case DRM_FORMAT_MOD_LINEAR:
tiling = SCALER_CTL0_TILING_LINEAR;
pitch0 = VC4_SET_FIELD(fb->pitches[0], SCALER_SRC_PITCH);
@@ -586,6 +588,49 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
break;
}
 
+   case DRM_FORMAT_MOD_BROADCOM_SAND64:
+   case DRM_FORMAT_MOD_BROADCOM_SAND128:
+   case DRM_FORMAT_MOD_BROADCOM_SAND256: {
+   uint32_t param = fourcc_mod_broadcom_param(fb->modifier);
+
+   /* Column-based NV12 or RGBA.
+*/
+   if (fb->format->num_planes > 1) {
+   if (hvs_format != HVS_PIXEL_FORMAT_YCBCR_YUV420_2PLANE) 
{
+   DRM_DEBUG_KMS("SAND format only valid for 
NV12/21");
+   return -EINVAL;
+   }
+   hvs_format = HVS_PIXEL_FORMAT_H264;
+   } else {
+   if (base_format_mod == DRM_FORMAT_MOD_BROADCOM_SAND256) 
{
+   DRM_DEBUG_KMS("SAND256 format only valid for 
H.264");
+   return -EINVAL;
+   }
+   }
+
+   switch (base_format_mod) {
+   case DRM_FORMAT_MOD_BROADCOM_SAND64:
+   tiling = SCALER_CTL0_TILING_64B;
+   break;
+   case DRM_FORMAT_MOD_BROADCOM_SAND128:
+   tiling = SCALER_CTL0_TILING_128B;
+   break;
+   case DRM_FORMAT_MOD_BROADCOM_SAND256:
+   tiling = SCALER_CTL0_TILING_256B_OR_T;
+   break;
+   default:
+   break;
+   }
+
+   if (param > SCALER_TILE_HEIGHT_MASK) {
+   DRM_DEBUG_KMS("SAND height too large (%d)\n", param);
+   return -EINVAL;
+   }
+
+   pitch0 = VC4_SET_FIELD(param, SCALER_TILE_HEIGHT);
+   break;
+   }
+
default:
DRM_DEBUG_KMS("Unsupported FB tiling flag 0x%16llx",
  (long long)fb->modifier);
@@ -596,7 +641,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
vc4_dlist_write(vc4_state,
SCALER_CTL0_VALID |
(format->pixel_order << SCALER_CTL0_ORDER_SHIFT) |
-   (format->hvs << SCALER_CTL0_PIXEL_FORMAT_SHIFT) |
+   (hvs_format << SCALER_CTL0_PIXEL_FORMAT_SHIFT) |
VC4_SET_FIELD(tiling, SCALER_CTL0_TILING) |

Re: [DPU PATCH 11/11] drm/msm: Remove dpu input fences

[Jeykumar Sankaran]

On 2018-02-28 11:19, Sean Paul wrote:

These are already provided by drm atomic core.

In conjunction with the output fences removed earlier, this obsoletes
dpu_fence, and it can be entirely removed as well.

Change-Id: Ida4924a09c455d7a84bfee569bd0d2fb436418de
Signed-off-by: Sean Paul 


Reviewed-by: Jeykumar Sankaran 


---
 drivers/gpu/drm/msm/Makefile  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  84 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.c | 404 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.h | 190 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 104 --
 drivers/gpu/drm/msm/msm_drv.h |   4 +-
 6 files changed, 1 insertion(+), 786 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_fence.h

diff --git a/drivers/gpu/drm/msm/Makefile 
b/drivers/gpu/drm/msm/Makefile

index 2fb9ba11df19..b47ef5267e19 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -55,7 +55,6 @@ msm-y := \
disp/dpu1/dpu_encoder.o \
disp/dpu1/dpu_encoder_phys_cmd.o \
disp/dpu1/dpu_encoder_phys_vid.o \
-   disp/dpu1/dpu_fence.o \
disp/dpu1/dpu_formats.o \
disp/dpu1/dpu_hw_ad4.o \
disp/dpu1/dpu_hw_blk.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 2d44989ade7a..8dd986e476bd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -64,16 +64,6 @@ static struct dpu_crtc_custom_events custom_events[] 
=

{
{DRM_EVENT_IDLE_NOTIFY, dpu_crtc_idle_interrupt_handler}
 };

-/* default input fence timeout, in ms */
-#define DPU_CRTC_INPUT_FENCE_TIMEOUT1
-
-/*
- * The default input fence timeout is 2 seconds while max allowed
- * range is 10 seconds. Any value above 10 seconds adds glitches 
beyond

- * tolerance limit.
- */
-#define DPU_CRTC_MAX_INPUT_FENCE_TIMEOUT 1
-
 /* layer mixer index on dpu_crtc */
 #define LEFT_MIXER 0
 #define RIGHT_MIXER 1
@@ -1946,21 +1936,6 @@ static void _dpu_crtc_set_idle_timeout(struct
drm_crtc *crtc, u64 val)
}
 }

-/**
- * _dpu_crtc_set_input_fence_timeout - update ns version of in fence
timeout
- * @cstate: Pointer to dpu crtc state
- */
-static void _dpu_crtc_set_input_fence_timeout(struct dpu_crtc_state
*cstate)
-{
-   if (!cstate) {
-   DPU_ERROR("invalid cstate\n");
-   return;
-   }
-   cstate->input_fence_timeout_ns =
-   dpu_crtc_get_property(cstate,
CRTC_PROP_INPUT_FENCE_TIMEOUT);
-   cstate->input_fence_timeout_ns *= NSEC_PER_MSEC;
-}
-
 /**
  * _dpu_crtc_set_dim_layer_v1 - copy dim layer settings from userspace
  * @cstate:  Pointer to dpu crtc state
@@ -2385,53 +2360,6 @@ static int 
_dpu_crtc_check_dest_scaler_data(struct

drm_crtc *crtc,
return ret;
 }

-/**
- * _dpu_crtc_wait_for_fences - wait for incoming framebuffer sync 
fences

- * @crtc: Pointer to CRTC object
- */
-static void _dpu_crtc_wait_for_fences(struct drm_crtc *crtc)
-{
-   struct drm_plane *plane = NULL;
-   uint32_t wait_ms = 1;
-   ktime_t kt_end, kt_wait;
-   int rc = 0;
-
-   DPU_DEBUG("\n");
-
-   if (!crtc || !crtc->state) {
-   DPU_ERROR("invalid crtc/state %pK\n", crtc);
-   return;
-   }
-
-   /* use monotonic timer to limit total fence wait time */
-   kt_end = ktime_add_ns(ktime_get(),
-   to_dpu_crtc_state(crtc->state)->input_fence_timeout_ns);
-
-   /*
-* Wait for fences sequentially, as all of them need to be
signalled
-* before we can proceed.
-*
-* Limit total wait time to INPUT_FENCE_TIMEOUT, but still call
-* dpu_plane_wait_input_fence with wait_ms == 0 after the timeout
so
-* that each plane can check its fence status and react
appropriately
-* if its fence has timed out. Call input fence wait multiple
times if
-* fence wait is interrupted due to interrupt call.
-*/
-   DPU_ATRACE_BEGIN("plane_wait_input_fence");
-   drm_atomic_crtc_for_each_plane(plane, crtc) {
-   do {
-   kt_wait = ktime_sub(kt_end, ktime_get());
-   if (ktime_compare(kt_wait, ktime_set(0, 0)) >= 0)
-   wait_ms = ktime_to_ms(kt_wait);
-   else
-   wait_ms = 0;
-
-   rc = dpu_plane_wait_input_fence(plane, wait_ms);
-   } while (wait_ms && rc == -ERESTARTSYS);
-   }
-   DPU_ATRACE_END("plane_wait_input_fence");
-}
-
 static void _dpu_crtc_setup_mixer_for_encoder(
struct drm_crtc *crtc,
struct drm_encoder *enc)
@@ -2716,9 +2644,6 @@ static void dpu_crtc_atomic_flush(struct drm_crtc
*crtc,
drm_atomic_crtc_for_each_plane(plane, 

Re: [DPU PATCH 08/11] drm/msm: Remove hand-rolled out fences

[Jeykumar Sankaran]

On 2018-02-28 11:19, Sean Paul wrote:

Remove release/output/retire fences from the dpu driver. These are
already available via drm core's OUT_FENCE property.

Change-Id: Id4238d0b5457f2c8ee2e87bb7814e1850a573623
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c |  66 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h |  23 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 178 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |  28 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |   3 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h   |   4 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h  |   8 -
 .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  |  73 +--
 .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  19 --
 .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   |  12 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  30 ---
 drivers/gpu/drm/msm/msm_drv.h |   3 -
 12 files changed, 36 insertions(+), 411 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
index 57b8627ef418..cc5bfa862cb7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
@@ -521,7 +521,6 @@ static void dpu_connector_destroy(struct 
drm_connector

*connector)
backlight_device_unregister(c_conn->bl_device);
drm_connector_unregister(connector);
mutex_destroy(_conn->lock);
-   dpu_fence_deinit(_conn->retire_fence);
drm_connector_cleanup(connector);
kfree(c_conn);
 }
@@ -906,12 +905,9 @@ static int 
dpu_connector_atomic_get_property(struct

drm_connector *connector,
c_state = to_dpu_connector_state(state);

idx = msm_property_index(_conn->property_info, property);
-   if (idx == CONNECTOR_PROP_RETIRE_FENCE)
-   rc = dpu_fence_create(_conn->retire_fence, val, 0);
-   else
-   /* get cached property value */
-   rc = msm_property_atomic_get(_conn->property_info,
-   _state->property_state, property, val);
+   /* get cached property value */
+   rc = msm_property_atomic_get(_conn->property_info,
+   _state->property_state, property, val);

/* allow for custom override */
if (c_conn->ops.get_property)
@@ -923,39 +919,6 @@ static int 
dpu_connector_atomic_get_property(struct

drm_connector *connector,
return rc;
 }

-void dpu_connector_prepare_fence(struct drm_connector *connector)
-{
-   if (!connector) {
-   DPU_ERROR("invalid connector\n");
-   return;
-   }
-
-   dpu_fence_prepare(_dpu_connector(connector)->retire_fence);
-}
-
-void dpu_connector_complete_commit(struct drm_connector *connector,
-   ktime_t ts)
-{
-   if (!connector) {
-   DPU_ERROR("invalid connector\n");
-   return;
-   }
-
-   /* signal connector's retire fence */
-   dpu_fence_signal(_dpu_connector(connector)->retire_fence, ts,
false);
-}
-
-void dpu_connector_commit_reset(struct drm_connector *connector, 
ktime_t

ts)
-{
-   if (!connector) {
-   DPU_ERROR("invalid connector\n");
-   return;
-   }
-
-   /* signal connector's retire fence */
-   dpu_fence_signal(_dpu_connector(connector)->retire_fence, ts,
true);
-}
-
 static enum drm_connector_status
 dpu_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -1214,26 +1177,19 @@ struct drm_connector *dpu_connector_init(struct
drm_device *dev,
"conn%u",
c_conn->base.base.id);

-   rc = dpu_fence_init(_conn->retire_fence, c_conn->name,
-   c_conn->base.base.id);
-   if (rc) {
-   DPU_ERROR("failed to init fence, %d\n", rc);
-   goto error_cleanup_conn;
-   }
-
mutex_init(_conn->lock);

rc = drm_mode_connector_attach_encoder(_conn->base, encoder);
if (rc) {
DPU_ERROR("failed to attach encoder to connector, %d\n",
rc);
-   goto error_cleanup_fence;
+   goto error_cleanup_conn;
}

 #ifdef CONFIG_DRM_MSM_DSI_STAGING
rc = dpu_backlight_setup(c_conn, dev);
if (rc) {
DPU_ERROR("failed to setup backlight, rc=%d\n", rc);
-   goto error_cleanup_fence;
+   goto error_cleanup_conn;
}
 #endif

@@ -1248,7 +1204,7 @@ struct drm_connector *dpu_connector_init(struct
drm_device *dev,
if (!info) {
DPU_ERROR("failed to allocate info buffer\n");
rc = -ENOMEM;
-   goto error_cleanup_fence;
+   goto error_cleanup_conn;
}

dpu_kms_info_reset(info);
@@ -1256,7 +1212,7 @@ struct drm_connector *dpu_connector_init(struct
drm_device *dev,
   

Re: [DPU PATCH 04/11] drm/msm: Move implicit sync fence handling to prepare_fb

[jsanka]

On 2018-02-28 11:18, Sean Paul wrote:
This is another piece that can be moved out of atomic to facilitate 
using

the atomic helpers.

Change-Id: I6dc3c4e5df508942bbc378c73a44e46e511b8469
Signed-off-by: Sean Paul 


Reviewed-by: Jeykumar Sankaran 


---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  8 
 drivers/gpu/drm/msm/msm_atomic.c  | 13 -
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 834dcc0bfefd..29e72b39fd72 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -2720,6 +2720,8 @@ static int dpu_plane_prepare_fb(struct drm_plane
*plane,
struct dpu_plane_rot_state *new_rstate;
struct dpu_hw_fmt_layout layout;
struct msm_gem_address_space *aspace;
+   struct msm_gem_object *msm_obj;
+   struct dma_fence *fence;
int ret;

if (!new_state->fb)
@@ -2761,6 +2763,12 @@ static int dpu_plane_prepare_fb(struct drm_plane
*plane,
return ret;
}

+   /* To support implicit sync, set a fence on the plane if
appropriate */
+   msm_obj = to_msm_bo(msm_framebuffer_bo(fb, 0));
+   fence = reservation_object_get_excl_rcu(msm_obj->resv);
+   if (fence)
+   drm_atomic_set_fence_for_plane(new_state, fence);
+
return 0;
 }

diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index eb2ccda5da0f..3a18bd3dc215 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -282,19 +282,6 @@ int msm_atomic_commit(struct drm_device *dev,
for_each_new_crtc_in_state(state, crtc, crtc_state, i)
c->crtc_mask |= drm_crtc_mask(crtc);

-   /*
-* Figure out what fence to wait for:
-*/
-   for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
-   if ((new_plane_state->fb != old_plane_state->fb) &&
new_plane_state->fb) {
-   struct drm_gem_object *obj =
msm_framebuffer_bo(new_plane_state->fb, 0);
-   struct msm_gem_object *msm_obj = to_msm_bo(obj);
-   struct dma_fence *fence =
reservation_object_get_excl_rcu(msm_obj->resv);
-
-   drm_atomic_set_fence_for_plane(new_plane_state,
fence);
-   }
-   }
-
/*
 * Wait for pending updates on any of the same crtc's and then
 * mark our set of crtc's as busy:

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

Re: [PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

[JeffyChen]

Hi Laurent,

On 03/03/2018 05:49 AM, Laurent Pinchart wrote:

Hi Enric,

Thank you for the patch.

On Friday, 2 March 2018 19:57:57 EET Enric Balletbo i Serra wrote:

From: Jeffy Chen 

We inited connector in attach(), so need a detach() to cleanup.


Do we ? The dw-hdmi driver already sets drm_connector_cleanup() as the
connector .destroy() handler, and the .destroy() operation is called by the
DRM core. None of the other bridge drivers call drm_connector_cleanup()
directly.


hmmm, checking the code, there are also lots of drivers do the 
cleanup(drm_connector_cleanup or funcs->destroy):

drm# grep -r "connector.*funcs->destroy" .
./rockchip/inno_hdmi.c: hdmi->connector.funcs->destroy(>connector);
./rockchip/cdn-dp-core.c:   connector->funcs->destroy(connector);
./bridge/analogix/analogix_dp_core.c: 
dp->connector.funcs->destroy(>connector);
./msm/hdmi/hdmi.c: 
hdmi->connector->funcs->destroy(hdmi->connector);
./msm/dsi/dsi.c: 
msm_dsi->connector->funcs->destroy(msm_dsi->connector);
./msm/edp/edp.c: 
edp->connector->funcs->destroy(edp->connector);

./zte/zx_hdmi.c:hdmi->connector.funcs->destroy(>connector);
./drm_connector.c:  connector->funcs->destroy(connector);
./drm_connector.c:  connector->funcs->destroy(connector);
./nouveau/dispnv04/disp.c: 
connector->funcs->destroy(connector);
./nouveau/nv50_display.c: 
mstc->connector.funcs->destroy(>connector);
./nouveau/nv50_display.c: 
connector->funcs->destroy(connector);




when i debug analogix_dp bind/unbind, i found that we need to cleanup 
the connector(reported by kmemleak). so i added it to 
./bridge/analogix/analogix_dp_core.c...after that i saw dw-hdmi missing 
that too(by checking the code), so make this patch.


but i didn't really tested it on devices using dw-hdmi, so i'm not very 
sure the dw-hdmi(maybe also other bridges) is the same with analogix_dp.


i can try to find a chromebook veyron to check it next week :)

but even there's a leak, i'm still not very sure about:
should the caller of drm_connector_init cleanup it
or the caller of drm_bridge_attach should do it(for example 
analogix_dp_bind/analogix_dp_unbind)

or should the DRM core take care of that?




Signed-off-by: Jeffy Chen 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v9: None

  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
f9802399cc0d..5626922f95f9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1985,6 +1985,13 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
*bridge) return 0;
  }

+static void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   drm_connector_cleanup(>connector);
+}
+
  static enum drm_mode_status
  dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
  const struct drm_display_mode *mode)
@@ -2041,6 +2048,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge
*bridge)

  static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.attach = dw_hdmi_bridge_attach,
+   .detach = dw_hdmi_bridge_detach,
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,





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

Re: [DPU PATCH 01/11] drm/msm: Skip seamless disables in crtc/encoder

[jsanka]

On 2018-02-28 11:18, Sean Paul wrote:

Instead of duplicating whole swaths of atomic helper functions (which
are already out-of-date), just skip the encoder/crtc disables in the
.disable hooks.

Change-Id: I7bd9183ae60624204fb1de9550656b776efc7202
Signed-off-by: Sean Paul 


Can you consider getting rid of these checks?


---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|   8 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |   8 +
 drivers/gpu/drm/msm/msm_atomic.c| 185 +---
 3 files changed, 17 insertions(+), 184 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 3cdf1e3d9d96..a3ab6ed2bf1d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -3393,6 +3393,7 @@ static void dpu_crtc_disable(struct drm_crtc 
*crtc)

 {
struct dpu_crtc *dpu_crtc;
struct dpu_crtc_state *cstate;
+   struct drm_display_mode *mode;
struct drm_encoder *encoder;
struct msm_drm_private *priv;
unsigned long flags;
@@ -3407,8 +3408,15 @@ static void dpu_crtc_disable(struct drm_crtc 
*crtc)

}
dpu_crtc = to_dpu_crtc(crtc);
cstate = to_dpu_crtc_state(crtc->state);
+   mode = >base.adjusted_mode;
priv = crtc->dev->dev_private;

+   if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode)
||
+   msm_is_mode_seamless_dms(mode)) {
+   DPU_DEBUG("Seamless mode is being applied, skip
disable\n");
+   return;
+   }
+

Another topic of discussion which should be brought up with dri-devel.

May not be common in PC world, but there are a handful of mobile OEM's
using panels which supports more than one resolution. Primary use cases
involve "seamless" switching to optimized display resolution when
streaming content changes resolutions or rendering lossless data.

Jeykumar S.


DPU_DEBUG("crtc%d\n", crtc->base.id);

if (dpu_kms_is_suspend_state(crtc->dev))
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3d168fa09f3f..28ceb589ee40 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2183,6 +2183,7 @@ static void dpu_encoder_virt_disable(struct
drm_encoder *drm_enc)
struct dpu_encoder_virt *dpu_enc = NULL;
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
+   struct drm_display_mode *mode;
int i = 0;

if (!drm_enc) {
@@ -2196,6 +2197,13 @@ static void dpu_encoder_virt_disable(struct
drm_encoder *drm_enc)
return;
}

+   mode = _enc->crtc->state->adjusted_mode;
+   if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode)
||
+   msm_is_mode_seamless_dms(mode)) {
+   DPU_DEBUG("Seamless mode is being applied, skip
disable\n");
+   return;
+   }
+
dpu_enc = to_dpu_encoder_virt(drm_enc);
DPU_DEBUG_ENC(dpu_enc, "\n");

diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index 46536edb72ee..5cfb80345052 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -84,189 +84,6 @@ static void msm_atomic_wait_for_commit_done(
}
 }

-static void
-msm_disable_outputs(struct drm_device *dev, struct drm_atomic_state
*old_state)
-{
-   struct drm_connector *connector;
-   struct drm_connector_state *old_conn_state, *new_conn_state;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
-   int i;
-
-   for_each_oldnew_connector_in_state(old_state, connector,
old_conn_state, new_conn_state, i) {
-   const struct drm_encoder_helper_funcs *funcs;
-   struct drm_encoder *encoder;
-   struct drm_crtc_state *old_crtc_state;
-   unsigned int crtc_idx;
-
-   /*
-* Shut down everything that's in the changeset and
currently
-* still on. So need to check the old, saved state.
-*/
-   if (!old_conn_state->crtc)
-   continue;
-
-   crtc_idx = drm_crtc_index(old_conn_state->crtc);
-   old_crtc_state = drm_atomic_get_old_crtc_state(old_state,
-
old_conn_state->crtc);
-
-   if (!old_crtc_state->active ||
-
!drm_atomic_crtc_needs_modeset(old_conn_state->crtc->state))
-   continue;
-
-   encoder = old_conn_state->best_encoder;
-
-   /* We shouldn't get this far if we didn't previously have
-* an encoder.. but WARN_ON() rather than explode.
-*/
-   if (WARN_ON(!encoder))
-   continue;
-
-   if (msm_is_mode_seamless(
-   >encoder->crtc->state->mode) ||
-   

Re: [PATCH] drm/dp: only accept valid DP_TRAINING_AUX_RD_INTERVAL values

[Manasi Navare]

Thanks for the patch. Masking the training AUX RD interval value to get
only the allowed values sounds of 0-4 is absolutely needed. Just one nit below:

On Fri, Mar 02, 2018 at 02:25:58PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> For panels that do not follow Display Port specifications mask off invalid
> values for DP_TRAINING_AUX_RD_INTERVAL. Specification lists acceptable

It would be good to call out DP specification and a particular version number 
if possible
So DP 1.2 specification.

With that change,
Reviewed-by: Manasi Navare 

> values 0-4 all other values are reserved and bit 7 of DPCD 0xe
> describes another feature. Currently the code uses all of DPCD 0xe and
> can cause max wait for 1024 ms instead of 16 ms as specified table 2-158.
> This address is read for both clock recovery and channel equalization.
>

> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 4 ++--
>  include/drm/drm_dp_helper.h | 1 +
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..a7e9b75 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -122,7 +122,7 @@ void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE])
>   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay((dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK) * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
> @@ -130,7 +130,7 @@ void drm_dp_link_train_channel_eq_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
>   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay((dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK) * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..77ba003 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -118,6 +118,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7 /* 1.4 */
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.7.4
> 
> ___
> 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] drm/dp: only accept valid DP_TRAINING_AUX_RD_INTERVAL values

[Rodrigo Vivi]

On Fri, Mar 02, 2018 at 02:25:58PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> For panels that do not follow Display Port specifications mask off invalid
> values for DP_TRAINING_AUX_RD_INTERVAL. Specification lists acceptable
> values 0-4 all other values are reserved and bit 7 of DPCD 0xe
> describes another feature. Currently the code uses all of DPCD 0xe and
> can cause max wait for 1024 ms instead of 16 ms as specified table 2-158.
> This address is read for both clock recovery and channel equalization.
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 4 ++--
>  include/drm/drm_dp_helper.h | 1 +
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..a7e9b75 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -122,7 +122,7 @@ void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE])
>   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay((dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK) * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
> @@ -130,7 +130,7 @@ void drm_dp_link_train_channel_eq_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
>   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay((dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK) * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..77ba003 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -118,6 +118,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7 /* 1.4 */

I confirmed it is already part of 1.2 and 1.3
So probably a good idea to already to s/XXX 1.2?/1.2/
but this is optional and up to you.

With s/1.4/1.2 feel free to add:

Reviewed-by: Rodrigo Vivi 

(well... in a hope that no other bad panel uses 5,6 or 7,
that are also reserved values. But I believe these cases shouldn't
be as bad as this one you faced here anyways)

>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.7.4
> 
> ___
> 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

[PATCH] drm/vc4: Add some missing HVS register definitions.

[Eric Anholt]

At least the RGBA expand field we should have been setting, because we
aren't expanding correctly for 565 -> .  Other registers are ones
that may be interesting for various projects that have been discussed.

Signed-off-by: Eric Anholt 
Cc: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_regs.h | 96 ++
 1 file changed, 96 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index b9749cb24063..ce8bb7486456 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -330,6 +330,21 @@
 #define SCALER_DISPCTRL00x0040
 # define SCALER_DISPCTRLX_ENABLE   BIT(31)
 # define SCALER_DISPCTRLX_RESETBIT(30)
+/* Generates a single frame when VSTART is seen and stops at the last
+ * pixel read from the FIFO.
+ */
+# define SCALER_DISPCTRLX_ONESHOT  BIT(29)
+/* Processes a single context in the dlist and then task switch,
+ * instead of an entire line.
+ */
+# define SCALER_DISPCTRLX_ONECTX   BIT(28)
+/* Set to have DISPSLAVE return 2 16bpp pixels and no status data. */
+# define SCALER_DISPCTRLX_FIFO32   BIT(27)
+/* Turns on output to the DISPSLAVE register instead of the normal
+ * FIFO.
+ */
+# define SCALER_DISPCTRLX_FIFOREG  BIT(26)
+
 # define SCALER_DISPCTRLX_WIDTH_MASK   VC4_MASK(23, 12)
 # define SCALER_DISPCTRLX_WIDTH_SHIFT  12
 # define SCALER_DISPCTRLX_HEIGHT_MASK  VC4_MASK(11, 0)
@@ -402,6 +417,68 @@
  */
 # define SCALER_GAMADDR_SRAMENBBIT(30)
 
+#define SCALER_OLEDOFFS 0x0080
+/* Clamps R to [16,235] and G/B to [16,240]. */
+# define SCALER_OLEDOFFS_YUVCLAMP   BIT(31)
+
+/* Chooses which display FIFO the matrix applies to. */
+# define SCALER_OLEDOFFS_DISPFIFO_MASK  VC4_MASK(25, 24)
+# define SCALER_OLEDOFFS_DISPFIFO_SHIFT 24
+# define SCALER_OLEDOFFS_DISPFIFO_DISABLED  0
+# define SCALER_OLEDOFFS_DISPFIFO_0 1
+# define SCALER_OLEDOFFS_DISPFIFO_1 2
+# define SCALER_OLEDOFFS_DISPFIFO_2 3
+
+/* Offsets are 8-bit 2s-complement. */
+# define SCALER_OLEDOFFS_RED_MASK   VC4_MASK(23, 16)
+# define SCALER_OLEDOFFS_RED_SHIFT  16
+# define SCALER_OLEDOFFS_GREEN_MASK VC4_MASK(15, 8)
+# define SCALER_OLEDOFFS_GREEN_SHIFT8
+# define SCALER_OLEDOFFS_BLUE_MASK  VC4_MASK(7, 0)
+# define SCALER_OLEDOFFS_BLUE_SHIFT 0
+
+/* The coefficients are S0.9 fractions. */
+#define SCALER_OLEDCOEF00x0084
+# define SCALER_OLEDCOEF0_B_TO_R_MASK   VC4_MASK(29, 20)
+# define SCALER_OLEDCOEF0_B_TO_R_SHIFT  20
+# define SCALER_OLEDCOEF0_B_TO_G_MASK   VC4_MASK(19, 10)
+# define SCALER_OLEDCOEF0_B_TO_G_SHIFT  10
+# define SCALER_OLEDCOEF0_B_TO_B_MASK   VC4_MASK(9, 0)
+# define SCALER_OLEDCOEF0_B_TO_B_SHIFT  0
+
+#define SCALER_OLEDCOEF10x0088
+# define SCALER_OLEDCOEF1_G_TO_R_MASK   VC4_MASK(29, 20)
+# define SCALER_OLEDCOEF1_G_TO_R_SHIFT  20
+# define SCALER_OLEDCOEF1_G_TO_G_MASK   VC4_MASK(19, 10)
+# define SCALER_OLEDCOEF1_G_TO_G_SHIFT  10
+# define SCALER_OLEDCOEF1_G_TO_B_MASK   VC4_MASK(9, 0)
+# define SCALER_OLEDCOEF1_G_TO_B_SHIFT  0
+
+#define SCALER_OLEDCOEF20x008c
+# define SCALER_OLEDCOEF2_R_TO_R_MASK   VC4_MASK(29, 20)
+# define SCALER_OLEDCOEF2_R_TO_R_SHIFT  20
+# define SCALER_OLEDCOEF2_R_TO_G_MASK   VC4_MASK(19, 10)
+# define SCALER_OLEDCOEF2_R_TO_G_SHIFT  10
+# define SCALER_OLEDCOEF2_R_TO_B_MASK   VC4_MASK(9, 0)
+# define SCALER_OLEDCOEF2_R_TO_B_SHIFT  0
+
+/* Slave addresses for DMAing from HVS composition output to other
+ * devices.  The top bits are valid only in !FIFO32 mode.
+ */
+#define SCALER_DISPSLAVE0   0x00c0
+#define SCALER_DISPSLAVE1   0x00c9
+#define SCALER_DISPSLAVE2   0x00d0
+# define SCALER_DISPSLAVE_ISSUE_VSTART  BIT(31)
+# define SCALER_DISPSLAVE_ISSUE_HSTART  BIT(30)
+/* Set when the current line has been read and an HSTART is required. */
+# define SCALER_DISPSLAVE_EOL   BIT(26)
+/* Set when the display FIFO is empty. */
+# define SCALER_DISPSLAVE_EMPTY BIT(25)
+/* Set when there is RGB data ready to read. */
+# define SCALER_DISPSLAVE_VALID BIT(24)
+# define SCALER_DISPSLAVE_RGB_MASK  VC4_MASK(23, 0)
+# define SCALER_DISPSLAVE_RGB_SHIFT 0
+
 #define SCALER_GAMDATA  0x00e0
 #define SCALER_DLIST_START  0x2000
 #define SCALER_DLIST_SIZE   0x4000
@@ -767,6 +844,10 @@ enum hvs_pixel_format {
  

[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #11 from dwagner  ---
I solved the same problem for me a long time ago by adding a
"drm_kms_helper.edid_firmware=edid/my_monitor_model_edid.bin" option to my
kernel command line, after saving the EDID blob of my monitor to the given
file.

But sure, would be great if such wasn't necessary.

-- 
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] drm/dp: only accept valid DP_TRAINING_AUX_RD_INTERVAL values

[matthew . s . atwood]

From: Matt Atwood 

For panels that do not follow Display Port specifications mask off invalid
values for DP_TRAINING_AUX_RD_INTERVAL. Specification lists acceptable
values 0-4 all other values are reserved and bit 7 of DPCD 0xe
describes another feature. Currently the code uses all of DPCD 0xe and
can cause max wait for 1024 ms instead of 16 ms as specified table 2-158.
This address is read for both clock recovery and channel equalization.

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 4 ++--
 include/drm/drm_dp_helper.h | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..a7e9b75 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -122,7 +122,7 @@ void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay((dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK) * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
@@ -130,7 +130,7 @@ void drm_dp_link_train_channel_eq_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay((dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK) * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..77ba003 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -118,6 +118,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7 /* 1.4 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

[PATCH 1/2] dt-bindings: Document qcom,adreno-gmu

[Jordan Crouse]

Document the device tree bindings for the Adreno GMU device
available on Adreno a6xx targets.

Change-Id: I3cfd5fb35ab0045e39905ff12393006e60f1a124
Signed-off-by: Jordan Crouse 
---
 .../devicetree/bindings/display/msm/gmu.txt| 54 ++
 .../devicetree/bindings/display/msm/gpu.txt| 10 +++-
 2 files changed, 62 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
b/Documentation/devicetree/bindings/display/msm/gmu.txt
new file mode 100644
index ..f65bb49fff36
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -0,0 +1,54 @@
+Qualcomm adreno/snapdragon GMU (Graphics management unit)
+
+The GMU is a programmable power controller for the GPU. the CPU controls the
+GMU which in turn handles power controls for the GPU.
+
+Required properties:
+- compatible:
+  * "qcom,adreno-gmu"
+- reg: Physical base address and length of the GMU registers.
+- reg-names: Matching names for the register regions
+  * "gmu"
+  * "gmu_pdc"
+- interrupts: The interrupt signals from the GMU.
+- interrupt-names: Matching names for the interrupts
+  * "hfi"
+  * "gmu"
+- clocks: phandles to the device clocks
+- clock-names: Matching names for the clocks
+   * "gmu"
+   * "cxo"
+   * "axi"
+   * "mnoc"
+- power-domains: should be <_gpucc GPU_CX_GDSC>
+- iommus: phandle to the adreno iommu
+- operating-points-v2: phandle to the OPP operating points
+
+Example:
+
+/ {
+   ...
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>,
+   <0xb20 0x30>;
+   reg-names = "gmu", "gmu_pdc";
+
+   interrupts = ,
+   ;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
+   <_gpucc GPU_CC_CXO_CLK>,
+   <_gcc GCC_DDRSS_GPU_AXI_CLK>,
+   <_gcc GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = <_gpucc GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   i   operating-points-v2 = <_opp_table>;
+   };
+};
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 43fac0fe09bb..0e207498edd3 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -8,12 +8,18 @@ Required properties:
   with the chip-id.
 - reg: Physical base address and length of the controller's registers.
 - interrupts: The interrupt signal from the gpu.
-- clocks: device clocks
+
+Optional properties.
+- clocks: device clocks. Required for a3xx, a4xx and a5xx targets. a6xx and
+  newer with a GMU attached do not have direct clock control from the CPU and
+  do not need to provide clock properties.
   See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: the following clocks can be provided:
   * "core"
   * "iface"
   * "mem_iface"
+- gmu: For a6xx and newer targets a phandle to the GMU device that will
+  control the power for the GPU
 
 Example:
 
-- 
2.16.1

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

[PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU

[Jordan Crouse]

Add the nodes and other bits to describe the Adreno GPU and GMU
devices.

Change-Id: Ibf4dc0ebb0ac03d8b6b8e65747e142c440e70b0a
Signed-off-by: Jordan Crouse 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 120 +++
 1 file changed, 120 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 7b5c16eb63b7..cc6d367ee55e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -312,5 +312,125 @@
status = "disabled";
};
};
+
+   adreno_smmu: arm,smmu-adreno@504 {
+   compatible = "qcom,msm8996-smmu-v2";
+   reg = <0x504 0x1>;
+   #iommu-cells = <1>;
+   #global-interrupts = <2>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   clocks = <_gcc GCC_GPU_MEMNOC_GFX_CLK>,
+<_gcc GCC_GPU_CFG_AHB_CLK>;
+   clock-names = "bus", "iface";
+
+   power-domains = <_gpucc GPU_CX_GDSC>;
+   };
+
+   gpu_opp_table: adreno-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-71000 {
+   opp-hz = /bits/ 64 <71000>;
+   qcom,arc-level = <416>;
+   };
+
+   opp-67500 {
+   opp-hz = /bits/ 64 <67500>;
+   qcom,arc-level = <384>;
+   };
+
+   opp-59600 {
+   opp-hz = /bits/ 64 <59600>;
+   qcom,arc-level = <320>;
+   };
+
+   opp-52000 {
+   opp-hz = /bits/ 64 <52000>;
+   qcom,arc-level = <256>;
+   };
+
+   opp-41400 {
+   opp-hz = /bits/ 64 <41400>;
+   qcom,arc-level = <192>;
+   };
+
+   opp-34200 {
+   opp-hz = /bits/ 64 <34200>;
+   qcom,arc-level = <128>;
+   };
+
+   opp-25700 {
+   opp-hz = /bits/ 64 <25700>;
+   qcom,arc-level = <64>;
+   };
+   };
+
+   gpu@500 {
+   compatible = "qcom,adreno-630.2", "qcom,adreno";
+   #stream-id-cells = <16>;
+
+   reg = <0x500 0x4>;
+   reg-names = "kgsl_3d0_reg_memory";
+
+   /*
+* Look ma, no clocks! The GPU clocks and power are
+* controlled entirely by the GMU
+*/
+
+   interrupts = ;
+   interrupt-names = "kgsl_3d0_irq";
+
+   iommus = <_smmu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   gmu = <>;
+   };
+
+   gmu_opp_table: adreno-gmu-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-4 {
+   opp-hz = /bits/ 64 <4>;
+   qcom,arc-level = <128>;
+   };
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   qcom,arc-level = <48>;
+   };
+   };
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>,
+ <0xb20 0x30>;
+   reg-names = "gmu", "gmu_pdc";
+
+   interrupts = ,
+;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
+<_gpucc GPU_CC_CXO_CLK>,
+<_gcc GCC_DDRSS_GPU_AXI_CLK>,
+<_gcc GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = <_gpucc 

[PATCH 0/2] arm64: dts: Add sdm845 GPU/GMU and SMMU

[Jordan Crouse]

Building on the sdm845 changes from Rajendra and SMMU changes from Vivek this
is an initial stab at the DT nodes for the sdm845 GPU and GMU (graphics
management unit) which is responsible for the direct power control of the GPU
including the companion arm-smmu-v2 compatible SMMU.

Please refer to https://patchwork.freedesktop.org/series/37428/ for the driver
code.

Jordan Crouse (2):
  dt-bindings: Document qcom,adreno-gmu
  arm64: dts: sdm845: Support GPU/GMU

 .../devicetree/bindings/display/msm/gmu.txt|  54 ++
 .../devicetree/bindings/display/msm/gpu.txt|  10 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi   | 120 +
 3 files changed, 182 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

-- 
2.16.1

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

Re: [PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

[Laurent Pinchart]

Hi Enric,

Thank you for the patch.

On Friday, 2 March 2018 19:57:57 EET Enric Balletbo i Serra wrote:
> From: Jeffy Chen 
> 
> We inited connector in attach(), so need a detach() to cleanup.

Do we ? The dw-hdmi driver already sets drm_connector_cleanup() as the 
connector .destroy() handler, and the .destroy() operation is called by the 
DRM core. None of the other bridge drivers call drm_connector_cleanup() 
directly.

> Signed-off-by: Jeffy Chen 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
> Changes in v9: None
> 
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> f9802399cc0d..5626922f95f9 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1985,6 +1985,13 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
> *bridge) return 0;
>  }
> 
> +static void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
> +{
> + struct dw_hdmi *hdmi = bridge->driver_private;
> +
> + drm_connector_cleanup(>connector);
> +}
> +
>  static enum drm_mode_status
>  dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
> const struct drm_display_mode *mode)
> @@ -2041,6 +2048,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge
> *bridge)
> 
>  static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
>   .attach = dw_hdmi_bridge_attach,
> + .detach = dw_hdmi_bridge_detach,
>   .enable = dw_hdmi_bridge_enable,
>   .disable = dw_hdmi_bridge_disable,
>   .mode_set = dw_hdmi_bridge_mode_set,

-- 
Regards,

Laurent Pinchart

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

[PATCH 2/3] drm/msm: Add generated headers for A6XX

[Jordan Crouse]

From: Sharat Masetty 

Add initial register headers for A6XX targets.

Change-Id: If7b37634aed55c8e05ac26465d628205b6130f09
Signed-off-by: Sharat Masetty 
Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1600 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h |  382 +++
 2 files changed, 1982 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h

diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
new file mode 100644
index ..17d12414f347
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -0,0 +1,1600 @@
+#ifndef A6XX_XML
+#define A6XX_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://github.com/freedreno/envytools/
+git clone https://github.com/freedreno/envytools.git
+
+The rules-ng-ng source files this header was generated from are:
+- /local3/projects/drm/envytools/rnndb//adreno.xml   (501 
bytes, from 2017-11-20 17:36:01)
+- /local3/projects/drm/envytools/rnndb//freedreno_copyright.xml  (   1572 
bytes, from 2016-10-24 21:12:27)
+- /local3/projects/drm/envytools/rnndb//adreno/a2xx.xml  (  32901 
bytes, from 2016-10-24 21:12:27)
+- /local3/projects/drm/envytools/rnndb//adreno/adreno_common.xml (  11792 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/adreno_pm4.xml(  17205 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a3xx.xml  (  83693 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a4xx.xml  ( 110372 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a5xx.xml  (  66793 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a6xx.xml  (  44551 
bytes, from 2017-11-20 19:30:19)
+- /local3/projects/drm/envytools/rnndb//adreno/a6xx_gmu.xml  (  10431 
bytes, from 2017-11-20 17:59:44)
+- /local3/projects/drm/envytools/rnndb//adreno/ocmem.xml (   1773 
bytes, from 2016-10-24 21:12:27)
+
+Copyright (C) 2013-2017 by the following authors:
+- Rob Clark  (robclark)
+- Ilia Mirkin  (imirkin)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+enum a6xx_cp_perfcounter_select {
+   PERF_CP_ALWAYS_COUNT = 0,
+};
+
+enum a6xx_event_write {
+   PC_CCU_INVALIDATE_DEPTH = 24,
+   PC_CCU_INVALIDATE_COLOR = 25,
+};
+
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPU_IDLE 0x0001
+#define A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR  0x0002
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW   0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPC_ERROR0x0080
+#define A6XX_RBBM_INT_0_MASK_CP_SW 0x0100
+#define A6XX_RBBM_INT_0_MASK_CP_HW_ERROR   0x0200
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_DEPTH_TS 0x0400
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_COLOR_TS 0x0800
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_RESOLVE_TS 0x1000
+#define A6XX_RBBM_INT_0_MASK_CP_IB20x2000
+#define A6XX_RBBM_INT_0_MASK_CP_IB10x4000
+#define A6XX_RBBM_INT_0_MASK_CP_RB 0x8000
+#define A6XX_RBBM_INT_0_MASK_CP_RB_DONE_TS 0x0002
+#define A6XX_RBBM_INT_0_MASK_CP_WT_DONE_TS 0x0004
+#define A6XX_RBBM_INT_0_MASK_CP_CACHE_FLUSH_TS 0x0010
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_BUS_OVERFLOW 0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_HANG_DETECT 

[PATCH 3/3] drm/msm: Add A6XX device support

[Jordan Crouse]

Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself.  Add support for the
A6XX core code, the GMU and the HFI (hardware firmware interface)
queue that the CPU uses to communicate with the GMU.

Change-Id: Icb2b80fa0d3bf4bdb0b82e9807360c19cb45dae6
Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Makefile   |3 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 1226 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  162 
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  809 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   60 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  |  435 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  127 +++
 drivers/gpu/drm/msm/adreno/adreno_device.c |   12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +-
 drivers/gpu/drm/msm/msm_gpu.c  |2 +-
 11 files changed, 2840 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index cd40c050b2d7..4affc665c0de 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -10,6 +10,9 @@ msm-y := \
adreno/a5xx_gpu.o \
adreno/a5xx_power.o \
adreno/a5xx_preempt.o \
+   adreno/a6xx_gpu.o \
+   adreno/a6xx_gmu.o \
+   adreno/a6xx_hfi.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
new file mode 100644
index ..3d0a46c49526
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -0,0 +1,1226 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "a6xx_gpu.h"
+#include "a6xx_gmu.xml.h"
+
+static irqreturn_t a6xx_gmu_irq(int irq, void *data)
+{
+   struct a6xx_gmu *gmu = data;
+   u32 status;
+
+   status = gmu_read(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_STATUS);
+   gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, status);
+
+   if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_WDOG_BITE) {
+   dev_err_ratelimited(gmu->dev, "GMU watchdog expired\n");
+
+   /* Temporary until we can recover safely */
+   BUG();
+   }
+
+   if (status &  A6XX_GMU_AO_HOST_INTERRUPT_STATUS_HOST_AHB_BUS_ERROR)
+   dev_err_ratelimited(gmu->dev, "GMU AHB bus error\n");
+
+   if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_FENCE_ERR)
+   dev_err_ratelimited(gmu->dev, "GMU fence error: 0x%x\n",
+   gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS));
+
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t a6xx_hfi_irq(int irq, void *data)
+{
+   struct a6xx_gmu *gmu = data;
+   u32 status;
+
+   status = gmu_read(gmu, REG_A6XX_GMU_GMU2HOST_INTR_INFO);
+   gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_CLR, status);
+
+   if (status & A6XX_GMU_GMU2HOST_INTR_INFO_MSGQ)
+   tasklet_schedule(>hfi_tasklet);
+
+   if (status & A6XX_GMU_GMU2HOST_INTR_INFO_CM3_FAULT) {
+   dev_err_ratelimited(gmu->dev, "GMU firmware fault\n");
+
+   /* Temporary until we can recover safely */
+   BUG();
+   }
+
+   return IRQ_HANDLED;
+}
+
+/* Check to see if the GX rail is still powered */
+static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
+{
+   u32 val  = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
+
+   return !(val &
+   (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF |
+   A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
+}
+
+#define GX_OFF_MASK \
+   (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF | \
+A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF)
+
+static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
+{
+   u32 val;
+   int local = gmu->idle_level;
+
+   /* SPTP and IFPC both report as IFPC */
+   if (gmu->idle_level == GMU_IDLE_STATE_SPTP)
+   local = GMU_IDLE_STATE_IFPC;
+
+   val = gmu_read(gmu, REG_A6XX_GPU_GMU_CX_GMU_RPMH_POWER_STATE);
+
+   if (val == local) {
+   if (gmu->idle_level != GMU_IDLE_STATE_IFPC ||
+   !a6xx_gmu_gx_is_on(gmu))
+   return true;
+   }
+
+   return false;

[v3 PATCH 0/3] Add support for Adreno a6xx

[Jordan Crouse]

a6xx GPU support for drm/msm - follow along here:
https://patchwork.freedesktop.org/series/37428/

Per suggestions from various folks for the associated device tree changes for
the sdm845 GPU (coming immediately after this) add a new opp function to query
the device tree node for a specific opp so that we can parse out platform
specific properties. For the GPU/GMU the device specific property is
qcom,arc-level which is a lookup value for the cmd-db table. Thanks Stephen
Boyd for the suggestion.

[v3: Add dev_pm_opp_np() and use it to get the per-opp rpmh index. Change the
reg-names and interrupt-names to reflect current standards without the "reg" or
"irq" suffix.  Fix additional bugs in the code that constructs the rpmh votes
for the GMU]

[v2: Addressed comments from Lucas Stach, added pm_runtime_get_supplier calls
for accesses to the GMU IOMMU, moved to SPDX headers for the new files]

Jordan Crouse (2):
  PM / OPP: Add dev_pm_opp_get_np()
  drm/msm: Add A6XX device support

Sharat Masetty (1):
  drm/msm: Add generated headers for A6XX

 drivers/gpu/drm/msm/Makefile   |3 +
 drivers/gpu/drm/msm/adreno/a6xx.xml.h  | 1600 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 1226 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  162 +++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h  |  382 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  809 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   60 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  |  435 
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  127 +++
 drivers/gpu/drm/msm/adreno/adreno_device.c |   12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +-
 drivers/gpu/drm/msm/msm_gpu.c  |2 +-
 drivers/opp/of.c   |   20 +
 include/linux/pm_opp.h |6 +
 15 files changed, 4848 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h

-- 
2.16.1

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

[PATCH 1/3] PM / OPP: Add dev_pm_opp_get_np()

[Jordan Crouse]

Add a function to return the device node associated with a
specific opp which will facilitate detailing with custom
properties in client drivers.

Signed-off-by: Jordan Crouse 
---
 drivers/opp/of.c   | 20 
 include/linux/pm_opp.h |  6 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index cb716aa2f44b..5695e7c1d091 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -235,6 +235,26 @@ static int opp_parse_supplies(struct dev_pm_opp *opp, 
struct device *dev,
return ret;
 }
 
+/**
+ * dev_pm_opp_get_np() - Get the device tree node corresponding to an opp
+ * @opp:   opp for which the node should be returned for
+ *
+ * If applicable return the device tree node for the corresponding opp so that
+ * the client can decode "custom" target specific properties.
+ *
+ * Return: A pointer to the device tree or NULL if it doesn't exist
+ */
+struct device_node *dev_pm_opp_get_np(struct dev_pm_opp *opp)
+{
+   if (IS_ERR_OR_NULL(opp)) {
+   pr_err("%s: Invalid parameters\n", __func__);
+   return NULL;
+   }
+
+   return opp->np;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_np);
+
 /**
  * dev_pm_opp_of_remove_table() - Free OPP table entries created from static DT
  *   entries
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 6c2d2e88f066..a38423137db2 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -308,6 +308,7 @@ int dev_pm_opp_of_cpumask_add_table(const struct cpumask 
*cpumask);
 void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask);
 int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask 
*cpumask);
 struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
+struct device_node *dev_pm_opp_get_np(struct dev_pm_opp *opp);
 #else
 static inline int dev_pm_opp_of_add_table(struct device *dev)
 {
@@ -336,6 +337,11 @@ static inline struct device_node 
*dev_pm_opp_of_get_opp_desc_node(struct device
 {
return NULL;
 }
+
+static inline struct device_node *dev_pm_opp_get_np(struct dev_pm_opp *opp)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __LINUX_OPP_H__ */
-- 
2.16.1

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

[Bug 104193] [radeonsi] The Witcher 3 freezes the system with no attachments calls & transform feedback Wine patch

[bugzilla-daemon]

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

--- Comment #5 from Shmerl  ---
Starting from Wine 3.3, the patch for invisible monsters that's causing the
freeze is in Wine source, so you can test regular stock Wine from 3.3 and newer
to narrow down the freeze using the attached save above.

I still get the freeze with the following:

OS: Debian testing x86_64 (kernel 4.15.4).
OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.23.0
/ 4.15.4-rcu, LLVM 5.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel
(git-51562ea7a0)

Proposed workaround MESA_EXTENSION_OVERRIDE=-GL_ARB_framebuffer_no_attachments
prevents the freeze, but also avoids fixing the actual bug with invisible
monsters.

-- 
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: [PULL] drm-misc-next

[Sean Paul]

On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul  wrote:
>
> Hi Dave,
> Here's this weeks pull, relatively small when you pull out the trivial fixes.
>
> drm-misc-next-2018-02-28:
> drm-misc-next for 4.17:
>
> UAPI Changes:
>  Fix drm_color_ctm matrix docs to match usage and change the type to
>  __u64 make it obvious (Ville)

Hi Dave,
Could you please hold off on pulling this? I'd like to sort out this
change a bit more. We're already using the __s64 in chrome, and not
explicitly sign-magnitude. I think it would be prudent to hash this
out a little more.

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?l=161

Sean

>
> Core Changes:
>  Check modifier with format when checking if a plane state is supported 
> (Ville)
>
> Driver Changes:
>  sun4i: Improve hw plane utilization (Maxime)
>  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>  virtio: Whitespace + checkpatch changes (Rodrigo)
>
> Cc: Maxime Ripard 
> Cc: Oleksandr Andrushchenko 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Siqueira 
>
> Cheers, Sean
>
>
> The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:
>
>   drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-28
>
> for you to fetch changes up to 7628166d5e2883e4cdd142b99863d29d411a81b2:
>
>   tinydrm: add backlight dependency (2018-02-28 15:08:56 -0500)
>
> 
> drm-misc-next for 4.17:
>
> UAPI Changes:
>  Fix drm_color_ctm matrix docs to match usage and change the type to
>  __u64 make it obvious (Ville)
>
> Core Changes:
>  Check modifier with format when checking if a plane state is supported 
> (Ville)
>
> Driver Changes:
>  sun4i: Improve hw plane utilization (Maxime)
>  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>  virtio: Whitespace + checkpatch changes (Rodrigo)
>
> Cc: Maxime Ripard 
> Cc: Oleksandr Andrushchenko 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Siqueira 
>
> 
> Arnd Bergmann (2):
>   drm: fix drm_get_max_iomem type mismatch
>   tinydrm: add backlight dependency
>
> Benjamin Gaignard (1):
>   drm/stm: check pitch and size calculations even if !CONFIG_MMU
>
> Chris Wilson (1):
>   drm/mm: Fix caching of leftmost node in the interval tree
>
> Linus Walleij (1):
>   drm/panel: Fix ARM Versatile panel clocks
>
> Maxime Ripard (4):
>   drm/sun4i: backend: Assign the pipes automatically
>   drm/sun4i: Remove the plane description structure
>   drm/sun4i: backend: Make zpos configurable
>   drm/sun4i: backend: Remove ARGB spoofing
>
> Oleksandr Andrushchenko (5):
>   drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC
>   drm/simple_kms_helper: Add {enable|disable}_vblank callback support
>   drm/mxsfb: Do not use deprecated drm_driver.{enable|disable)_vblank
>   drm/tve200: Do not use deprecated drm_driver.{enable|disable)_vblank
>   drm/pl111: Do not use deprecated drm_driver.{enable|disable)_vblank
>
> Rodrigo Siqueira (7):
>   drm/virtio: Add tabs at the start of a line
>   drm/virtio: Add blank line after variable declarations
>   drm/virtio: Add */ in block comments to separate line
>   drm/virtio: Remove return from void function
>   drm/virtio: Replace 'unsigned' for 'unsigned int'
>   drm/virtio: Remove multiple blank lines
>   drm/virtio: Add spaces around operators
>
> Thierry Reding (1):
>   drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC
>
> Ville Syrjälä (4):
>   drm: Check that the plane supports the request format+modifier combo
>   drm/i915: Remove the pipe/plane ID checks from 
> skl_check_ccs_aux_surface()
>   drm: Include the header with the prototype for 
> drm_get_panel_orientation_quirk()
>   drm/uapi: The ctm matrix uses sign-magnitude representation
>
>  drivers/gpu/drm/drm_atomic.c   | 10 +++--
>  drivers/gpu/drm/drm_crtc.c | 10 +++--
>  drivers/gpu/drm/drm_crtc_internal.h|  4 +-
>  drivers/gpu/drm/drm_memory.c   |  2 +-
>  drivers/gpu/drm/drm_mm.c   |  9 +++--
>  drivers/gpu/drm/drm_panel_orientation_quirks.c |  1 +
>  drivers/gpu/drm/drm_plane.c| 33 
>  drivers/gpu/drm/drm_simple_kms_helper.c| 34 
>  drivers/gpu/drm/i915/intel_display.c   |  8 
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 54 +
>  drivers/gpu/drm/panel/panel-arm-versatile.c|  

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #28 from Dennis Schridde  ---
Linux kernel is at 4.15.7-gentoo-r1, LLVM at 5.0.1, Mesa at 18.0.0_rc4.

-- 
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 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

Dennis Schridde  changed:

   What|Removed |Added

 CC||devuran...@gmx.net

--- Comment #27 from Dennis Schridde  ---
I run into this issue regularly with an AMD Ryzen 5 2400G (primary display,
connected via DP to the monitor) and an AMD Radeon RX 560 (not connected to a
monitor, secondary display according to mainboard firmware configuration).

After using my computer for some time, the graphics suddenly freezes and I see
lines like the following in dmesg (after logging in via SSH):

[Fri Mar  2 21:05:33 2018] amdgpu: [powerplay] pp_dpm_get_temperature was not
implemented.
[Fri Mar  2 21:06:03 2018] INFO: task X:898 blocked for more than 120 seconds.  
[Fri Mar  2 21:06:03 2018]   Tainted: GW4.15.7-gentoo-r1 #2 
[Fri Mar  2 21:06:03 2018] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.  
[Fri Mar  2 21:06:03 2018] X   D0   898881 0x0004   
[Fri Mar  2 21:06:03 2018] Call Trace:  
[Fri Mar  2 21:06:03 2018]  ? __schedule+0x2a7/0x8b0
[Fri Mar  2 21:06:03 2018]  schedule+0x28/0x80
[Fri Mar  2 21:06:03 2018]  schedule_preempt_disabled+0xa/0x10
[Fri Mar  2 21:06:03 2018]  __ww_mutex_lock.isra.3+0x224/0x690
[Fri Mar  2 21:06:03 2018]  ? drm_modeset_backoff+0x3e/0xb0 [drm]
[Fri Mar  2 21:06:03 2018]  drm_modeset_backoff+0x3e/0xb0 [drm]
[Fri Mar  2 21:06:03 2018]  drm_mode_gamma_set_ioctl+0xb4/0x200 [drm]
[Fri Mar  2 21:06:03 2018]  ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm]
[Fri Mar  2 21:06:03 2018]  drm_ioctl_kernel+0x5b/0xb0 [drm]
[Fri Mar  2 21:06:03 2018]  drm_ioctl+0x2d5/0x370 [drm]
[Fri Mar  2 21:06:03 2018]  ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm]
[Fri Mar  2 21:06:03 2018]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[Fri Mar  2 21:06:03 2018]  do_vfs_ioctl+0xa4/0x670
[Fri Mar  2 21:06:03 2018]  ? __sys_recvmsg+0x64/0xa0
[Fri Mar  2 21:06:03 2018]  ? __sys_recvmsg+0x95/0xa0
[Fri Mar  2 21:06:03 2018]  SyS_ioctl+0x74/0x80
[Fri Mar  2 21:06:03 2018]  do_syscall_64+0x6e/0x120
[Fri Mar  2 21:06:03 2018]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[Fri Mar  2 21:06:03 2018] RIP: 0033:0x7fd8924c0467
[Fri Mar  2 21:06:03 2018] RSP: 002b:7ffcb17d7b08 EFLAGS: 0246
ORIG_RAX: 0010
[Fri Mar  2 21:06:03 2018] RAX: ffda RBX: 560ddb4480e0 RCX:
7fd8924c0467
[Fri Mar  2 21:06:03 2018] RDX: 7ffcb17d7b40 RSI: c02064a5 RDI:
0016
[Fri Mar  2 21:06:03 2018] RBP: 7ffcb17d7b40 R08: 560ddb4487a0 R09:
560ddb4489a0
[Fri Mar  2 21:06:03 2018] R10: 0001 R11: 0246 R12:
c02064a5
[Fri Mar  2 21:06:03 2018] R13: 0016 R14: 560ddb448bb0 R15:
560ddb4485a0
[Fri Mar  2 21:06:03 2018] INFO: task kworker/u32:2:32344 blocked for more than
120 seconds.
[Fri Mar  2 21:06:03 2018]   Tainted: GW4.15.7-gentoo-r1 #2
[Fri Mar  2 21:06:03 2018] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[Fri Mar  2 21:06:03 2018] kworker/u32:2   D0 32344  2 0x8000
[Fri Mar  2 21:06:03 2018] Workqueue: events_unbound commit_work
[drm_kms_helper]
[Fri Mar  2 21:06:03 2018] Call Trace:
[Fri Mar  2 21:06:03 2018]  ? __schedule+0x2a7/0x8b0
[Fri Mar  2 21:06:03 2018]  schedule+0x28/0x80
[Fri Mar  2 21:06:03 2018]  schedule_timeout+0x1e7/0x370
[Fri Mar  2 21:06:03 2018]  ? generic_reg_get+0x21/0x30 [amdgpu]
[Fri Mar  2 21:06:03 2018]  dma_fence_default_wait+0x1f0/0x280
[Fri Mar  2 21:06:03 2018]  ? dma_fence_release+0x90/0x90
[Fri Mar  2 21:06:03 2018]  dma_fence_wait_timeout+0x39/0xf0
[Fri Mar  2 21:06:03 2018]  reservation_object_wait_timeout_rcu+0x17b/0x370
[Fri Mar  2 21:06:03 2018]  amdgpu_dm_do_flip+0x11f/0x360 [amdgpu]
[Fri Mar  2 21:06:03 2018]  amdgpu_dm_atomic_commit_tail+0x8a1/0x9a0 [amdgpu]
[Fri Mar  2 21:06:03 2018]  ? _cond_resched+0x15/0x40
[Fri Mar  2 21:06:03 2018]  ? wait_for_completion_timeout+0x35/0x180
[Fri Mar  2 21:06:03 2018]  commit_tail+0x3d/0x70 [drm_kms_helper]
[Fri Mar  2 21:06:03 2018]  process_one_work+0x1da/0x3d0
[Fri Mar  2 21:06:03 2018]  worker_thread+0x2b/0x3f0
[Fri Mar  2 21:06:03 2018]  ? process_one_work+0x3d0/0x3d0
[Fri Mar  2 21:06:03 2018]  kthread+0x113/0x130
[Fri Mar  2 21:06:03 2018]  ? kthread_create_worker_on_cpu+0x70/0x70
[Fri Mar  2 21:06:03 2018]  ? SyS_exit_group+0x10/0x10
[Fri Mar  2 21:06:03 2018]  ret_from_fork+0x22/0x40
[Fri Mar  2 21:06:33 2018] i2c /dev entries driver

Everything apart from the graphics appears to continue to run fine, except any
application (e.g. started on the command line) that tries to talk to the X
server: They will hang.  Most 

Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Rob Herring]

On Fri, Mar 2, 2018 at 7:48 AM, Benoit Parrot  wrote:
> Add 'plane' child node to generic DISPC node as an optional
> property.

Why? What problem are you solving?

>
> Signed-off-by: Benoit Parrot 
> ---
>  .../devicetree/bindings/display/ti/ti,omap-dss.txt | 63 
> ++
>  1 file changed, 63 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt 
> b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
> index 249e588d7865..cb101525b805 100644
> --- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
> +++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
> @@ -27,6 +27,34 @@ DISPC
>  Optional properties:
>  - max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
> limit
> in bytes per second
> +- plane: Child node(s) which defines which logical plane are available to

This is the "Optional properties" section and plane is not a property.

> +   the system. If at least one plane child node is defined then
> +   only planes defined by these nodes will be available to the system.
> +   Plane nodes must be sequential starting with reg = <0> as DT parsing
> +   will stop on the first missing numbered node.
> +   This means if plane #1 is defined but plane #0 is not then it will
> +   be as if none of the plane nodes were defined.
> +
> +   Each plane node contains the following properties:
> +   Required properties:
> +   - reg:   Used to number the logical plane

Is logical plane a h/w concept?

> +   - hw-planes: One or two HW plane number(s).
> +When 2 numbers are present this indicates a virtual plane
> +composed of two physical planes intended to be used
> +when the display is larger then the capacity of a
> +single plane i.e. wider than 2048 pixels.
> +The first number in the pair will dictate the 
> capabilities
> +of the virtual plane. This means that for proper
> +operation the virtual plane should be composed of HW
> +planes of the same capabilities.
> +If GFX plane is used in a virtual plane it should be
> +specified first, otherwise unexpected behavior would
> +be encountered.
> +   Optional property:
> +   - hw-crtcs:  One or more HW crtc number(s).
> +Describe the list of CRTCs on which this plane is
> +available. If this node is not present then the
> +plane will be available on all available CRTCs.

Let's not copy archaic terms from DRM into bindings.

Really, I'm skeptical that any of this belongs in DT. For example,
can't you figure out you need 2 physical planes whenever your
panel/timing width is greater than 2048?

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

Re: [PATCH v2 05/10] video: add MIPI DSI host controller bridge

[Brian Norris]

On Fri, Mar 02, 2018 at 10:57:59AM -0800, Brian Norris wrote:
> Hi,
> 
> On Fri, Mar 02, 2018 at 04:44:06PM +0100, yannick fertre wrote:
> > Add a Synopsys Designware MIPI DSI host bridge driver, based on the
> > Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
> 
> How many times are we going to allow copy-and-pasting the same driver?
> Last time we wanted to modify the Rockchip driver, we were told
> "consolidate", because ST had already forked our driver. This nearly
> halted all progress. I'm going to be real disappointed if we see another
> fork get merged.
> 
> (IOW, I would say "over my dead body," but I have no power here.)
> 
> And why can't you use DRM?

...wait a second...this looks like it's a u-boot driver. There's a
surprising amount of similarity between U-boot and Linux drivers (no
coincidence I'm sure), including  headers.

Since when do U-Boot patches go to LKML and dri-devel?

Anyway, I'll try my best to ignore this series.

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

Re: [PATCH v2 05/10] video: add MIPI DSI host controller bridge

[Brian Norris]

Hi,

On Fri, Mar 02, 2018 at 04:44:06PM +0100, yannick fertre wrote:
> Add a Synopsys Designware MIPI DSI host bridge driver, based on the
> Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.

How many times are we going to allow copy-and-pasting the same driver?
Last time we wanted to modify the Rockchip driver, we were told
"consolidate", because ST had already forked our driver. This nearly
halted all progress. I'm going to be real disappointed if we see another
fork get merged.

(IOW, I would say "over my dead body," but I have no power here.)

And why can't you use DRM?

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

Re: [PATCH libdrm] omap: add Android build support

[Emil Velikov]

On 28 February 2018 at 18:54, Andrew F. Davis  wrote:
> From: Gowtham Tammana 
>
> Add Android.mk file to build libdrm_omap library.
>
Zero objections on my end, but can we have the use case mentioned in
the commit message.
Years ago I was looking for users of the library and I could not find any.

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

Re: [PATCH 02/14] iommu/arm-smmu: Add support for TTBR1

[Jordan Crouse]

On Fri, Mar 02, 2018 at 05:57:21PM +, Robin Murphy wrote:
> On 21/02/18 22:59, Jordan Crouse wrote:
> >Allow a SMMU device to opt into allocating a TTBR1 pagetable.
> >
> >The size of the TTBR1 region will be the same as
> >the TTBR0 size with the sign extension bit set on the highest
> >bit in the region unless the upstream size is 49 bits and then
> >the sign-extension bit will be set on the 49th bit.
> 
> Um, isn't the 49th bit still "the highest bit" if the address size
> is 49 bits? ;)

Indeed. :)

> >The map/unmap operations will automatically use the appropriate
> >pagetable based on the specified iova and the existing mask.
> >
> >Signed-off-by: Jordan Crouse 
> >---
> >  drivers/iommu/arm-smmu-regs.h  |   2 -
> >  drivers/iommu/arm-smmu.c   |  22 --
> >  drivers/iommu/io-pgtable-arm.c | 160 
> > -
> >  drivers/iommu/io-pgtable-arm.h |  20 ++
> >  drivers/iommu/io-pgtable.h |  16 -
> >  5 files changed, 192 insertions(+), 28 deletions(-)
> >
> >diff --git a/drivers/iommu/arm-smmu-regs.h b/drivers/iommu/arm-smmu-regs.h
> >index a1226e4ab5f8..0ce85d5b22e9 100644
> >--- a/drivers/iommu/arm-smmu-regs.h
> >+++ b/drivers/iommu/arm-smmu-regs.h
> >@@ -193,8 +193,6 @@ enum arm_smmu_s2cr_privcfg {
> >  #define RESUME_RETRY   (0 << 0)
> >  #define RESUME_TERMINATE   (1 << 0)
> >-#define TTBCR2_SEP_SHIFT15
> >-#define TTBCR2_SEP_UPSTREAM (0x7 << TTBCR2_SEP_SHIFT)
> >  #define TTBCR2_AS  (1 << 4)
> >  #define TTBRn_ASID_SHIFT   48
> >diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >index 69e7c60792a8..ebfa59b59622 100644
> >--- a/drivers/iommu/arm-smmu.c
> >+++ b/drivers/iommu/arm-smmu.c
> >@@ -248,6 +248,7 @@ struct arm_smmu_domain {
> > enum arm_smmu_domain_stage  stage;
> > struct mutexinit_mutex; /* Protects smmu pointer */
> > spinlock_t  cb_lock; /* Serialises ATS1* ops and 
> > TLB syncs */
> >+u32 attributes;
> > struct iommu_domain domain;
> >  };
> >@@ -598,7 +599,6 @@ static void arm_smmu_init_context_bank(struct 
> >arm_smmu_domain *smmu_domain,
> > } else {
> > cb->tcr[0] = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
> > cb->tcr[1] = pgtbl_cfg->arm_lpae_s1_cfg.tcr >> 32;
> >-cb->tcr[1] |= TTBCR2_SEP_UPSTREAM;
> > if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64)
> > cb->tcr[1] |= TTBCR2_AS;
> > }
> >@@ -729,6 +729,9 @@ static int arm_smmu_init_domain_context(struct 
> >iommu_domain *domain,
> > enum io_pgtable_fmt fmt;
> > struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> > struct arm_smmu_cfg *cfg = _domain->cfg;
> >+unsigned int quirks =
> >+smmu_domain->attributes & (1 << DOMAIN_ATTR_ENABLE_TTBR1) ?
> >+IO_PGTABLE_QUIRK_ARM_TTBR1 : 0;
> > mutex_lock(_domain->init_mutex);
> > if (smmu_domain->smmu)
> >@@ -852,7 +855,11 @@ static int arm_smmu_init_domain_context(struct 
> >iommu_domain *domain,
> > else
> > cfg->asid = cfg->cbndx + smmu->cavium_id_base;
> >+if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
> >+quirks |= IO_PGTABLE_QUIRK_NO_DMA;
> >+
> > pgtbl_cfg = (struct io_pgtable_cfg) {
> >+.quirks = quirks,
> > .pgsize_bitmap  = smmu->pgsize_bitmap,
> > .ias= ias,
> > .oas= oas,
> >@@ -860,9 +867,6 @@ static int arm_smmu_init_domain_context(struct 
> >iommu_domain *domain,
> > .iommu_dev  = smmu->dev,
> > };
> >-if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
> >-pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_NO_DMA;
> >-
> > smmu_domain->smmu = smmu;
> > pgtbl_ops = alloc_io_pgtable_ops(fmt, _cfg, smmu_domain);
> > if (!pgtbl_ops) {
> >@@ -1477,6 +1481,10 @@ static int arm_smmu_domain_get_attr(struct 
> >iommu_domain *domain,
> > case DOMAIN_ATTR_NESTING:
> > *(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
> > return 0;
> >+case DOMAIN_ATTR_ENABLE_TTBR1:
> >+*((int *)data) = !!(smmu_domain->attributes
> >+& (1 << DOMAIN_ATTR_ENABLE_TTBR1));
> >+return 0;
> > default:
> > return -ENODEV;
> > }
> >@@ -1505,6 +1513,12 @@ static int arm_smmu_domain_set_attr(struct 
> >iommu_domain *domain,
> > else
> > smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
> >+break;
> >+case DOMAIN_ATTR_ENABLE_TTBR1:
> >+if (*((int *)data))
> >+smmu_domain->attributes |=
> >+1 << DOMAIN_ATTR_ENABLE_TTBR1;
> >+ret = 0;
> > break;
> > default:
> > ret = -ENODEV;
> >diff --git 

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Ville Syrjälä]

On Fri, Mar 02, 2018 at 09:13:14AM -0800, Eric Anholt wrote:
> Ville Syrjälä  writes:
> 
> > On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote:
> >> Hey Ville,
> >> 
> >> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä
> >>  wrote:
> >> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote:
> >> >> If you want the plane to always be opaque you shouldn't expose any
> >> >> formats with alpha.
> >> >>
> >> >> Also what happens if one disables the primary plane? Or does the driver
> >> >> not allow that?
> >> >
> >> > Or just makes the plane not cover the entire screen?
> >> 
> >> We've exposed alpha formats in the past so disabling that now would break
> >> userspace, certainly Android that chooses alpha-everything.
> >
> > So it refuses to even run on hardware that can't do per-pixel alpha on
> > the primary plane?
> >
> >> The VC4 HVS
> >> has no fixed planes so I'll acknowledge that the concept of a primary plane
> >> is somewhat dubious and userspace could disable it or make it not cover the
> >> entire screen, making this ineffective.
> >> 
> >> But then ultimately there doesn't seem to be a standard for what the 
> >> display
> >> is supposed to be if you have transparent pixels with no plane to blend to
> >> below.
> >
> > The standard is black. IMO it's a driver bug if it fails to do that.
> 
> If the plane is premultiplied (isn't that what DRM planes are supposed
> to be?  I can't find any docs),

Yeah I think pre-multiplied is what was agreed on because that was
what everyone's cursor planes were doing already. But I guess we didn't
actually document that anywhere :(

Should we add something like 
+/*
+ * Note that using any format with alpha (A) implies pre-multiplied
+ * alpha blending: Dc = Sc + (1.0 - Sa) * Dc, where Sa is source alpha,
+ * Sc is source color, and Dc is destination color.
+ */
to drm_fourcc.h perhaps?

Not sure if that's the best place, nor am I sure the wording is good
enough. Opinions welcome.

igt could really use some alpha blending tests as well...

> then blending against black is the same
> as not doing any blending at all.

Ah, yes indeeed. Hmm. And with my i915 hat on that actually means that we
should in theory be able to expose alpha formats on i915 primary planes
because there can never be anything but black underneath them on account
of the fixed zorder. But we can't make that promise for the sprite planes,
so probably not worth the hassle for primary planes either. Sufficiently
smart userspace should be able figure this fact out on its own I
suppose.

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

Re: [PATCH 02/14] iommu/arm-smmu: Add support for TTBR1

[Robin Murphy]

On 21/02/18 22:59, Jordan Crouse wrote:

Allow a SMMU device to opt into allocating a TTBR1 pagetable.

The size of the TTBR1 region will be the same as
the TTBR0 size with the sign extension bit set on the highest
bit in the region unless the upstream size is 49 bits and then
the sign-extension bit will be set on the 49th bit.


Um, isn't the 49th bit still "the highest bit" if the address size is 49 
bits? ;)



The map/unmap operations will automatically use the appropriate
pagetable based on the specified iova and the existing mask.

Signed-off-by: Jordan Crouse 
---
  drivers/iommu/arm-smmu-regs.h  |   2 -
  drivers/iommu/arm-smmu.c   |  22 --
  drivers/iommu/io-pgtable-arm.c | 160 -
  drivers/iommu/io-pgtable-arm.h |  20 ++
  drivers/iommu/io-pgtable.h |  16 -
  5 files changed, 192 insertions(+), 28 deletions(-)

diff --git a/drivers/iommu/arm-smmu-regs.h b/drivers/iommu/arm-smmu-regs.h
index a1226e4ab5f8..0ce85d5b22e9 100644
--- a/drivers/iommu/arm-smmu-regs.h
+++ b/drivers/iommu/arm-smmu-regs.h
@@ -193,8 +193,6 @@ enum arm_smmu_s2cr_privcfg {
  #define RESUME_RETRY  (0 << 0)
  #define RESUME_TERMINATE  (1 << 0)
  
-#define TTBCR2_SEP_SHIFT		15

-#define TTBCR2_SEP_UPSTREAM(0x7 << TTBCR2_SEP_SHIFT)
  #define TTBCR2_AS (1 << 4)
  
  #define TTBRn_ASID_SHIFT		48

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60792a8..ebfa59b59622 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -248,6 +248,7 @@ struct arm_smmu_domain {
enum arm_smmu_domain_stage  stage;
struct mutexinit_mutex; /* Protects smmu pointer */
spinlock_t  cb_lock; /* Serialises ATS1* ops and 
TLB syncs */
+   u32 attributes;
struct iommu_domain domain;
  };
  
@@ -598,7 +599,6 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,

} else {
cb->tcr[0] = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
cb->tcr[1] = pgtbl_cfg->arm_lpae_s1_cfg.tcr >> 32;
-   cb->tcr[1] |= TTBCR2_SEP_UPSTREAM;
if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64)
cb->tcr[1] |= TTBCR2_AS;
}
@@ -729,6 +729,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain 
*domain,
enum io_pgtable_fmt fmt;
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_cfg *cfg = _domain->cfg;
+   unsigned int quirks =
+   smmu_domain->attributes & (1 << DOMAIN_ATTR_ENABLE_TTBR1) ?
+   IO_PGTABLE_QUIRK_ARM_TTBR1 : 0;
  
  	mutex_lock(_domain->init_mutex);

if (smmu_domain->smmu)
@@ -852,7 +855,11 @@ static int arm_smmu_init_domain_context(struct 
iommu_domain *domain,
else
cfg->asid = cfg->cbndx + smmu->cavium_id_base;
  
+	if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)

+   quirks |= IO_PGTABLE_QUIRK_NO_DMA;
+
pgtbl_cfg = (struct io_pgtable_cfg) {
+   .quirks = quirks,
.pgsize_bitmap  = smmu->pgsize_bitmap,
.ias= ias,
.oas= oas,
@@ -860,9 +867,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain 
*domain,
.iommu_dev  = smmu->dev,
};
  
-	if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)

-   pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_NO_DMA;
-
smmu_domain->smmu = smmu;
pgtbl_ops = alloc_io_pgtable_ops(fmt, _cfg, smmu_domain);
if (!pgtbl_ops) {
@@ -1477,6 +1481,10 @@ static int arm_smmu_domain_get_attr(struct iommu_domain 
*domain,
case DOMAIN_ATTR_NESTING:
*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
return 0;
+   case DOMAIN_ATTR_ENABLE_TTBR1:
+   *((int *)data) = !!(smmu_domain->attributes
+   & (1 << DOMAIN_ATTR_ENABLE_TTBR1));
+   return 0;
default:
return -ENODEV;
}
@@ -1505,6 +1513,12 @@ static int arm_smmu_domain_set_attr(struct iommu_domain 
*domain,
else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
  
+		break;

+   case DOMAIN_ATTR_ENABLE_TTBR1:
+   if (*((int *)data))
+   smmu_domain->attributes |=
+   1 << DOMAIN_ATTR_ENABLE_TTBR1;
+   ret = 0;
break;
default:
ret = -ENODEV;
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index fff0b6ba0a69..1bd0045f2cb7 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -152,7 +152,7 @@ struct arm_lpae_io_pgtable {
unsigned long   

[PATCH libdrm 1/1] intel: allocate buffer with the requested size when reuse is disabled

[James Xiong]

From: "Xiong, James" 

Previously a bucket size was used for buffer allocation whether
bo_reuse is false or true. This patch returns NULL in function
drm_intel_gem_bo_bucket_for_size() when bo_reuse is false, the
original requested size is used instead.

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 386da30..43a3f38 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -402,6 +402,9 @@ drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem 
*bufmgr_gem,
 {
int i;
 
+   if (!bufmgr_gem->bo_reuse)
+   return NULL;
+
for (i = 0; i < bufmgr_gem->num_buckets; i++) {
struct drm_intel_gem_bo_bucket *bucket =
_gem->cache_bucket[i];
@@ -1382,7 +1385,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, 
time_t time)
 
bucket = drm_intel_gem_bo_bucket_for_size(bufmgr_gem, bo->size);
/* Put the buffer into our internal cache for reuse if we can. */
-   if (bufmgr_gem->bo_reuse && bo_gem->reusable && bucket != NULL &&
+   if (bo_gem->reusable && bucket != NULL &&
drm_intel_gem_bo_madvise_internal(bufmgr_gem, bo_gem,
  I915_MADV_DONTNEED)) {
bo_gem->free_time = time;
@@ -3806,6 +3809,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
drm_intel_gem_get_pipe_from_crtc_id;
bufmgr_gem->bufmgr.bo_references = drm_intel_gem_bo_references;
 
+   bufmgr_gem->bo_reuse = false; /* explicitly set to false */
init_cache_buckets(bufmgr_gem);
 
DRMINITLISTHEAD(_gem->vma_cache);
-- 
2.7.4

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

[PATCH 1/1] intel: align reuse buffer's size on page size instead

[James Xiong]

From: "Xiong, James" 

With gem_reuse enabled, when a buffer size is different than
the sizes of buckets, it is aligned to the next bucket's size,
which means about 25% more memory than the requested is allocated
in the worst senario. For example:

Orignal sizeActual
32KB+1Byte  40KB
.
.
.
8MB+1Byte   10MB
.
.
.
96MB+1Byte  112MB

This is very memory expensive and make the reuse feature less
favorable than it deserves to be.

This commit aligns the reuse buffer size on page size instead,
the buffer whose size falls between bucket[n] and bucket[n+1] is
put in bucket[n] when it's done; And when searching for a cached
buffer for reuse, it goes through the cached buffers list in the
bucket until a cached buffer, whose size is larger than or equal
to the requested size, is found.

Performed gfxbench tests, the performances and reuse ratioes
(reuse count/allocation count) were same as before, saved memory
usage by 1% ~ 7%(gl_manhattan: peak allocated memory size was
reduced from 448401408 to 419078144).

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 180 +--
 libdrm_lists.h   |   6 ++
 2 files changed, 101 insertions(+), 85 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 386da30..5b2d0d0 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -402,11 +402,10 @@ drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem 
*bufmgr_gem,
 {
int i;
 
-   for (i = 0; i < bufmgr_gem->num_buckets; i++) {
-   struct drm_intel_gem_bo_bucket *bucket =
-   _gem->cache_bucket[i];
-   if (bucket->size >= size) {
-   return bucket;
+   for (i = 0; i < bufmgr_gem->num_buckets - 1; i++) {
+   if (size >= bufmgr_gem->cache_bucket[i].size &&
+   size < bufmgr_gem->cache_bucket[i+1].size) {
+   return _gem->cache_bucket[i];
}
}
 
@@ -685,25 +684,95 @@ drm_intel_gem_bo_madvise(drm_intel_bo *bo, int madv)
 madv);
 }
 
-/* drop the oldest entries that have been purged by the kernel */
+/* drop the entries that are older than the given time */
 static void
 drm_intel_gem_bo_cache_purge_bucket(drm_intel_bufmgr_gem *bufmgr_gem,
-   struct drm_intel_gem_bo_bucket *bucket)
+   struct drm_intel_gem_bo_bucket *bucket,
+   time_t time)
 {
-   while (!DRMLISTEMPTY(>head)) {
-   drm_intel_bo_gem *bo_gem;
-
-   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
- bucket->head.next, head);
-   if (drm_intel_gem_bo_madvise_internal
-   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED))
-   break;
-
-   DRMLISTDEL(_gem->head);
-   drm_intel_gem_bo_free(_gem->bo);
+   drm_intel_bo_gem *bo_gem, *temp;
+   DRMLISTFOREACHENTRYSAFE(bo_gem, temp, >head, head) {
+   if (bo_gem->free_time >= time) {
+   drm_intel_gem_bo_madvise_internal
+   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED);
+   DRMLISTDEL(_gem->head);
+   drm_intel_gem_bo_free(_gem->bo);
+   }
}
 }
 
+static drm_intel_bo_gem *
+drm_intel_gem_bo_cached_for_size(drm_intel_bufmgr_gem *bufmgr_gem,
+ unsigned long size,
+ uint32_t tiling_mode,
+ unsigned long stride,
+ unsigned long alignment,
+ bool for_render)
+{
+   struct drm_intel_gem_bo_bucket *bucket =
+   drm_intel_gem_bo_bucket_for_size(bufmgr_gem, size);
+
+   if(bucket != NULL) {
+   drm_intel_bo_gem *bo_gem, *temp_bo_gem;
+retry:
+   bo_gem = NULL;
+   if (for_render) {
+   /* Allocate new render-target BOs from the tail (MRU)
+* of the list, as it will likely be hot in the GPU
+* cache and in the aperture for us.
+*/
+   DRMLISTFOREACHENTRYREVERSE(temp_bo_gem, >head, 
head) {
+   if (temp_bo_gem->bo.size >= size) {
+   bo_gem = temp_bo_gem;
+   DRMLISTDEL(_gem->head);
+   bo_gem->bo.align = alignment;
+   break;
+   }
+   }
+   } else {
+   assert(alignment == 0);
+   /* For non-render-target BOs (where we're probably
+* going to map it first thing in order to 

[Bug 103953] [DC] Polaris10: Missing modes when enabling DC

[bugzilla-daemon]

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

--- Comment #9 from Marc Cousin  ---
Bug solved for me too with amd-staging-drm-next. Thanks a lot.

-- 
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 04/14] iommu: sva: Add support for pasid allocation

[Jean-Philippe Brucker]

On 21/02/18 22:59, Jordan Crouse wrote:
[...]
> +int iommu_sva_alloc_pasid(struct iommu_domain *domain, struct device *dev)
> +{
> + int ret, pasid;
> + struct io_pasid *io_pasid;
> +
> + if (!domain->ops->pasid_alloc || !domain->ops->pasid_free)
> + return -ENODEV;
> +
> + io_pasid = kzalloc(sizeof(*io_pasid), GFP_KERNEL);
> + if (!io_pasid)
> + return -ENOMEM;
> +
> + io_pasid->domain = domain;
> + io_pasid->base.type = IO_TYPE_PASID;
> +
> + idr_preload(GFP_KERNEL);
> + spin_lock(_sva_lock);
> + pasid = idr_alloc_cyclic(_pasid_idr, _pasid->base,
> + 1, (1 << 31), GFP_ATOMIC);

To be usable by other IOMMUs, this should restrict the PASID range to what
the IOMMU and the device support like io_mm_alloc(). In your case 31 bits,
but with PCI PASID it depends on the PASID capability and the SMMU
SubstreamID range.

For this reason I think device drivers should call iommu_sva_device_init()
once, even for the alloc_pasid() API. For SMMUv2 I guess it will be a NOP,
but other IOMMUs will allocate PASID tables and enable features in the
device. In addition, knowing that all users of the API call
iommu_sva_device_init()/shutdown() could allow us to allocate and enable
stuff lazily in the future.

It would also allow a given device driver to use both
iommu_sva_pasid_alloc() and iommu_sva_bind() at the same time. So that the
driver can assigns contexts to userspace and still use some of them for
management.

[...]
> +int iommu_sva_map(int pasid, unsigned long iova,
> +   phys_addr_t paddr, size_t size, int prot)

It would be nice to factor iommu_map(), since this logic for map, map_sg
and unmap should be the same regardless of the PASID argument.

For example
- iommu_sva_map(domain, pasid, ...)
- iommu_map(domain, ...)

both call
- __iommu_map(domain, pasid, ...)

which calls either
- ops->map(domain, ...)
- ops->sva_map(domain, pasid, ...)

[...]
> @@ -347,6 +353,15 @@ struct iommu_ops {
>   int (*page_response)(struct iommu_domain *domain, struct device *dev,
>struct page_response_msg *msg);
>  
> + int (*pasid_alloc)(struct iommu_domain *domain, struct device *dev,
> + int pasid);
> + int (*sva_map)(struct iommu_domain *domain, int pasid,
> +unsigned long iova, phys_addr_t paddr, size_t size,
> +int prot);
> + size_t (*sva_unmap)(struct iommu_domain *domain, int pasid,
> + unsigned long iova, size_t size);
> + void (*pasid_free)(struct iommu_domain *domain, int pasid);
> +

Hmm, now IOMMU has the following ops:

* mm_alloc(): allocates a shared mm structure
* mm_attach(): writes the entry in the PASID table
* mm_detach(): removes the entry from the PASID table and invalidates it
* mm_free(): free shared mm
* pasid_alloc(): allocates a pasid structure (which I usually call
"private mm") and write the entry in the PASID table (or call
install_pasid() for SMMUv2)
* pasid_free(): remove from the PASID table (or call remove_pasid()) and
free the pasid structure.

Splitting mm_alloc and mm_attach is necessary because the io_mm in my case
can be shared between devices (allocated once, attached multiple times).
In your case a PASID is private to one device so only one callback is
needed. However mm_alloc+mm_attach will do roughly the same as
pasid_alloc, so to reduce redundancy in iommu_ops, maybe we could reuse
mm_alloc and mm_attach for the private PASID case?

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

Re: [PATCH v8 4/8] drm/rockchip: dw-mipi-dsi: Fix error handling path

[Enric Balletbo i Serra]

Hi Heiko,

On 01/03/18 16:50, Heiko Stübner wrote:
> Hi Jeffy, Thierry, Enric,
> 
> Am Mittwoch, 10. Januar 2018, 17:23:44 CET schrieb Thierry Escande:
>> From: Jeffy Chen 
>>
>> Add missing pm_runtime_disable() in bind()'s error handling path.
>>
>> Also cleanup encoder & connector in unbind().
> 
> Can you please split all these surprise "Also" sections into separate
> patches?
> 

I'll take a look.

> It looks like this is true for all following patch to some degree and
> the inno-hdmi patch even has a unbind reordering-change without
> mentioning it in the commit message.
> 

Actually, I think this patch is not correct against current mainline, see below.

> 
> Thanks
> Heiko
> 
>> Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
>> Signed-off-by: Jeffy Chen 
>> Signed-off-by: Thierry Escande 
>> ---
>>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +
>>  1 file changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index b1fe0639227e..78e6b7919bf7
>> 100644
>> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>> @@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
>> device *master, ret = dw_mipi_dsi_register(drm, dsi);
>>  if (ret) {
>>  DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
>> -goto err_pllref;
>> +goto err_disable_pllref;
>>  }
>>
>>  dsi->dsi_host.ops = _mipi_dsi_host_ops;
>> @@ -1290,24 +1290,25 @@ static int dw_mipi_dsi_bind(struct device *dev,
>> struct device *master, ret = mipi_dsi_host_register(>dsi_host);
>>  if (ret) {
>>  DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
>> -goto err_cleanup;
>> +goto err_disable_pm_runtime;
>>  }
>>
>>  if (!dsi->panel) {
>>  ret = -EPROBE_DEFER;
>> -goto err_mipi_dsi_host;
>> +goto err_unreg_mipi_dsi_host;
>>  }
>>
>>  dev_set_drvdata(dev, dsi);
>>  pm_runtime_enable(dev);
>>  return 0;
>>
>> -err_mipi_dsi_host:
>> +err_unreg_mipi_dsi_host:
>>  mipi_dsi_host_unregister(>dsi_host);
>> -err_cleanup:
>> -drm_encoder_cleanup(>encoder);
>> -drm_connector_cleanup(>connector);
>> -err_pllref:
>> +err_disable_pm_runtime:
>> +pm_runtime_disable(dev);

I think that this is not required, 'pm_runtime_enable' is called just before the
'return 0' (see above). Commit 517f56839f58 'drm/rockchip: dw-mipi-dsi: fix
possible un-balanced runtime PM enable' moved the call to that place. So, now
the call to pm_runtime_disable is not needed.

>> +dsi->connector.funcs->destroy(>connector);
>> +dsi->encoder.funcs->destroy(>encoder);

Here, there is a reordering and also a function replacement. The reorder makes
sense to me, first cleanup the connector and then the encoder, but I'm not sure
about the function change and if is needed, anyway, in the case is needed,
shouldn't be

+   drm_connector_cleanup(>connector);
+   drm_encoder_cleanup(>encoder);

instead?

>> +err_disable_pllref:
>>  clk_disable_unprepare(dsi->pllref_clk);
>>  return ret;
>>  }
>> @@ -1319,6 +1320,10 @@ static void dw_mipi_dsi_unbind(struct device *dev,
>> struct device *master,
>>
>>  mipi_dsi_host_unregister(>dsi_host);
>>  pm_runtime_disable(dev);
>> +
>> +dsi->connector.funcs->destroy(>connector);
>> +dsi->encoder.funcs->destroy(>encoder);
>> +

Same here.

>>  clk_disable_unprepare(dsi->pllref_clk);
>>  }
> 
> 

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

Re: [PATCH v8 4/8] drm/rockchip: dw-mipi-dsi: Fix error handling path

[Enric Balletbo i Serra]

Hi Heiko,

On 02/03/18 13:17, Heiko Stuebner wrote:
> Hi Enric,
> 
> Am Freitag, 2. März 2018, 13:09:02 CET schrieb Enric Balletbo i Serra:
>> Hi Heiko,
>>
>> On 01/03/18 16:50, Heiko Stübner wrote:
>>> Hi Jeffy, Thierry, Enric,
>>>
>>> Am Mittwoch, 10. Januar 2018, 17:23:44 CET schrieb Thierry Escande:
 From: Jeffy Chen 

 Add missing pm_runtime_disable() in bind()'s error handling path.

 Also cleanup encoder & connector in unbind().
>>>
>>> Can you please split all these surprise "Also" sections into separate
>>> patches?
>>>
>>
>> I'll take a look.
>>
>>> It looks like this is true for all following patch to some degree and
>>> the inno-hdmi patch even has a unbind reordering-change without
>>> mentioning it in the commit message.
>>>
>>
>> Actually, I think this patch is not correct against current mainline, see 
>> below.
>>
>>>
>>> Thanks
>>> Heiko
>>>
 Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
 Signed-off-by: Jeffy Chen 
 Signed-off-by: Thierry Escande 
 ---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +
  1 file changed, 13 insertions(+), 8 deletions(-)

 diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
 b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index b1fe0639227e..78e6b7919bf7
 100644
 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
 +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
 @@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev, 
 struct
 device *master, ret = dw_mipi_dsi_register(drm, dsi);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
 -  goto err_pllref;
 +  goto err_disable_pllref;
}

dsi->dsi_host.ops = _mipi_dsi_host_ops;
 @@ -1290,24 +1290,25 @@ static int dw_mipi_dsi_bind(struct device *dev,
 struct device *master, ret = mipi_dsi_host_register(>dsi_host);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
 -  goto err_cleanup;
 +  goto err_disable_pm_runtime;
}

if (!dsi->panel) {
ret = -EPROBE_DEFER;
 -  goto err_mipi_dsi_host;
 +  goto err_unreg_mipi_dsi_host;
}

dev_set_drvdata(dev, dsi);
pm_runtime_enable(dev);
return 0;

 -err_mipi_dsi_host:
 +err_unreg_mipi_dsi_host:
mipi_dsi_host_unregister(>dsi_host);
 -err_cleanup:
 -  drm_encoder_cleanup(>encoder);
 -  drm_connector_cleanup(>connector);
 -err_pllref:
 +err_disable_pm_runtime:
 +  pm_runtime_disable(dev);
>>
>> I think that this is not required, 'pm_runtime_enable' is called just before 
>> the
>> 'return 0' (see above). Commit 517f56839f58 'drm/rockchip: dw-mipi-dsi: fix
>> possible un-balanced runtime PM enable' moved the call to that place. So, now
>> the call to pm_runtime_disable is not needed.
>>
 +  dsi->connector.funcs->destroy(>connector);
 +  dsi->encoder.funcs->destroy(>encoder);
>>
>> Here, there is a reordering and also a function replacement. The reorder 
>> makes
>> sense to me, first cleanup the connector and then the encoder, but I'm not 
>> sure
>> about the function change and if is needed, anyway, in the case is needed,
>> shouldn't be
>>
>> +drm_connector_cleanup(>connector);
>> +drm_encoder_cleanup(>encoder);
>>
>> instead?
> 
> If you look at drm/rockchip/dw-mipi-dsi.c you'll see that
> dw_mipi_dsi_drm_connector_destroy() does both connector_unregister()
> and drm_connector_cleanup().
> 
> And looking at other drivers it really seems that calling that destroy
> callback is really the way to go.
> 

Right, thanks for pointing me in the right direction. Learning about this
graphics stuff ;)

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

Re: [PATCH 11/14] drm/msm: Add support for iommu-sva PASIDs

[Jean-Philippe Brucker]

On 21/02/18 22:59, Jordan Crouse wrote:
[...]> +static int install_pasid_cb(int pasid, u64 ttbr, u32 asid, void *data)
> +{
> + struct pasid_entry *entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> +
> + if (!entry)
> + return -ENOMEM;
> +
> + entry->pasid = pasid;
> + entry->ttbr = ttbr;
> + entry->asid = asid;
> +
> + /* FIXME: Assume that we'll never have a pasid conflict? */

I think a conflict would be a bug on the IOMMU side. Users should not have
to check this. Then again, I have a few WARNs on the SMMUv3 context table
code that uncovered nasty bugs during development.

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

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Claudiu Beznea]

On 28.02.2018 21:44, Thierry Reding wrote:
> On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
>> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
>> were adapted to this change.
>>
>> Signed-off-by: Claudiu Beznea 
>> ---
>>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>>  drivers/bus/ts-nbus.c|  2 +-
>>  drivers/clk/clk-pwm.c|  3 ++-
>>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>>  drivers/hwmon/pwm-fan.c  |  2 +-
>>  drivers/input/misc/max77693-haptic.c |  2 +-
>>  drivers/input/misc/max8997_haptic.c  |  6 +-
>>  drivers/leds/leds-pwm.c  |  5 -
>>  drivers/media/rc/ir-rx51.c   |  5 -
>>  drivers/media/rc/pwm-ir-tx.c |  5 -
>>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>>  drivers/video/backlight/lp8788_bl.c  |  5 -
>>  drivers/video/backlight/pwm_bl.c | 11 +--
>>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>>  include/linux/pwm.h  |  6 --
>>  16 files changed, 70 insertions(+), 21 deletions(-)
> 
> I don't think it makes sense to leak mode support into the legacy API.
> The pwm_config() function is considered legacy
I missed this aspect.

 and should eventually go
> away. As such it doesn't make sense to integrate a new feature such as
> PWM modes into it. 
Agree.

All users of pwm_config() assume normal mode, and
> that's what pwm_config() should provide.
Agree.

> 
> Anyone that needs something other than normal mode should use the new
> atomic PWM API.
Agree.

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

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Heikki Krogerus]

Hi,

On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
> +
> +ccic: s2mm005@33 {
> + ...
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";

Is this child node really necessary? There will never be more then
one connector per CC line.

We should prefer device_graph* functions over of_graph* and
acpi_graph* functions in the drivers so we don't have to handle the
same thing multiple times with separate APIs. Is it still possible if
there is that connector child node?

> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usb_con_hs: endpoint {
> + remote-endpoint = <_usbc_hs>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + usb_con_ss: endpoint {
> + remote-endpoint = <_phy_ss>;
> + };
> + };
> + port@2 {
> + reg = <2>;
> + usb_con_sbu: endpoint {
> + remote-endpoint = <_aux>;
> + };
> + };
> + };
> + };
> +};


Thanks,

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

Re: [PATCH 03/14] iommu: Create a base struct for io_mm

[Jean-Philippe Brucker]

Hi Jordan,

Thank you for this, SMMUv3 and virtio-iommu need these SVA patches as well.

On 21/02/18 22:59, Jordan Crouse wrote:
[...]> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index e2c49e583d8d..e998389cf195 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -110,8 +110,17 @@ struct iommu_domain {
>   struct list_head mm_list;
>  };
>  
> +enum iommu_io_type {
> + IO_TYPE_MM,
> +};
> +
> +struct io_base {
> + int type;
> + int pasid;
> +};

"io_base" is a bit vague. I'm bad at naming so my opinion doesn't hold
much water, but I'd rather this be something like "io_mm_base". When I
initially toyed with the idea I intended to keep io_mm as parent structure
and have "private" and "shared" sub-structures. Even if private PASIDs
don't rely on the kernel mm subsystem, this structure would still
represent an I/O mm of sorts, with a pgd and pgtable info.

Thanks,
Jean

> +
>  struct io_mm {
> - int pasid;
> + struct io_base  base;
>   struct list_headdevices;
>   struct kref kref;
>  #if defined(CONFIG_MMU_NOTIFIER)
> 

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

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Claudiu Beznea]

On 28.02.2018 22:04, Jani Nikula wrote:
> On Wed, 28 Feb 2018, Thierry Reding  wrote:
>> Anyone that needs something other than normal mode should use the new
>> atomic PWM API.
> 
> At the risk of revealing my true ignorance, what is the new atomic PWM
> API? Where? Examples of how one would convert old code over to the new
> API?
As far as I know, the old PWM core code uses config(), set_polarity(),
enable(), disable() methods of driver, registered as pwm_ops:
struct pwm_ops {

int (*request)(struct pwm_chip *chip, struct pwm_device *pwm);

void (*free)(struct pwm_chip *chip, struct pwm_device *pwm);

int (*config)(struct pwm_chip *chip, struct pwm_device *pwm,

  int duty_ns, int period_ns);

int (*set_polarity)(struct pwm_chip *chip, struct pwm_device *pwm,

enum pwm_polarity polarity);

int (*capture)(struct pwm_chip *chip, struct pwm_device *pwm,

   struct pwm_capture *result, unsigned long timeout);

int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);

void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);

int (*apply)(struct pwm_chip *chip, struct pwm_device *pwm,

 struct pwm_state *state);

void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm,

  struct pwm_state *state);

#ifdef CONFIG_DEBUG_FS

void (*dbg_show)(struct pwm_chip *chip, struct seq_file *s);

#endif

struct module *owner;

};


to do settings on hardware. In order to so settings on a PWM the users
should have been follow the below steps:
->config()
->set_polarity()
->enable()
Moreover, if the PWM was previously enabled it should have been first
disable and then to follow the above steps in order to apply a new settings
on hardware.
The driver should have been provide, at probe, all the above function:
->config(), ->set_polarity(), ->disable(), ->enable(), function that were
used by PWM core.

Now, having atomic PWM, the driver should provide one function to PWM core,
which is ->apply() function. Every PWM has a state associated, which keeps
the period, duty cycle, polarity and enable/disable status. The driver's
->apply() function takes as argument the state that should be applied and
it takes care of applying this new state directly without asking user to
call ->disable(), then ->config()/->set_polarity(), then ->enable() to
apply new hardware settings.

The PWM consumer could set a new state for PWM it uses, using
pwm_apply_state(pwm, new_state);

Regarding the models to switch on atomic PWM, on the controller side you
can check for drivers that registers apply function at probe time.
Regarding the PWM users, you can look for pwm_apply_state()
(drivers/hwmon/pwm-fan.c or drivers/input/misc/pwm-beeper.c are some examples).

Thierry, please correct me if I'm wrong.

Thank you,
Claudiu Beznea

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

[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #10 from Michael Zapf  ---
It seems to be related to EDID, as I see it.

Once I turn off the display, I lose the EDID information.

Before:
# find /sys -name edid -exec echo {} \; -exec od -tx1 -Ax {} \;
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DVI-D-1/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DP-2/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-HDMI-A-2/edid
00 00 ff ff ff ff ff ff 00 41 2f 27 10 01 01 01 01
10 00 19 01 03 80 36 23 78 ee ce 50 a3 54 4c 99 26
20 0f 50 54 a5 6b 80 81 40 a9 00 a9 40 b3 00 d1 00
30 01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20
40 36 00 22 60 21 00 00 1a 00 00 00 fc 00 56 53 58
50 2d 33 33 30 0a 20 20 20 20 20 00 00 00 fd 00 30
60 55 1e 46 11 00 0a 20 20 20 20 20 20 00 00 00 ff
70 00 50 4c 43 39 33 33 30 31 34 47 0a 20 20 01 a6
80 02 03 34 71 4b 01 02 04 85 06 10 11 13 14 15 1f
90 38 09 7f 07 0f 7f 07 15 07 50 3e 06 c0 49 7f 00
a0 57 06 00 5f 7e 01 67 7e 00 83 4f 00 00 66 03 0c
b0 00 11 00 80 01 1d 80 18 71 1c 16 20 58 2c 25 00
c0 06 44 21 00 00 9e 01 1d 80 d0 72 1c 16 20 10 2c
d0 25 80 06 44 21 00 00 9e 01 1d 00 72 51 d0 1e 20
e0 6e 28 55 00 06 44 21 00 00 1e 01 1d 00 bc 52 d0
f0 1e 20 b8 28 55 40 06 44 21 00 00 1e 00 00 00 8f
000100
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DP-1/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-HDMI-A-1/edid
00


Turn off, turn on again:

# find /sys -name edid -exec echo {} \; -exec od -tx1 -Ax {} \;
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DVI-D-1/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DP-2/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-HDMI-A-2/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DP-1/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-HDMI-A-1/edid
00

When I continue to turn it off and on again, EDID does not reappear. However,
when I reboot, it is there again. How does my monitor know that my PC has been
rebooted?

-- 
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/vc4: Ignore alpha on primary plane

[Eric Anholt]

Ville Syrjälä  writes:

> On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote:
>> Hey Ville,
>> 
>> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä
>>  wrote:
>> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote:
>> >> If you want the plane to always be opaque you shouldn't expose any
>> >> formats with alpha.
>> >>
>> >> Also what happens if one disables the primary plane? Or does the driver
>> >> not allow that?
>> >
>> > Or just makes the plane not cover the entire screen?
>> 
>> We've exposed alpha formats in the past so disabling that now would break
>> userspace, certainly Android that chooses alpha-everything.
>
> So it refuses to even run on hardware that can't do per-pixel alpha on
> the primary plane?
>
>> The VC4 HVS
>> has no fixed planes so I'll acknowledge that the concept of a primary plane
>> is somewhat dubious and userspace could disable it or make it not cover the
>> entire screen, making this ineffective.
>> 
>> But then ultimately there doesn't seem to be a standard for what the display
>> is supposed to be if you have transparent pixels with no plane to blend to
>> below.
>
> The standard is black. IMO it's a driver bug if it fails to do that.

If the plane is premultiplied (isn't that what DRM planes are supposed
to be?  I can't find any docs), then blending against black is the same
as not doing any blending at all.


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

Re: [PATCH 2/2] drm/sun4i: add lvds mode_valid function

[Giulio Benetti]

Hi,

Il 02/03/2018 15:37, Maxime Ripard ha scritto:

On Fri, Mar 02, 2018 at 12:42:14PM +0100, Giulio Benetti wrote:

Hi,

Il 01/03/2018 10:57, Maxime Ripard ha scritto:

On Wed, Feb 28, 2018 at 06:53:52PM +0100, Giulio Benetti wrote:

   static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
.get_modes  = sun4i_lvds_get_modes,
+   .mode_valid = sun4i_lvds_mode_valid,
   };


This should be on the encoder, not the connector.


I've seen it is bound to connector in rgb and to encoder in hdmi.
Is it correct rgb mode_valid under connector funcs?
Otherwise I send a patch also for that one.


This would need to be fixed as well. Bridges attach to encoder, not
connectors, so if you ever have a bridge connected to the RGB output
(like on the A13-Olinuxino), mode_valid isn't called at the moment.


Ok, I will do the same for rgb and submit a patchset,
need some time to test both lvds and rgb.

--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/14] iommu: sva: Add support for pasid allocation

[Jordan Crouse]

On Fri, Mar 02, 2018 at 12:27:58PM +, Jean-Philippe Brucker wrote:
> On 21/02/18 22:59, Jordan Crouse wrote:
> [...]
> > +int iommu_sva_alloc_pasid(struct iommu_domain *domain, struct device *dev)
> > +{
> > +   int ret, pasid;
> > +   struct io_pasid *io_pasid;
> > +
> > +   if (!domain->ops->pasid_alloc || !domain->ops->pasid_free)
> > +   return -ENODEV;
> > +
> > +   io_pasid = kzalloc(sizeof(*io_pasid), GFP_KERNEL);
> > +   if (!io_pasid)
> > +   return -ENOMEM;
> > +
> > +   io_pasid->domain = domain;
> > +   io_pasid->base.type = IO_TYPE_PASID;
> > +
> > +   idr_preload(GFP_KERNEL);
> > +   spin_lock(_sva_lock);
> > +   pasid = idr_alloc_cyclic(_pasid_idr, _pasid->base,
> > +   1, (1 << 31), GFP_ATOMIC);
> 
> To be usable by other IOMMUs, this should restrict the PASID range to what
> the IOMMU and the device support like io_mm_alloc(). In your case 31 bits,
> but with PCI PASID it depends on the PASID capability and the SMMU
> SubstreamID range.
> 
> For this reason I think device drivers should call iommu_sva_device_init()
> once, even for the alloc_pasid() API. For SMMUv2 I guess it will be a NOP,
> but other IOMMUs will allocate PASID tables and enable features in the
> device. In addition, knowing that all users of the API call
> iommu_sva_device_init()/shutdown() could allow us to allocate and enable
> stuff lazily in the future.
> 
> It would also allow a given device driver to use both
> iommu_sva_pasid_alloc() and iommu_sva_bind() at the same time. So that the
> driver can assigns contexts to userspace and still use some of them for
> management.

No problem.

> [...]
> > +int iommu_sva_map(int pasid, unsigned long iova,
> > + phys_addr_t paddr, size_t size, int prot)
> 
> It would be nice to factor iommu_map(), since this logic for map, map_sg
> and unmap should be the same regardless of the PASID argument.
> 
> For example
> - iommu_sva_map(domain, pasid, ...)
> - iommu_map(domain, ...)
> 
> both call
> - __iommu_map(domain, pasid, ...)
> 
> which calls either
> - ops->map(domain, ...)
> - ops->sva_map(domain, pasid, ...)

Agree.  I was kind of annoyed at the code duplication - this would be a good way
to handle it.

> [...]
> > @@ -347,6 +353,15 @@ struct iommu_ops {
> > int (*page_response)(struct iommu_domain *domain, struct device *dev,
> >  struct page_response_msg *msg);
> >  
> > +   int (*pasid_alloc)(struct iommu_domain *domain, struct device *dev,
> > +   int pasid);
> > +   int (*sva_map)(struct iommu_domain *domain, int pasid,
> > +  unsigned long iova, phys_addr_t paddr, size_t size,
> > +  int prot);
> > +   size_t (*sva_unmap)(struct iommu_domain *domain, int pasid,
> > +   unsigned long iova, size_t size);
> > +   void (*pasid_free)(struct iommu_domain *domain, int pasid);
> > +
> 
> Hmm, now IOMMU has the following ops:
> 
> * mm_alloc(): allocates a shared mm structure
> * mm_attach(): writes the entry in the PASID table
> * mm_detach(): removes the entry from the PASID table and invalidates it
> * mm_free(): free shared mm
> * pasid_alloc(): allocates a pasid structure (which I usually call
> "private mm") and write the entry in the PASID table (or call
> install_pasid() for SMMUv2)
> * pasid_free(): remove from the PASID table (or call remove_pasid()) and
> free the pasid structure.
> 
> Splitting mm_alloc and mm_attach is necessary because the io_mm in my case
> can be shared between devices (allocated once, attached multiple times).
> In your case a PASID is private to one device so only one callback is
> needed. However mm_alloc+mm_attach will do roughly the same as
> pasid_alloc, so to reduce redundancy in iommu_ops, maybe we could reuse
> mm_alloc and mm_attach for the private PASID case?

Okay - let me bang on it and see what we can clean up.  Thanks for the review.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/14] iommu: Create a base struct for io_mm

[Jordan Crouse]

On Fri, Mar 02, 2018 at 12:25:48PM +, Jean-Philippe Brucker wrote:
> Hi Jordan,
> 
> Thank you for this, SMMUv3 and virtio-iommu need these SVA patches as well.
> 
> On 21/02/18 22:59, Jordan Crouse wrote:
> [...]> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index e2c49e583d8d..e998389cf195 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -110,8 +110,17 @@ struct iommu_domain {
> > struct list_head mm_list;
> >  };
> >  
> > +enum iommu_io_type {
> > +   IO_TYPE_MM,
> > +};
> > +
> > +struct io_base {
> > +   int type;
> > +   int pasid;
> > +};
> 
> "io_base" is a bit vague. I'm bad at naming so my opinion doesn't hold
> much water, but I'd rather this be something like "io_mm_base". When I
> initially toyed with the idea I intended to keep io_mm as parent structure
> and have "private" and "shared" sub-structures. Even if private PASIDs
> don't rely on the kernel mm subsystem, this structure would still
> represent an I/O mm of sorts, with a pgd and pgtable info.

I'm also bad at naming but I don't mind changing it. io_mm_base seems okay to me
unless somebody has a better idea. I also like the terms "private" and
"shared". I'm going to start adopting those where it makes sense.

Jordan
> 
> > +
> >  struct io_mm {
> > -   int pasid;
> > +   struct io_base  base;
> > struct list_headdevices;
> > struct kref kref;
> >  #if defined(CONFIG_MMU_NOTIFIER)
> > 
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Ville Syrjälä]

On Fri, Mar 02, 2018 at 04:48:03PM +0100, Stefan Schake wrote:
> On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä
>  wrote:
> > On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote:
> >> Hey Ville,
> >>
> >> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä
> >>  wrote:
> >> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote:
> >> >> If you want the plane to always be opaque you shouldn't expose any
> >> >> formats with alpha.
> >> >>
> >> >> Also what happens if one disables the primary plane? Or does the driver
> >> >> not allow that?
> >> >
> >> > Or just makes the plane not cover the entire screen?
> >>
> >> We've exposed alpha formats in the past so disabling that now would break
> >> userspace, certainly Android that chooses alpha-everything.
> >
> > So it refuses to even run on hardware that can't do per-pixel alpha on
> > the primary plane?
> 
> Well since we have no real primary plane we'd have to remove support from
> every plane or add elaborate logic to atomic check that detects and rejects
> a configuration that has pixels blending from nothing, which presumably is
> what triggers the display artifacts.
> 
> >> The VC4 HVS
> >> has no fixed planes so I'll acknowledge that the concept of a primary plane
> >> is somewhat dubious and userspace could disable it or make it not cover the
> >> entire screen, making this ineffective.
> >>
> >> But then ultimately there doesn't seem to be a standard for what the 
> >> display
> >> is supposed to be if you have transparent pixels with no plane to blend to
> >> below.
> >
> > The standard is black. IMO it's a driver bug if it fails to do that.
> 
> Then to be sure we should always enable the background fill. Maybe Eric can
> clarify what the cost for this is, all I have to go on there is the comment
> on the register set.

Yeah, that sounds like the correct thing to do.

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

[Patch 4/4] drm/omap: Add virtual plane support to omap_plane

[Benoit Parrot]

Add virtual plane support by adding an array to contain
all of the actual plane_id a "omap_plane" correspond to.

When at least one 'plane' child node is present in DT then
omap_plane_init will only used the plane described in DT.
Some of these nodes may be a virtual plane if they are defined
as two physical planes.
Planes can also be associated with various crtcs independently.
Therefore we can restrict the use of virtual plane to specific
CRTC/video port if need be, if crtc_mask is not specified then
the plane will be available to all available crtcs.
Physical plane which are not described will essentially be hidden
from the driver.

If no 'plane' child node exist then the existing plane
allocation will take place.

Signed-off-by: Benoit Parrot 
---
 drivers/gpu/drm/omapdrm/omap_drv.c   |  18 +++--
 drivers/gpu/drm/omapdrm/omap_fb.c|  66 +++--
 drivers/gpu/drm/omapdrm/omap_fb.h|   4 +-
 drivers/gpu/drm/omapdrm/omap_plane.c | 139 +--
 drivers/gpu/drm/omapdrm/omap_plane.h |   3 +-
 5 files changed, 162 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index dd68b2556f5b..73796364a592 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -188,10 +188,9 @@ static int omap_connect_dssdevs(void)
return r;
 }
 
-static int omap_modeset_init_properties(struct drm_device *dev)
+static int omap_modeset_init_properties(struct drm_device *dev, u32 num_planes)
 {
struct omap_drm_private *priv = dev->dev_private;
-   unsigned int num_planes = priv->dispc_ops->get_num_ovls();
 
priv->zorder_prop = drm_property_create_range(dev, 0, "zorder", 0,
  num_planes - 1);
@@ -210,10 +209,19 @@ static int omap_modeset_init(struct drm_device *dev)
int num_crtcs, crtc_idx, plane_idx;
int ret;
u32 plane_crtc_mask;
+   struct dispc_plane_mappings plane_mappings = {0};
 
drm_mode_config_init(dev);
 
-   ret = omap_modeset_init_properties(dev);
+   ret = priv->dispc_ops->get_plane_mapping(_mappings);
+   if (ret < 0)
+   return ret;
+
+   /* use plane mappings info */
+   if (plane_mappings.num_planes)
+   num_ovls = plane_mappings.num_planes;
+
+   ret = omap_modeset_init_properties(dev, num_ovls);
if (ret < 0)
return ret;
 
@@ -266,7 +274,7 @@ static int omap_modeset_init(struct drm_device *dev)
return -ENOMEM;
 
plane = omap_plane_init(dev, plane_idx, DRM_PLANE_TYPE_PRIMARY,
-   plane_crtc_mask);
+   plane_crtc_mask, _mappings);
if (IS_ERR(plane))
return PTR_ERR(plane);
 
@@ -296,7 +304,7 @@ static int omap_modeset_init(struct drm_device *dev)
return -EINVAL;
 
plane = omap_plane_init(dev, plane_idx, DRM_PLANE_TYPE_OVERLAY,
-   plane_crtc_mask);
+   plane_crtc_mask, _mappings);
if (IS_ERR(plane))
return PTR_ERR(plane);
 
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index b2539a90e1a4..80b29b7f5696 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -153,25 +153,27 @@ static uint32_t drm_rotation_to_tiler(unsigned int 
drm_rot)
 /* update ovl info for scanout, handles cases of multi-planar fb's, etc.
  */
 void omap_framebuffer_update_scanout(struct drm_framebuffer *fb,
-   struct drm_plane_state *state, struct omap_overlay_info *info)
+   struct drm_plane_state *state,
+   struct omap_overlay_info *main_info,
+   struct omap_overlay_info *aux_info)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
const struct drm_format_info *format = omap_fb->format;
struct plane *plane = _fb->planes[0];
uint32_t x, y, orient = 0;
 
-   info->fourcc = fb->format->format;
+   main_info->fourcc = fb->format->format;
 
-   info->pos_x  = state->crtc_x;
-   info->pos_y  = state->crtc_y;
-   info->out_width  = state->crtc_w;
-   info->out_height = state->crtc_h;
-   info->width  = state->src_w >> 16;
-   info->height = state->src_h >> 16;
+   main_info->pos_x  = state->crtc_x;
+   main_info->pos_y  = state->crtc_y;
+   main_info->out_width  = state->crtc_w;
+   main_info->out_height = state->crtc_h;
+   main_info->width  = state->src_w >> 16;
+   main_info->height = state->src_h >> 16;
 
/* DSS driver wants the w & h in rotated orientation */
if (drm_rotation_90_or_270(state->rotation))
-   swap(info->width, info->height);
+  

[Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Benoit Parrot]

Add 'plane' child node to generic DISPC node as an optional
property.

Signed-off-by: Benoit Parrot 
---
 .../devicetree/bindings/display/ti/ti,omap-dss.txt | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt 
b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
index 249e588d7865..cb101525b805 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
+++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
@@ -27,6 +27,34 @@ DISPC
 Optional properties:
 - max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
limit
in bytes per second
+- plane: Child node(s) which defines which logical plane are available to
+   the system. If at least one plane child node is defined then
+   only planes defined by these nodes will be available to the system.
+   Plane nodes must be sequential starting with reg = <0> as DT parsing
+   will stop on the first missing numbered node.
+   This means if plane #1 is defined but plane #0 is not then it will
+   be as if none of the plane nodes were defined.
+
+   Each plane node contains the following properties:
+   Required properties:
+   - reg:   Used to number the logical plane
+   - hw-planes: One or two HW plane number(s).
+When 2 numbers are present this indicates a virtual plane
+composed of two physical planes intended to be used
+when the display is larger then the capacity of a
+single plane i.e. wider than 2048 pixels.
+The first number in the pair will dictate the capabilities
+of the virtual plane. This means that for proper
+operation the virtual plane should be composed of HW
+planes of the same capabilities.
+If GFX plane is used in a virtual plane it should be
+specified first, otherwise unexpected behavior would
+be encountered.
+   Optional property:
+   - hw-crtcs:  One or more HW crtc number(s).
+Describe the list of CRTCs on which this plane is
+available. If this node is not present then the
+plane will be available on all available CRTCs.
 
 Video Ports
 ---
@@ -216,3 +244,38 @@ OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector
};
};
 };
+
+A short example on how to define a virtual plane configuration
+to enable wide display support.
+Here we define:
+- plane#0 to be the HW plane #0 (i.e. GFX plane)
+ only available on crtc #0
+- plane#1 to be a virtual wide plane composed of HW plane #1 and #2
+ (i.e. VID1 & VID2) available on crtc #0 & #1
+- plane#2 to be the HW plane #3 (i.e. VID3 plane)
+ only available on crtc #0
+
+ {
+dispc@58001000 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+plane@0 {
+reg = <0>;
+hw-planes = <0>;
+hw-crtcs = <0>;
+};
+
+plane@1 {
+reg = <1>;
+hw-planes = <1 2>;
+hw-crtcs = <0 1>;
+};
+
+plane@2 {
+reg = <2>;
+hw-planes = <3>;
+hw-crtcs = <0>;
+};
+};
+};
-- 
2.9.0

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

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Stefan Schake]

On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä
 wrote:
> On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote:
>> Hey Ville,
>>
>> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä
>>  wrote:
>> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote:
>> >> If you want the plane to always be opaque you shouldn't expose any
>> >> formats with alpha.
>> >>
>> >> Also what happens if one disables the primary plane? Or does the driver
>> >> not allow that?
>> >
>> > Or just makes the plane not cover the entire screen?
>>
>> We've exposed alpha formats in the past so disabling that now would break
>> userspace, certainly Android that chooses alpha-everything.
>
> So it refuses to even run on hardware that can't do per-pixel alpha on
> the primary plane?

Well since we have no real primary plane we'd have to remove support from
every plane or add elaborate logic to atomic check that detects and rejects
a configuration that has pixels blending from nothing, which presumably is
what triggers the display artifacts.

>> The VC4 HVS
>> has no fixed planes so I'll acknowledge that the concept of a primary plane
>> is somewhat dubious and userspace could disable it or make it not cover the
>> entire screen, making this ineffective.
>>
>> But then ultimately there doesn't seem to be a standard for what the display
>> is supposed to be if you have transparent pixels with no plane to blend to
>> below.
>
> The standard is black. IMO it's a driver bug if it fails to do that.

Then to be sure we should always enable the background fill. Maybe Eric can
clarify what the cost for this is, all I have to go on there is the comment
on the register set.

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

[PATCH v2 05/10] video: add MIPI DSI host controller bridge

[yannick fertre]

Add a Synopsys Designware MIPI DSI host bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.

Signed-off-by: yannick fertre 
---
 drivers/video/Kconfig   |   9 +
 drivers/video/Makefile  |   1 +
 drivers/video/dw_mipi_dsi.c | 822 
 include/dw_mipi_dsi.h   |  32 ++
 4 files changed, 864 insertions(+)
 create mode 100644 drivers/video/dw_mipi_dsi.c
 create mode 100644 include/dw_mipi_dsi.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index b5fc535..0f641d7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -657,6 +657,15 @@ config VIDEO_DW_HDMI
  rather requires a SoC-specific glue driver to call it), it
  can not be enabled from the configuration menu.
 
+config VIDEO_DW_MIPI_DSI
+   bool
+   help
+ Enables the common driver code for the Designware MIPI DSI
+ block found in SoCs from various vendors.
+ As this does not provide any functionality by itself (but
+ rather requires a SoC-specific glue driver to call it), it
+ can not be enabled from the configuration menu.
+
 config VIDEO_SIMPLE
bool "Simple display driver for preconfigured display"
help
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 65002af..50be569 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
 obj-$(CONFIG_LG4573) += lg4573.o
 obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
 obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_VIDEO_DW_MIPI_DSI) += dw_mipi_dsi.o
 obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
 obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
 obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
new file mode 100644
index 000..d7bd92d
--- /dev/null
+++ b/drivers/video/dw_mipi_dsi.c
@@ -0,0 +1,822 @@
+/*
+ * Copyright (C) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *   Yannick Fertre  for STMicroelectronics.
+ *
+ * Modified by Yannick Fertre 
+ * This generic Synopsys DesignWare MIPI DSI host driver is based on the
+ * bridge synopsys from drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c (kernel
+ * linux).
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HWVER_131  0x31333100  /* IP version 1.31 */
+
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVISION(div)   (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVISION(div)   ((div) & 0xff)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VCID(vcid) ((vcid) & 0x3)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define LOOSELY18_EN   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_VCID   0x1c
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_PARTITIONING_EN0x24
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define CRC_RX_EN  BIT(4)
+#define ECC_RX_EN  BIT(3)
+#define BTA_EN BIT(2)
+#define EOTP_RX_EN BIT(1)
+#define EOTP_TX_EN BIT(0)
+
+#define DSI_GEN_VCID   0x30
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
+#define 

[PATCH v2 02/10] video: stm32: stm32_ltdc: update debug log

[yannick fertre]

Replace  macro debug by pr_error, pr_warn or pr_info.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 62 
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index bd9c0de..e95f35c 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -176,13 +176,13 @@ static u32 stm32_ltdc_get_pixel_format(enum 
video_log2_bpp l2bpp)
case VIDEO_BPP2:
case VIDEO_BPP4:
default:
-   debug("%s: warning %dbpp not supported yet, %dbpp instead\n",
- __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
+   pr_warn("%s: warning %dbpp not supported yet, %dbpp instead\n",
+   __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
pf = PF_RGB565;
break;
}
 
-   debug("%s: %d bpp -> ltdc pf %d\n", __func__, VNBITS(l2bpp), pf);
+   pr_info("%s: %d bpp -> ltdc pf %d\n", __func__, VNBITS(l2bpp), pf);
 
return (u32)pf;
 }
@@ -249,7 +249,7 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv 
*priv,
 
/* Signal polarities */
val = 0;
-   debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
+   pr_info("%s: timing->flags 0x%08x\n", __func__, timings->flags);
if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= GCR_HSPOL;
if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
@@ -343,26 +343,26 @@ static int stm32_ltdc_probe(struct udevice *dev)
 
priv->regs = (void *)dev_read_addr(dev);
if ((fdt_addr_t)priv->regs == FDT_ADDR_T_NONE) {
-   debug("%s: ltdc dt register address error\n", __func__);
+   pr_err("%s: ltdc dt register address error\n", __func__);
return -EINVAL;
}
 
ret = clk_get_by_index(dev, 0, );
if (ret) {
-   debug("%s: peripheral clock get error %d\n", __func__, ret);
+   pr_err("%s: peripheral clock get error %d\n", __func__, ret);
return ret;
}
 
ret = clk_enable();
if (ret) {
-   debug("%s: peripheral clock enable error %d\n",
- __func__, ret);
+   pr_err("%s: peripheral clock enable error %d\n",
+  __func__, ret);
return ret;
}
 
ret = reset_get_by_index(dev, 0, );
if (ret) {
-   debug("%s: missing ltdc hardware reset\n", __func__);
+   pr_err("%s: missing ltdc hardware reset\n", __func__);
return -ENODEV;
}
 
@@ -372,41 +372,40 @@ static int stm32_ltdc_probe(struct udevice *dev)
 #ifdef CONFIG_VIDEO_BRIDGE
ret = uclass_get_device(UCLASS_VIDEO_BRIDGE, 0, );
if (ret) {
-   debug("%s: No video bridge, or no backlight on bridge\n",
- __func__);
+   pr_info("%s: No video bridge, or no backlight on bridge\n",
+   __func__);
}
 
if (bridge) {
ret = video_bridge_attach(bridge);
if (ret) {
-   debug("%s: fail to attach bridge\n", __func__);
+   pr_err("%s: fail to attach bridge\n", __func__);
return ret;
}
}
 #endif
ret = uclass_first_device(UCLASS_PANEL, );
if (ret) {
-   debug("%s: panel device error %d\n", __func__, ret);
+   pr_err("%s: panel device error %d\n", __func__, ret);
return ret;
}
 
ret = fdtdec_decode_display_timing(gd->fdt_blob, dev_of_offset(panel),
   0, );
if (ret) {
-   debug("%s: decode display timing error %d\n",
- __func__, ret);
+   pr_err("%s: decode display timing error %d\n", __func__, ret);
return ret;
}
 
rate = clk_set_rate(, timings.pixelclock.typ);
if (rate < 0) {
-   debug("%s: fail to set pixel clock %d hz %d hz\n",
- __func__, timings.pixelclock.typ, rate);
+   pr_err("%s: fail to set pixel clock %d hz %d hz\n",
+  __func__, timings.pixelclock.typ, rate);
return rate;
}
 
-   debug("%s: Set pixel clock req %d hz get %d hz\n", __func__,
- timings.pixelclock.typ, rate);
+   pr_info("%s: Set pixel clock req %d hz get %d hz\n", __func__,
+   timings.pixelclock.typ, rate);
 
/* TODO Below parameters are hard-coded for the moment... */
priv->l2bpp = VIDEO_BPP16;
@@ -417,12 +416,12 @@ static int stm32_ltdc_probe(struct udevice *dev)
priv->crop_h = timings.vactive.typ;
priv->alpha = 0xFF;
 
-   debug("%s: %dx%d %dbpp frame buffer at 0x%lx\n", __func__,
-

[PATCH v2 10/10] board: Add STM32F769 SoC, discovery board support

[yannick fertre]

Signed-off-by: yannick fertre 
---
 configs/stm32f769-disco_defconfig | 63 +++
 1 file changed, 63 insertions(+)
 create mode 100644 configs/stm32f769-disco_defconfig

diff --git a/configs/stm32f769-disco_defconfig 
b/configs/stm32f769-disco_defconfig
new file mode 100644
index 000..ac34076
--- /dev/null
+++ b/configs/stm32f769-disco_defconfig
@@ -0,0 +1,63 @@
+CONFIG_ARM=y
+CONFIG_STM32=y
+CONFIG_SYS_MALLOC_F_LEN=0xC00
+CONFIG_STM32F7=y
+CONFIG_TARGET_STM32F746_DISCO=y
+CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco"
+CONFIG_BOOTDELAY=3
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk consoleblank=0 
ignore_loglevel"
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="U-Boot > "
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n"
+CONFIG_AUTOBOOT_STOP_STR=" "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPT=y
+# CONFIG_RANDOM_UUID is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_SNTP=y
+CONFIG_CMD_DNS=y
+CONFIG_CMD_LINK_LOCAL=y
+CONFIG_CMD_BMP=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+# CONFIG_DOS_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_NETCONSOLE=y
+# CONFIG_BLK is not set
+CONFIG_DM_MMC=y
+# CONFIG_SPL_DM_MMC is not set
+CONFIG_ARM_PL180_MMCI=y
+CONFIG_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+# CONFIG_PINCTRL_FULL is not set
+CONFIG_DM_SPI=y
+CONFIG_STM32_QSPI=y
+CONFIG_DM_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
+CONFIG_VIDEO_STM32=y
+CONFIG_VIDEO_STM32_DSI=y
+CONFIG_VIDEO_STM32_MAX_XRES=480
+CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_EFI_LOADER is not set
-- 
1.9.1

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

[PATCH v2 09/10] arm: dts: stm32: add display for STM32F769 disco board

[yannick fertre]

Enable the display controller, mipi dsi bridge & panel.
Set panel display timings.

Signed-off-by: yannick fertre 
---
 arch/arm/dts/stm32f769-disco.dts | 71 
 1 file changed, 71 insertions(+)

diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
index 59c9d31..82985b9 100644
--- a/arch/arm/dts/stm32f769-disco.dts
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -42,6 +42,7 @@
 
 /dts-v1/;
 #include "stm32f746.dtsi"
+#include 
 #include 
 
 / {
@@ -264,3 +265,73 @@
bus-width = <4>;
max-frequency = <2500>;
 };
+
+ {
+   status = "okay";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ltdc_out_dsi: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in>;
+   };
+   };
+};
+
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <_out_dsi>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi_out: endpoint {
+   remote-endpoint = <_panel_in>;
+   };
+   };
+   };
+
+   panel-dsi@0 {
+   compatible = "orisetech,otm8009a";
+   reg = <0>; /* dsi virtual channel (0..3) */
+   reset-gpios = < 15 GPIO_ACTIVE_LOW>;
+   status = "okay";
+
+   port {
+   dsi_panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   display-timings {
+   timing@0 {
+   clock-frequency = <32729000>;
+   hactive = <480>;
+   hfront-porch = <120>;
+   hback-porch = <63>;
+   hsync-len = <120>;
+   vactive = <800>;
+   vfront-porch = <12>;
+   vback-porch = <12>;
+   vsync-len = <12>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <0>;
+   pixelclk-active = <1>;
+   };
+   };
+   };
+};
-- 
1.9.1

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

[PATCH v2 07/10] video: add support of panel rm68200

[yannick fertre]

Support for Raydium rm68200 720p dsi 2dl video mode panel.

Signed-off-by: yannick fertre 
---
 drivers/video/Kconfig   |   8 +
 drivers/video/Makefile  |   1 +
 drivers/video/raydium-rm68200.c | 329 
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/video/raydium-rm68200.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0f641d7..2561c59 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -328,6 +328,14 @@ config VIDEO_LCD_ORISETECH_OTM8009A
---help---
Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
 
+config VIDEO_LCD_RAYDIUM_RM68200
+   bool "RM68200 DSI LCD panel support"
+   depends on DM_VIDEO
+   select VIDEO_MIPI_DSI
+   default n
+   ---help---
+   Support for Raydium rm68200 720x1280 dsi 2dl video mode panel.
+
 config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 50be569..1a6c8d3 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
 obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
 obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
+obj-$(CONFIG_VIDEO_LCD_RAYDIUM_RM68200) += raydium-rm68200.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/raydium-rm68200.c b/drivers/video/raydium-rm68200.c
new file mode 100644
index 000..46afb58
--- /dev/null
+++ b/drivers/video/raydium-rm68200.c
@@ -0,0 +1,329 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre  for STMicroelectronics.
+ *   Philippe Cornu  for STMicroelectronics.
+ *
+ * This rm68200 panel driver is based on the panel driver from
+ * drivers/gpu/drm/panel/panel-raydium-rm68200.c (kernel linux)
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DRV_NAME "raydium_rm68200"
+
+/*** Manufacturer Command Set ***/
+#define MCS_CMD_MODE_SW0xFE /* CMD Mode Switch */
+#define MCS_CMD1_UCS   0x00 /* User Command Set (UCS = CMD1) */
+#define MCS_CMD2_P00x01 /* Manufacture Command Set Page0 (CMD2 P0) */
+#define MCS_CMD2_P10x02 /* Manufacture Command Set Page1 (CMD2 P1) */
+#define MCS_CMD2_P20x03 /* Manufacture Command Set Page2 (CMD2 P2) */
+#define MCS_CMD2_P30x04 /* Manufacture Command Set Page3 (CMD2 P3) */
+
+/* CMD2 P0 commands (Display Options and Power) */
+#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */
+#define MCS_SGOPCTR0x16 /* Source Bias Current */
+#define MCS_SDCTR  0x1A /* Source Output Delay Time */
+#define MCS_INVCTR 0x1B /* Inversion Type */
+#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */
+#define MCS_SETAVDD0x27 /* PFM Control for AVDD Output */
+#define MCS_SETAVEE0x29 /* PFM Control for AVEE Output */
+#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */
+#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */
+#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */
+#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */
+#define MCS_SETVGN 0x52 /* VG M/S N Control */
+#define MCS_SETVGP 0x54 /* VG M/S P Control */
+#define MCS_SW_CTRL0x5F /* Interface Control for PFM and MIPI */
+
+/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
+#define GOA_VSTV1  0x00
+#define GOA_VSTV2  0x07
+#define GOA_VCLK1  0x0E
+#define GOA_VCLK2  0x17
+#define GOA_VCLK_OPT1  0x20
+#define GOA_BICLK1 0x2A
+#define GOA_BICLK2 0x37
+#define GOA_BICLK3 0x44
+#define GOA_BICLK4 0x4F
+#define GOA_BICLK_OPT1 0x5B
+#define GOA_BICLK_OPT2 0x60
+#define MCS_GOA_GPO1   0x6D
+#define MCS_GOA_GPO2   0x71
+#define MCS_GOA_EQ 0x74
+#define MCS_GOA_CLK_GALLON 0x7C
+#define MCS_GOA_FS_SEL00x7E
+#define MCS_GOA_FS_SEL10x87
+#define MCS_GOA_FS_SEL20x91
+#define MCS_GOA_FS_SEL30x9B
+#define MCS_GOA_BS_SEL00xAC
+#define MCS_GOA_BS_SEL10xB5
+#define MCS_GOA_BS_SEL20xBF
+#define MCS_GOA_BS_SEL30xC9
+#define MCS_GOA_BS_SEL40xD3
+
+/* CMD2 P3 commands (Gamma) */
+#define MCS_GAMMA_VP   0x60 /* Gamma VP1~VP16 */
+#define MCS_GAMMA_VN   0x70 /* Gamma VN1~VN16 */
+
+struct rm68200_panel_priv {
+   struct udevice *reg;
+   struct udevice *backlight;
+   struct gpio_desc reset;
+};
+
+static void rm68200_dcs_write_buf(struct udevice *dev, const void *data,
+ size_t len)
+{
+   struct mipi_dsi_panel_plat *plat = 

[PATCH v2 00/10] splash screen on the stm32f769 disco board

[yannick fertre]

Version 2:
- Replace debug log by pr_error, pr_warn or pr_info.
- Rework bridge between ltdc & dsi panel
- Rework backligh management (with or witout gpio)
- Rework panel otm8009a
- Add new panel raydium rm68200

Version 1:
- Initial commit

This serie contains all patchsets needed for displaying a splash screen 
on the stm32f769 disco board.

yannick fertre (10):
  video: stm32: stm32_ltdc: add bridge to display controller
  video: stm32: stm32_ltdc: update debug log
  video: add support of MIPI DSI interface
  video: add support of panel OTM8009A
  video: add MIPI DSI host controller bridge
  video: add support of STM32 MIPI DSI controller driver
  video: add support of panel rm68200
  arm: dts: stm32: add dsi for STM32F746
  arm: dts: stm32: add display for STM32F769 disco board
  board: Add STM32F769 SoC, discovery board support

 arch/arm/dts/stm32f746.dtsi|  12 +
 arch/arm/dts/stm32f769-disco.dts   |  71 
 configs/stm32f769-disco_defconfig  |  63 +++
 drivers/video/Kconfig  |  32 ++
 drivers/video/Makefile |   4 +
 drivers/video/dw_mipi_dsi.c| 822 +
 drivers/video/mipi_display.c   | 807 
 drivers/video/orisetech_otm8009a.c | 329 +++
 drivers/video/raydium-rm68200.c| 329 +++
 drivers/video/stm32/Kconfig|  10 +
 drivers/video/stm32/Makefile   |   1 +
 drivers/video/stm32/stm32_dsi.c| 427 +++
 drivers/video/stm32/stm32_ltdc.c   | 144 ---
 include/dw_mipi_dsi.h  |  32 ++
 include/mipi_display.h | 257 +++-
 15 files changed, 3285 insertions(+), 55 deletions(-)
 create mode 100644 configs/stm32f769-disco_defconfig
 create mode 100644 drivers/video/dw_mipi_dsi.c
 create mode 100644 drivers/video/mipi_display.c
 create mode 100644 drivers/video/orisetech_otm8009a.c
 create mode 100644 drivers/video/raydium-rm68200.c
 create mode 100644 drivers/video/stm32/stm32_dsi.c
 create mode 100644 include/dw_mipi_dsi.h

-- 
1.9.1

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

[PATCH v2 06/10] video: add support of STM32 MIPI DSI controller driver

[yannick fertre]

Add the STM32 DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/Kconfig |  10 +
 drivers/video/stm32/Makefile|   1 +
 drivers/video/stm32/stm32_dsi.c | 427 
 3 files changed, 438 insertions(+)
 create mode 100644 drivers/video/stm32/stm32_dsi.c

diff --git a/drivers/video/stm32/Kconfig b/drivers/video/stm32/Kconfig
index 113a2bb..2ea6f18 100644
--- a/drivers/video/stm32/Kconfig
+++ b/drivers/video/stm32/Kconfig
@@ -15,6 +15,16 @@ menuconfig VIDEO_STM32
  DSI. This option enables these supports which can be used on
  devices which have RGB TFT or DSI display connected.
 
+config VIDEO_STM32_DSI
+   bool "Enable STM32 DSI video support"
+   depends on VIDEO_STM32
+   select VIDEO_MIPI_DSI
+   select VIDEO_BRIDGE
+   select VIDEO_DW_MIPI_DSI
+   help
+ This option enables support DSI internal bridge which can be used on
+ devices which have DSI display connected.
+
 config VIDEO_STM32_MAX_XRES
int "Maximum horizontal resolution (for memory allocation purposes)"
depends on VIDEO_STM32
diff --git a/drivers/video/stm32/Makefile b/drivers/video/stm32/Makefile
index 372a2e1..f8c3ff7 100644
--- a/drivers/video/stm32/Makefile
+++ b/drivers/video/stm32/Makefile
@@ -8,3 +8,4 @@
 #
 
 obj-${CONFIG_VIDEO_STM32} = stm32_ltdc.o
+obj-${CONFIG_VIDEO_STM32_DSI} += stm32_dsi.o
diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c
new file mode 100644
index 000..3e26433
--- /dev/null
+++ b/drivers/video/stm32/stm32_dsi.c
@@ -0,0 +1,427 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *   Yannick Fertre  for STMicroelectronics.
+ *
+ * This driver is based on the mipi dsi driver from
+ * drivers/gpu/drm/stm/dw_mipi_dsi-stm.c (kernel linux).
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define HWVER_130  0x31333000  /* IP version 1.30 */
+#define HWVER_131  0x31333100  /* IP version 1.31 */
+
+/* DSI digital registers & bit definitions */
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+/*
+ * DSI wrapper registers & bit definitions
+ * Note: registers are named as in the Reference Manual
+ */
+#define DSI_WCFGR  0x0400  /* Wrapper ConFiGuration Reg */
+#define WCFGR_DSIM BIT(0)  /* DSI Mode */
+#define WCFGR_COLMUX   GENMASK(3, 1)   /* COLor MUltipleXing */
+
+#define DSI_WCR0x0404  /* Wrapper Control Reg */
+#define WCR_DSIEN  BIT(3)  /* DSI ENable */
+
+#define DSI_WISR   0x040C  /* Wrapper Interrupt and Status Reg */
+#define WISR_PLLLS BIT(8)  /* PLL Lock Status */
+#define WISR_RRS   BIT(12) /* Regulator Ready Status */
+
+#define DSI_WPCR0  0x0418  /* Wrapper Phy Conf Reg 0 */
+#define WPCR0_UIX4 GENMASK(5, 0)   /* Unit Interval X 4 */
+#define WPCR0_TDDL BIT(16) /* Turn Disable Data Lanes */
+
+#define DSI_WRPCR  0x0430  /* Wrapper Regulator & Pll Ctrl Reg */
+#define WRPCR_PLLENBIT(0)  /* PLL ENable */
+#define WRPCR_NDIV GENMASK(8, 2)   /* pll loop DIVision Factor */
+#define WRPCR_IDF  GENMASK(14, 11) /* pll Input Division Factor */
+#define WRPCR_ODF  GENMASK(17, 16) /* pll Output Division Factor */
+#define WRPCR_REGENBIT(24) /* REGulator ENable */
+#define WRPCR_BGRENBIT(28) /* BandGap Reference ENable */
+#define IDF_MIN1
+#define IDF_MAX7
+#define NDIV_MIN   10
+#define NDIV_MAX   125
+#define ODF_MIN1
+#define ODF_MAX8
+
+/* dsi color format coding according to the datasheet */
+enum dsi_color {
+   DSI_RGB565_CONF1,
+   DSI_RGB565_CONF2,
+   DSI_RGB565_CONF3,
+   DSI_RGB666_CONF1,
+   DSI_RGB666_CONF2,
+   DSI_RGB888,
+};
+
+#define LANE_MIN_KBPS  31250
+#define LANE_MAX_KBPS  50
+
+/* Timeout for regulator on/off, pll lock/unlock & fifo empty */
+#define TIMEOUT_US 20
+
+struct stm32_dsi_priv {
+   struct mipi_dsi_device device;
+   void __iomem *base;
+   struct udevice *panel;
+   u32 pllref_clk;
+   u32 hw_version;
+   int lane_min_kbps;
+   int lane_max_kbps;
+};
+
+static inline void dsi_write(struct stm32_dsi_priv *dsi, u32 reg, u32 val)
+{
+   writel(val, dsi->base + reg);
+}
+
+static inline u32 dsi_read(struct stm32_dsi_priv *dsi, u32 reg)
+{
+   return readl(dsi->base + reg);
+}
+
+static inline void 

[PATCH v2 04/10] video: add support of panel OTM8009A

[yannick fertre]

Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.

Signed-off-by: yannick fertre 
---
 drivers/video/Kconfig  |   8 +
 drivers/video/Makefile |   1 +
 drivers/video/orisetech_otm8009a.c | 329 +
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/video/orisetech_otm8009a.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1981298..b5fc535 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -320,6 +320,14 @@ config VIDEO_LCD_ANX9804
from a parallel LCD interface and translate it on the fy into a DP
interface for driving eDP TFT displays. It uses I2C for configuration.
 
+config VIDEO_LCD_ORISETECH_OTM8009A
+   bool "OTM8009A DSI LCD panel support"
+   depends on DM_VIDEO
+   select VIDEO_MIPI_DSI
+   default n
+   ---help---
+   Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
+
 config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 6f42cca..65002af 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_COREBOOT) += coreboot.o
 obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
 obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
+obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/orisetech_otm8009a.c 
b/drivers/video/orisetech_otm8009a.c
new file mode 100644
index 000..79f2da8
--- /dev/null
+++ b/drivers/video/orisetech_otm8009a.c
@@ -0,0 +1,329 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre  for STMicroelectronics.
+ *   Philippe Cornu  for STMicroelectronics.
+ *
+ * This otm8009a panel driver is based on the panel driver from
+ * drivers/gpu/drm/panel/panel-orisetech-otm8009a.c (kernel linux)
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DRV_NAME "orisetech_otm8009a"
+
+#define OTM8009A_BACKLIGHT_DEFAULT 240
+#define OTM8009A_BACKLIGHT_MAX 255
+
+/* Manufacturer Command Set */
+#define MCS_ADRSFT 0x  /* Address Shift Function */
+#define MCS_PANSET 0xB3A6  /* Panel Type Setting */
+#define MCS_SD_CTRL0xC0A2  /* Source Driver Timing Setting */
+#define MCS_P_DRV_M0xC0B4  /* Panel Driving Mode */
+#define MCS_OSC_ADJ0xC181  /* Oscillator Adjustment for Idle/Normal mode */
+#define MCS_RGB_VID_SET0xC1A1  /* RGB Video Mode Setting */
+#define MCS_SD_PCH_CTRL0xC480  /* Source Driver Precharge Control */
+#define MCS_NO_DOC10xC48A  /* Command not documented */
+#define MCS_PWR_CTRL1  0xC580  /* Power Control Setting 1 */
+#define MCS_PWR_CTRL2  0xC590  /* Power Control Setting 2 for Normal Mode */
+#define MCS_PWR_CTRL4  0xC5B0  /* Power Control Setting 4 for DC Voltage */
+#define MCS_PANCTRLSET10xCB80  /* Panel Control Setting 1 */
+#define MCS_PANCTRLSET20xCB90  /* Panel Control Setting 2 */
+#define MCS_PANCTRLSET30xCBA0  /* Panel Control Setting 3 */
+#define MCS_PANCTRLSET40xCBB0  /* Panel Control Setting 4 */
+#define MCS_PANCTRLSET50xCBC0  /* Panel Control Setting 5 */
+#define MCS_PANCTRLSET60xCBD0  /* Panel Control Setting 6 */
+#define MCS_PANCTRLSET70xCBE0  /* Panel Control Setting 7 */
+#define MCS_PANCTRLSET80xCBF0  /* Panel Control Setting 8 */
+#define MCS_PANU2D10xCC80  /* Panel U2D Setting 1 */
+#define MCS_PANU2D20xCC90  /* Panel U2D Setting 2 */
+#define MCS_PANU2D30xCCA0  /* Panel U2D Setting 3 */
+#define MCS_PAND2U10xCCB0  /* Panel D2U Setting 1 */
+#define MCS_PAND2U20xCCC0  /* Panel D2U Setting 2 */
+#define MCS_PAND2U30xCCD0  /* Panel D2U Setting 3 */
+#define MCS_GOAVST 0xCE80  /* GOA VST Setting */
+#define MCS_GOACLKA1   0xCEA0  /* GOA CLKA1 Setting */
+#define MCS_GOACLKA3   0xCEB0  /* GOA CLKA3 Setting */
+#define MCS_GOAECLK0xCFC0  /* GOA ECLK Setting */
+#define MCS_NO_DOC20xCFD0  /* Command not documented */
+#define MCS_GVDDSET0xD800  /* GVDD/NGVDD */
+#define MCS_VCOMDC 0xD900  /* VCOM Voltage Setting */
+#define MCS_GMCT2_2P   0xE100  /* Gamma Correction 2.2+ Setting */
+#define MCS_GMCT2_2N   0xE200  /* Gamma Correction 2.2- Setting */
+#define MCS_NO_DOC30xF5B6  /* Command not documented */
+#define MCS_CMD2_ENA1  0xFF00  /* Enable Access Command2 "CMD2" */
+#define MCS_CMD2_ENA2  0xFF80  /* Enable Access Orise Command2 */
+
+struct otm8009a_panel_priv {
+   struct udevice *reg;
+   struct 

[PATCH v2 01/10] video: stm32: stm32_ltdc: add bridge to display controller

[yannick fertre]

Manage a bridge insert between the display controller & a panel.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 107 ++-
 1 file changed, 71 insertions(+), 36 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index e160c77..bd9c0de 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -15,12 +16,12 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
 struct stm32_ltdc_priv {
void __iomem *regs;
-   struct display_timing timing;
enum video_log2_bpp l2bpp;
u32 bg_col_argb;
u32 crop_x, crop_y, crop_w, crop_h;
@@ -210,23 +211,23 @@ static void stm32_ltdc_enable(struct stm32_ltdc_priv 
*priv)
setbits_le32(priv->regs + LTDC_GCR, GCR_LTDCEN);
 }
 
-static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv)
+static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv,
+   struct display_timing *timings)
 {
void __iomem *regs = priv->regs;
-   struct display_timing *timing = >timing;
u32 hsync, vsync, acc_hbp, acc_vbp, acc_act_w, acc_act_h;
u32 total_w, total_h;
u32 val;
 
/* Convert video timings to ltdc timings */
-   hsync = timing->hsync_len.typ - 1;
-   vsync = timing->vsync_len.typ - 1;
-   acc_hbp = hsync + timing->hback_porch.typ;
-   acc_vbp = vsync + timing->vback_porch.typ;
-   acc_act_w = acc_hbp + timing->hactive.typ;
-   acc_act_h = acc_vbp + timing->vactive.typ;
-   total_w = acc_act_w + timing->hfront_porch.typ;
-   total_h = acc_act_h + timing->vfront_porch.typ;
+   hsync = timings->hsync_len.typ - 1;
+   vsync = timings->vsync_len.typ - 1;
+   acc_hbp = hsync + timings->hback_porch.typ;
+   acc_vbp = vsync + timings->vback_porch.typ;
+   acc_act_w = acc_hbp + timings->hactive.typ;
+   acc_act_h = acc_vbp + timings->vactive.typ;
+   total_w = acc_act_w + timings->hfront_porch.typ;
+   total_h = acc_act_h + timings->vfront_porch.typ;
 
/* Synchronization sizes */
val = (hsync << 16) | vsync;
@@ -248,14 +249,14 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv 
*priv)
 
/* Signal polarities */
val = 0;
-   debug("%s: timing->flags 0x%08x\n", __func__, timing->flags);
-   if (timing->flags & DISPLAY_FLAGS_HSYNC_HIGH)
+   debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
+   if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= GCR_HSPOL;
-   if (timing->flags & DISPLAY_FLAGS_VSYNC_HIGH)
+   if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
-   if (timing->flags & DISPLAY_FLAGS_DE_HIGH)
+   if (timings->flags & DISPLAY_FLAGS_DE_HIGH)
val |= GCR_DEPOL;
-   if (timing->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   if (timings->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
val |= GCR_PCPOL;
clrsetbits_le32(regs + LTDC_GCR,
GCR_HSPOL | GCR_VSPOL | GCR_DEPOL | GCR_PCPOL, val);
@@ -331,7 +332,11 @@ static int stm32_ltdc_probe(struct udevice *dev)
struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct stm32_ltdc_priv *priv = dev_get_priv(dev);
-   struct udevice *panel;
+#ifdef CONFIG_VIDEO_BRIDGE
+   struct udevice *bridge = NULL;
+#endif
+   struct udevice *panel = NULL;
+   struct display_timing timings;
struct clk pclk;
struct reset_ctl rst;
int rate, ret;
@@ -364,63 +369,93 @@ static int stm32_ltdc_probe(struct udevice *dev)
/* Reset */
reset_deassert();
 
-   ret = uclass_first_device(UCLASS_PANEL, );
+#ifdef CONFIG_VIDEO_BRIDGE
+   ret = uclass_get_device(UCLASS_VIDEO_BRIDGE, 0, );
if (ret) {
-   debug("%s: panel device error %d\n", __func__, ret);
-   return ret;
+   debug("%s: No video bridge, or no backlight on bridge\n",
+ __func__);
}
 
-   ret = panel_enable_backlight(panel);
+   if (bridge) {
+   ret = video_bridge_attach(bridge);
+   if (ret) {
+   debug("%s: fail to attach bridge\n", __func__);
+   return ret;
+   }
+   }
+#endif
+   ret = uclass_first_device(UCLASS_PANEL, );
if (ret) {
-   debug("%s: panel %s enable backlight error %d\n",
- __func__, panel->name, ret);
+   debug("%s: panel device error %d\n", __func__, ret);
return ret;
}
 
-   ret = fdtdec_decode_display_timing(gd->fdt_blob,
-  dev_of_offset(dev), 0,

[PATCH v2 08/10] arm: dts: stm32: add dsi for STM32F746

[yannick fertre]

Add mipi dsi bridge node in device-tree.

Signed-off-by: yannick fertre 
---
 arch/arm/dts/stm32f746.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index e4d32bf..4ec954d 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -332,6 +332,18 @@
u-boot,dm-pre-reloc;
status = "disabled";
};
+
+   dsi: dsi@40016c00 {
+   compatible = "st,stm32-dsi";
+   reg = <0x40016C00 0x800>;
+   resets = < STM32F7_APB2_RESET(DSI)>;
+   clocks =  < 0 STM32F7_APB2_CLOCK(DSI)>,
+ < 0 STM32F7_APB2_CLOCK(LTDC)>,
+ <_hse>;
+   clock-names = "pclk", "px_clk", "ref";
+   u-boot,dm-pre-reloc;
+   status = "disabled";
+   };
};
 };
 
-- 
1.9.1

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

[PATCH v2 03/10] video: add support of MIPI DSI interface

[yannick fertre]

Mipi_display.c contains a set of dsi helpers.
This file is a copy of file drm_mipi_dsi.c (linux kernel).

Signed-off-by: yannick fertre 
---
 drivers/video/Kconfig|   7 +
 drivers/video/Makefile   |   1 +
 drivers/video/mipi_display.c | 807 +++
 include/mipi_display.h   | 257 +-
 4 files changed, 1071 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/mipi_display.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2fc0def..1981298 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -75,6 +75,13 @@ config VIDEO_ANSI
  Enable ANSI escape sequence decoding for a more fully functional
  console.
 
+config VIDEO_MIPI_DSI
+   bool "Support MIPI DSI interface"
+   depends on DM_VIDEO
+   default y if DM_VIDEO
+   help
+ Support MIPI DSI interface for driving a MIPI compatible LCD panel.
+
 config CONSOLE_NORMAL
bool "Support a simple text console"
depends on DM_VIDEO
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index dfafe08..6f42cca 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
 obj-$(CONFIG_LG4573) += lg4573.o
 obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
 obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
 obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
 obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
 obj-${CONFIG_EXYNOS_FB} += exynos/
diff --git a/drivers/video/mipi_display.c b/drivers/video/mipi_display.c
new file mode 100644
index 000..d90ff5d
--- /dev/null
+++ b/drivers/video/mipi_display.c
@@ -0,0 +1,807 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012-2013, Samsung Electronics, Co., Ltd.
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Andrzej Hajda 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: dsi helpers
+ *
+ * These functions contain some common logic and helpers to deal with MIPI DSI
+ * peripherals.
+ *
+ * Helpers are provided for a number of standard MIPI DSI command as well as a
+ * subset of the MIPI DCS command set.
+ */
+
+/**
+ * mipi_dsi_attach - attach a DSI device to its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_attach(struct mipi_dsi_device *dsi)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->attach)
+   return -ENOSYS;
+
+   return ops->attach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_attach);
+
+/**
+ * mipi_dsi_detach - detach a DSI device from its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_detach(struct mipi_dsi_device *dsi)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->detach)
+   return -ENOSYS;
+
+   return ops->detach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_detach);
+
+static ssize_t mipi_dsi_device_transfer(struct mipi_dsi_device *dsi,
+   struct mipi_dsi_msg *msg)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->transfer)
+   return -ENOSYS;
+
+   if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+   msg->flags |= MIPI_DSI_MSG_USE_LPM;
+
+   return ops->transfer(dsi->host, msg);
+}
+
+/**
+ * mipi_dsi_packet_format_is_short - check if a packet is of the short format
+ * @type: MIPI DSI data type of the packet
+ *
+ * Return: true if the packet for the given data type is a short packet, false
+ * otherwise.
+ */
+bool mipi_dsi_packet_format_is_short(u8 type)
+{
+   switch (type) {
+   case MIPI_DSI_V_SYNC_START:
+   case MIPI_DSI_V_SYNC_END:
+   case MIPI_DSI_H_SYNC_START:
+   case MIPI_DSI_H_SYNC_END:
+

Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express

[Liviu Dudau]

On Fri, Mar 02, 2018 at 01:50:20PM +, Robin Murphy wrote:
> On 02/03/18 12:37, Linus Walleij wrote:
> > On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy  wrote:
> > > On 02/03/18 09:09, Linus Walleij wrote:
> > 
> > > > Also the Versatile Express CLCD on the motherboard has
> > > > a dedicated video memory, and cannot use CMA (ha! complex!)
> > > > and I will need to figure out a way to work around that.
> > > > The CLCDs synthesized on the core tiles for CA9 work
> > > > fine with this though.
> > > 
> > > Out of curiosity, what's the issue with declaring the VRAM as a CMA 
> > > region?
> > > That's certainly worked for stuff like local RAM on FPGA tiles in the 
> > > past,
> > > and I can't think offhand of any way in which VExpress is wildly different
> > > (but I am of course open to being wrong...)
> > 
> > There is nothing wrong with that apart from my ignorance
> > of that solution. So thanks! :D
> > 
> > My experience with CMA is limited to using the 7 areas
> > that are defined by default in Kconfig and the DRM helpers
> > just plugging in on the front.
> > 
> > Do you have some pointers? Is this something I can
> > handily just set up in the device tree?
> 
> It should be - the inner workings of dma-{coherent,contiguous} are a maze of
> twisty little passages, all alike, and it'll take me a while to page the
> details back in, but IIRC it's mostly just a case of having a
> reserved-memory node covering the VRAM with the right combination of magic
> properties for rmem_dma_setup() to pick up, such that it gets assigned as
> the CLCD's private region. The subsequent "just plugging in" aspect doesn't
> change, it just makes allocations start taking this route under the covers:
> 
>   drm_gem_cma_create()
> dma_alloc_wc()
>   dma_alloc_attrs()
> dma_alloc_from_dev_coherent()
> 
> I could have sworn I've exchanged relevant FPGA DT fragments with Liviu in
> the past, but now I can't seem to find one to refer back to :(

Maybe something line this:
https://github.com/ARM-software/linux/blob/development/malidp/arch/arm64/boot/dts/arm/juno-base.dtsi#L792

And look at line 855 for the possible use of it.

That is how we currently make CMA allocate buffers in FPGA for the Mali
DP "hardware" (bitstream on FPGA) that we have in Juno.

Best regards,
Liviu

> 
> Robin.

-- 

| 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

[Bug 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

--- Comment #10 from tempel.jul...@gmail.com ---
I thought of something similar too. But I'm far away from 330Mhz pixel clock.
I'm just using LCD standard timings, which result in a pixel clock of
304.37MHz:
https://abload.de/img/75hzhgs1d.png

I also had the suspicion that the magic 300Mhz mark might be a problem, so I
created a resolution with custom timings for 74Hz which resulted in ~295MHz,
but the issue was still the same. It seems like it's really just about the
refresh rate and not the timings or pixelclock.

-- 
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 105302] [DC] - Maximum pixel clock of dual-link DVI too low for some modes

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #5 from Alex Deucher  ---
I'd rather not support running things out of spec in the driver.  The source is
open.  If you want to adjust the code allow something like that you can.

-- 
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 v1 2/2] drm/panel: Add support for Raydium rm68200 panel driver

[Philippe CORNU]

Hi Thierry,

A big thank you for your code review and comments.
It helped me to improve the driver and to send a v2.

Philippe :-)

On 02/28/2018 08:16 PM, Thierry Reding wrote:
> On Thu, Feb 08, 2018 at 03:30:26PM +0100, Philippe Cornu wrote:
>> This patch adds Raydium Semiconductor Corporation rm68200
>> 5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode).
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>   drivers/gpu/drm/panel/Kconfig |   8 +
>>   drivers/gpu/drm/panel/Makefile|   1 +
>>   drivers/gpu/drm/panel/panel-raydium-rm68200.c | 464 
>> ++
>>   3 files changed, 473 insertions(+)
>>   create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 988048ebcc22..08d99dd46765 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -108,6 +108,14 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
>>Pi 7" Touchscreen.  To compile this driver as a module,
>>choose M here.
>>   
>> +config DRM_PANEL_RAYDIUM_RM68200
>> +tristate "Raydium rm68200 720x1280 dsi 2dl video mode panel"
> 
> What's 2dl? Either this is something already implied by the RM68200
> model or if there are multiple variants of the RM68200 you'll probably
> want to ensure that's reflected in the compatible string.
> 
>> +depends on OF
>> +depends on DRM_MIPI_DSI
>> +help
>> +  Say Y here if you want to enable support for Raydium rm68200
>> +  720x1280 dsi 2dl video mode panel
>> +
>>   config DRM_PANEL_SAMSUNG_S6E3HA2
>>  tristate "Samsung S6E3HA2 DSI video mode panel"
>>  depends on OF
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index 3d2a88d0e965..f26efc11d746 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>>   obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
>>   obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
>> panel-panasonic-vvx10f034n00.o
>>   obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
>> panel-raspberrypi-touchscreen.o
>> +obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
>>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
>> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c 
>> b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
>> new file mode 100755
>> index ..f3e15873d05a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
>> @@ -0,0 +1,464 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) STMicroelectronics SA 2017
>> + *
>> + * Authors: Philippe Cornu 
>> + *  Yannick Fertre 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define DRV_NAME "raydium_rm68200"
> 
> Not needed, see below.
> 
>> +
>> +/*** Manufacturer Command Set ***/
>> +#define MCS_CMD_MODE_SW 0xFE /* CMD Mode Switch */
>> +#define MCS_CMD1_UCS0x00 /* User Command Set (UCS = CMD1) */
>> +#define MCS_CMD2_P0 0x01 /* Manufacture Command Set Page0 (CMD2 P0) */
>> +#define MCS_CMD2_P1 0x02 /* Manufacture Command Set Page1 (CMD2 P1) */
>> +#define MCS_CMD2_P2 0x03 /* Manufacture Command Set Page2 (CMD2 P2) */
>> +#define MCS_CMD2_P3 0x04 /* Manufacture Command Set Page3 (CMD2 P3) */
>> +
>> +/* CMD2 P0 commands (Display Options and Power) */
>> +#define MCS_STBCTR  0x12 /* TE1 Output Setting Zig-Zag Connection */
>> +#define MCS_SGOPCTR 0x16 /* Source Bias Current */
>> +#define MCS_SDCTR   0x1A /* Source Output Delay Time */
>> +#define MCS_INVCTR  0x1B /* Inversion Type */
>> +#define MCS_EXT_PWR_IC  0x24 /* External PWR IC Control */
>> +#define MCS_SETAVDD 0x27 /* PFM Control for AVDD Output */
>> +#define MCS_SETAVEE 0x29 /* PFM Control for AVEE Output */
>> +#define MCS_BT2CTR  0x2B /* DDVDL Charge Pump Control */
>> +#define MCS_BT3CTR  0x2F /* VGH Charge Pump Control */
>> +#define MCS_BT4CTR  0x34 /* VGL Charge Pump Control */
>> +#define MCS_VCMCTR  0x46 /* VCOM Output Level Control */
>> +#define MCS_SETVGN  0x52 /* VG M/S N Control */
>> +#define MCS_SETVGP  0x54 /* VG M/S P Control */
>> +#define MCS_SW_CTRL 0x5F /* Interface Control for PFM and MIPI */
>> +
>> +/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
>> +#define GOA_VSTV1   0x00
>> +#define GOA_VSTV2   0x07
>> +#define GOA_VCLK1   0x0E
>> +#define GOA_VCLK2   0x17
>> +#define GOA_VCLK_OPT1   0x20
>> +#define GOA_BICLK1  0x2A
>> +#define GOA_BICLK2  0x37
>> +#define GOA_BICLK3  0x44
>> +#define GOA_BICLK4  0x4F
>> +#define GOA_BICLK_OPT1  0x5B
>> 

[PATCH v2 1/2] dt-bindings/display/panel: Add support for Raydium rm68200 dsi panel

[Philippe Cornu]

The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
TFT LCD panel connected using a MIPI-DSI video interface.

Reviewed-by: Rob Herring 
Signed-off-by: Philippe Cornu 
---
 .../bindings/display/panel/raydium,rm68200.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt 
b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
new file mode 100644
index ..cbb79ef3bfc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
@@ -0,0 +1,25 @@
+Raydium Semiconductor Corporation RM68200 5.5" 720p MIPI-DSI TFT LCD panel
+
+The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
+panel connected using a MIPI-DSI video interface.
+
+Required properties:
+  - compatible: "raydium,rm68200"
+  - reg: the virtual channel number of a DSI peripheral
+
+Optional properties:
+  - reset-gpios: a GPIO spec for the reset pin (active low).
+  - power-supply: phandle of the regulator that provides the supply voltage.
+  - backlight: phandle of the backlight device attached to the panel.
+
+Example:
+ {
+   ...
+   panel@0 {
+   compatible = "raydium,rm68200";
+   reg = <0>;
+   reset-gpios = < 15 GPIO_ACTIVE_LOW>;
+   power-supply = <>;
+   backlight = <_backlight>;
+   };
+};
-- 
2.15.1

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

[PATCH v2 2/2] drm/panel: Add support for Raydium RM68200 panel driver

[Philippe Cornu]

This patch adds Raydium Semiconductor Corporation RM68200
5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode).

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/panel/Kconfig |   8 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-raydium-rm68200.c | 437 ++
 3 files changed, 446 insertions(+)
 create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 988048ebcc22..a30eb7a2f8e2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -108,6 +108,14 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
  Pi 7" Touchscreen.  To compile this driver as a module,
  choose M here.
 
+config DRM_PANEL_RAYDIUM_RM68200
+   tristate "Raydium RM68200 720x1280 dsi video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Raydium RM68200
+ 720x1280 dsi video mode panel
+
 config DRM_PANEL_SAMSUNG_S6E3HA2
tristate "Samsung S6E3HA2 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3d2a88d0e965..f26efc11d746 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c 
b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
new file mode 100755
index ..35d75148ca08
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
@@ -0,0 +1,437 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu 
+ *  Yannick Fertre 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*** Manufacturer Command Set ***/
+#define MCS_CMD_MODE_SW0xFE /* CMD Mode Switch */
+#define MCS_CMD1_UCS   0x00 /* User Command Set (UCS = CMD1) */
+#define MCS_CMD2_P00x01 /* Manufacture Command Set Page0 (CMD2 P0) */
+#define MCS_CMD2_P10x02 /* Manufacture Command Set Page1 (CMD2 P1) */
+#define MCS_CMD2_P20x03 /* Manufacture Command Set Page2 (CMD2 P2) */
+#define MCS_CMD2_P30x04 /* Manufacture Command Set Page3 (CMD2 P3) */
+
+/* CMD2 P0 commands (Display Options and Power) */
+#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */
+#define MCS_SGOPCTR0x16 /* Source Bias Current */
+#define MCS_SDCTR  0x1A /* Source Output Delay Time */
+#define MCS_INVCTR 0x1B /* Inversion Type */
+#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */
+#define MCS_SETAVDD0x27 /* PFM Control for AVDD Output */
+#define MCS_SETAVEE0x29 /* PFM Control for AVEE Output */
+#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */
+#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */
+#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */
+#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */
+#define MCS_SETVGN 0x52 /* VG M/S N Control */
+#define MCS_SETVGP 0x54 /* VG M/S P Control */
+#define MCS_SW_CTRL0x5F /* Interface Control for PFM and MIPI */
+
+/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
+#define GOA_VSTV1  0x00
+#define GOA_VSTV2  0x07
+#define GOA_VCLK1  0x0E
+#define GOA_VCLK2  0x17
+#define GOA_VCLK_OPT1  0x20
+#define GOA_BICLK1 0x2A
+#define GOA_BICLK2 0x37
+#define GOA_BICLK3 0x44
+#define GOA_BICLK4 0x4F
+#define GOA_BICLK_OPT1 0x5B
+#define GOA_BICLK_OPT2 0x60
+#define MCS_GOA_GPO1   0x6D
+#define MCS_GOA_GPO2   0x71
+#define MCS_GOA_EQ 0x74
+#define MCS_GOA_CLK_GALLON 0x7C
+#define MCS_GOA_FS_SEL00x7E
+#define MCS_GOA_FS_SEL10x87
+#define MCS_GOA_FS_SEL20x91
+#define MCS_GOA_FS_SEL30x9B
+#define MCS_GOA_BS_SEL00xAC
+#define MCS_GOA_BS_SEL10xB5
+#define MCS_GOA_BS_SEL20xBF
+#define MCS_GOA_BS_SEL30xC9
+#define MCS_GOA_BS_SEL40xD3
+
+/* CMD2 P3 commands (Gamma) */
+#define MCS_GAMMA_VP   0x60 /* Gamma VP1~VP16 */
+#define MCS_GAMMA_VN   0x70 /* Gamma VN1~VN16 */
+
+struct rm68200 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct gpio_desc *reset_gpio;
+   struct regulator *supply;
+ 

[PATCH v2 0/2] drm/panel: Add support for Raydium RM68200 panel

[Philippe Cornu]

The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
TFT LCD panel connected using a MIPI-DSI video interface.

Version 2:
- Add Rob Herring Reviewed-by on dt-bindings.
- Update Kconfig & driver thanks to Thierry Reding comments: no more
  DRV_NAME, DRM_WARN_ONCE instead of DRV_NAME where applicable, use
  backlight_enable/disable() & devm_of_find_backlight(), no extra
  gpio reset to 0, no more msg if successful, use RM68200 instead of
  rm68200 where necessary.

Version 1:
- Initial commit

Philippe Cornu (2):
  dt-bindings/display/panel: Add support for Raydium rm68200 dsi panel
  drm/panel: Add support for Raydium RM68200 panel driver

 .../bindings/display/panel/raydium,rm68200.txt |  25 ++
 drivers/gpu/drm/panel/Kconfig  |   8 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-raydium-rm68200.c  | 437 +
 4 files changed, 471 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
 create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c

-- 
2.15.1

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

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Ville Syrjälä]

On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote:
> Hey Ville,
> 
> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä
>  wrote:
> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote:
> >> If you want the plane to always be opaque you shouldn't expose any
> >> formats with alpha.
> >>
> >> Also what happens if one disables the primary plane? Or does the driver
> >> not allow that?
> >
> > Or just makes the plane not cover the entire screen?
> 
> We've exposed alpha formats in the past so disabling that now would break
> userspace, certainly Android that chooses alpha-everything.

So it refuses to even run on hardware that can't do per-pixel alpha on
the primary plane?

> The VC4 HVS
> has no fixed planes so I'll acknowledge that the concept of a primary plane
> is somewhat dubious and userspace could disable it or make it not cover the
> entire screen, making this ineffective.
> 
> But then ultimately there doesn't seem to be a standard for what the display
> is supposed to be if you have transparent pixels with no plane to blend to
> below.

The standard is black. IMO it's a driver bug if it fails to do that.

> This helps in the common case, the belts fix would be to
> enable the VC4 HVS background color fill incurring a fixed overhead that
> in most cases is wasted because the composition ends up being opaque.
> 
> Thanks,
> Stefan

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

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Stefan Schake]

Hey Ville,

On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä
 wrote:
> On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote:
>> If you want the plane to always be opaque you shouldn't expose any
>> formats with alpha.
>>
>> Also what happens if one disables the primary plane? Or does the driver
>> not allow that?
>
> Or just makes the plane not cover the entire screen?

We've exposed alpha formats in the past so disabling that now would break
userspace, certainly Android that chooses alpha-everything. The VC4 HVS
has no fixed planes so I'll acknowledge that the concept of a primary plane
is somewhat dubious and userspace could disable it or make it not cover the
entire screen, making this ineffective.

But then ultimately there doesn't seem to be a standard for what the display
is supposed to be if you have transparent pixels with no plane to blend to
below. This helps in the common case, the belts fix would be to
enable the VC4 HVS background color fill incurring a fixed overhead that
in most cases is wasted because the composition ends up being opaque.

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

[Bug 105302] [DC] - Maximum pixel clock of dual-link DVI too low for some modes

[bugzilla-daemon]

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

--- Comment #4 from Harry Wentland  ---
This sounds like a feature request, rather than a bug.

-- 
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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

--- Comment #9 from Harry Wentland  ---
Are you messing with TMDS_MAX_PIXEL_CLOCK as Andrew is doing in this ticket:
https://bugs.freedesktop.org/show_bug.cgi?id=105302 ?

With DC clock switching might happen more aggressively which could explain the
underflow you're seeing.

-- 
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: [DPU PATCH 06/11] drm/msm: Remove msm_commit/kthread, use atomic helper commit

[Sean Paul]

On Thu, Mar 01, 2018 at 07:37:10PM -0500, Rob Clark wrote:
> On Thu, Mar 1, 2018 at 3:37 PM,   wrote:
> > On 2018-03-01 07:27, Sean Paul wrote:
> >>
> >> On Wed, Feb 28, 2018 at 08:07:00PM -0800, jsa...@codeaurora.org wrote:
> >>>
> >>> On 2018-02-28 11:19, Sean Paul wrote:
> >>> > Moving further towards switching fully to the the atomic helpers, this
> >>> > patch removes the hand-rolled kthread nonblock commit code and uses
> >>
> >> the
> >>>
> >>> > atomic helpers commit_work model.
> >>> >
> >>> > There's still a lot of copypasta here, but it's still needed to
> >>> > facilitate the swap_state and prepare_fence private functions. These
> >>> > will be sorted out in a follow-on patch.
> >>> >
> >>> > Change-Id: I9fcba27824ba63d3fab96cb2bc194bfa6f3475b7
> >>> > Signed-off-by: Sean Paul 
> >>> > ---
> >>> >  drivers/gpu/drm/msm/msm_atomic.c | 199
> >>
> >> ++-
> >>>
> >>> >  drivers/gpu/drm/msm/msm_drv.c|   1 -
> >>> >  drivers/gpu/drm/msm/msm_drv.h|   4 -
> >>> >  3 files changed, 35 insertions(+), 169 deletions(-)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> >>> > b/drivers/gpu/drm/msm/msm_atomic.c
> >>> > index 3a18bd3dc215..7e54eb65d096 100644
> >>> > --- a/drivers/gpu/drm/msm/msm_atomic.c
> >>> > +++ b/drivers/gpu/drm/msm/msm_atomic.c
> >>> > @@ -21,51 +21,6 @@
> >>> >  #include "msm_gem.h"
> >>> >  #include "msm_fence.h"
> >>> >
> >>> > -struct msm_commit {
> >>> > - struct drm_device *dev;
> >>> > - struct drm_atomic_state *state;
> >>> > - uint32_t crtc_mask;
> >>> > - bool nonblock;
> >>> > - struct kthread_work commit_work;
> >>> > -};
> >>> > -
> >>> > -/* block until specified crtcs are no longer pending update, and
> >>> > - * atomically mark them as pending update
> >>> > - */
> >>> > -static int start_atomic(struct msm_drm_private *priv, uint32_t
> >>> > crtc_mask)
> >>> > -{
> >>> > - int ret;
> >>> > -
> >>> > - spin_lock(>pending_crtcs_event.lock);
> >>> > - ret = wait_event_interruptible_locked(priv->pending_crtcs_event,
> >>> > - !(priv->pending_crtcs & crtc_mask));
> >>> > - if (ret == 0) {
> >>> > - DBG("start: %08x", crtc_mask);
> >>> > - priv->pending_crtcs |= crtc_mask;
> >>> > - }
> >>> > - spin_unlock(>pending_crtcs_event.lock);
> >>> > -
> >>> > - return ret;
> >>> > -}
> >>> > -
> >>> > -/* clear specified crtcs (no longer pending update)
> >>> > - */
> >>> > -static void end_atomic(struct msm_drm_private *priv, uint32_t
> >>> > crtc_mask)
> >>> > -{
> >>> > - spin_lock(>pending_crtcs_event.lock);
> >>> > - DBG("end: %08x", crtc_mask);
> >>> > - priv->pending_crtcs &= ~crtc_mask;
> >>> > - wake_up_all_locked(>pending_crtcs_event);
> >>> > - spin_unlock(>pending_crtcs_event.lock);
> >>> > -}
> >>> > -
> >>> > -static void commit_destroy(struct msm_commit *c)
> >>> > -{
> >>> > - end_atomic(c->dev->dev_private, c->crtc_mask);
> >>> > - if (c->nonblock)
> >>> > - kfree(c);
> >>> > -}
> >>> > -
> >>> >  static void msm_atomic_wait_for_commit_done(
> >>> >   struct drm_device *dev,
> >>> >   struct drm_atomic_state *old_state)
> >>> > @@ -118,6 +73,10 @@ static void msm_atomic_commit_tail(struct
> >>> > drm_atomic_state *state)
> >>> >
> >>> >   msm_atomic_wait_for_commit_done(dev, state);
> >>> >
> >>> > + drm_atomic_helper_commit_hw_done(state);
> >>> > +
> >>> > + drm_atomic_helper_wait_for_vblanks(dev, state);
> >>> > +
> >>> >   drm_atomic_helper_cleanup_planes(dev, state);
> >>> >
> >>> >   kms->funcs->complete_commit(kms, state);
> >>> > @@ -126,109 +85,25 @@ static void msm_atomic_commit_tail(struct
> >>> > drm_atomic_state *state)
> >>> >  /* The (potentially) asynchronous part of the commit.  At this point
> >>> >   * nothing can fail short of armageddon.
> >>> >   */
> >>> > -static void complete_commit(struct msm_commit *c)
> >>> > +static void commit_tail(struct drm_atomic_state *state)
> >>> >  {
> >>> > - struct drm_atomic_state *state = c->state;
> >>> > - struct drm_device *dev = state->dev;
> >>> > + drm_atomic_helper_wait_for_fences(state->dev, state, false);
> >>> >
> >>> > - drm_atomic_helper_wait_for_fences(dev, state, false);
> >>> > + drm_atomic_helper_wait_for_dependencies(state);
> >>> >
> >>> >   msm_atomic_commit_tail(state);
> >>> >
> >>> > - drm_atomic_state_put(state);
> >>> > -}
> >>> > -
> >>> > -static void _msm_drm_commit_work_cb(struct kthread_work *work)
> >>> > -{
> >>> > - struct msm_commit *commit =  NULL;
> >>> > -
> >>> > - if (!work) {
> >>> > - DRM_ERROR("%s: Invalid commit work data!\n", __func__);
> >>> > - return;
> >>> > - }
> >>> > -
> >>> > - commit = container_of(work, struct msm_commit, commit_work);
> >>> > -
> >>> > - complete_commit(commit);
> >>> > -
> >>> > - 

Re: [PATCH 01/14] iommu: Add DOMAIN_ATTR_ENABLE_TTBR1

[Robin Murphy]

On 21/02/18 22:59, Jordan Crouse wrote:

Add a new domain attribute to enable the TTBR1 pagetable for drivers
and devices that support it.  This will enabled using a TTBR1 (otherwise
known as a "global" or "system" pagetable for devices that support a split
pagetable scheme for switching pagetables quickly and safely.


TTBR1 is very much an Arm VMSA-specific term; if the concept of a split 
address space is useful in general, is it worth trying to frame it in 
general terms? AFAICS other IOMMU drivers could achieve the same effect 
fairly straightforwardly by simply copying the top-level "global" 
entries across whenever they switch "private" tables.


FWIW even for SMMU there could potentially be cases with Arm Ltd. IP 
where the SoC vendor implements a stage-2-only configuration in their 
media subsystem, because they care most about minimising area and 
stage-1-only isn't an option.


Robin.


Signed-off-by: Jordan Crouse 
---
  include/linux/iommu.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 641aaf0f1b81..e2c49e583d8d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -153,6 +153,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMU_ENABLE,
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
+   DOMAIN_ATTR_ENABLE_TTBR1,
DOMAIN_ATTR_MAX,
  };
  


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

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Ville Syrjälä]

On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 02, 2018 at 01:32:40AM +0100, Stefan Schake wrote:
> > We allow alpha formats on the primary plane but a partially transparent
> > framebuffer will cause a corrupted display. With this change black pixels
> > are output instead, in line with the behavior for other DRM drivers.
> > 
> > Signed-off-by: Stefan Schake 
> > ---
> > Test program is available at https://github.com/stschake/vc4-alpha-test
> > 
> >  drivers/gpu/drm/vc4/vc4_plane.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
> > b/drivers/gpu/drm/vc4/vc4_plane.c
> > index 61ad955..8c829fa 100644
> > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > @@ -521,6 +521,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> > u32 ctl0_offset = vc4_state->dlist_count;
> > const struct hvs_format *format = 
> > vc4_get_hvs_format(fb->format->format);
> > int num_planes = drm_format_num_planes(format->drm);
> > +   bool primary_plane = state->crtc->primary == plane;
> > u32 scl0, scl1, pitch0;
> > u32 lbm_size, tiling;
> > unsigned long irqflags;
> > @@ -620,8 +621,12 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> >  
> > /* Position Word 2: Source Image Size, Alpha Mode */
> > vc4_state->pos2_offset = vc4_state->dlist_count;
> > +   /* We do not enable the HVS background color fill so the primary plane
> > +* must be opaque to avoid display artifacts. Achieve this by always
> > +* using fixed alpha (initialized to 0xff above) on the primary plane.
> > +*/
> > vc4_dlist_write(vc4_state,
> > -   VC4_SET_FIELD(fb->format->has_alpha ?
> > +   VC4_SET_FIELD(fb->format->has_alpha && !primary_plane ?
> 
> If you want the plane to always be opaque you shouldn't expose any
> formats with alpha.
> 
> Also what happens if one disables the primary plane? Or does the driver
> not allow that?

Or just makes the plane not cover the entire screen?

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

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Ville Syrjälä]

On Fri, Mar 02, 2018 at 01:32:40AM +0100, Stefan Schake wrote:
> We allow alpha formats on the primary plane but a partially transparent
> framebuffer will cause a corrupted display. With this change black pixels
> are output instead, in line with the behavior for other DRM drivers.
> 
> Signed-off-by: Stefan Schake 
> ---
> Test program is available at https://github.com/stschake/vc4-alpha-test
> 
>  drivers/gpu/drm/vc4/vc4_plane.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 61ad955..8c829fa 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -521,6 +521,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
>   u32 ctl0_offset = vc4_state->dlist_count;
>   const struct hvs_format *format = 
> vc4_get_hvs_format(fb->format->format);
>   int num_planes = drm_format_num_planes(format->drm);
> + bool primary_plane = state->crtc->primary == plane;
>   u32 scl0, scl1, pitch0;
>   u32 lbm_size, tiling;
>   unsigned long irqflags;
> @@ -620,8 +621,12 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
>  
>   /* Position Word 2: Source Image Size, Alpha Mode */
>   vc4_state->pos2_offset = vc4_state->dlist_count;
> + /* We do not enable the HVS background color fill so the primary plane
> +  * must be opaque to avoid display artifacts. Achieve this by always
> +  * using fixed alpha (initialized to 0xff above) on the primary plane.
> +  */
>   vc4_dlist_write(vc4_state,
> - VC4_SET_FIELD(fb->format->has_alpha ?
> + VC4_SET_FIELD(fb->format->has_alpha && !primary_plane ?

If you want the plane to always be opaque you shouldn't expose any
formats with alpha.

Also what happens if one disables the primary plane? Or does the driver
not allow that?

> SCALER_POS2_ALPHA_MODE_PIPELINE :
> SCALER_POS2_ALPHA_MODE_FIXED,
> SCALER_POS2_ALPHA_MODE) |
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 2/2] drm/sun4i: add lvds mode_valid function

[Maxime Ripard]

On Fri, Mar 02, 2018 at 12:42:14PM +0100, Giulio Benetti wrote:
> Hi,
> 
> Il 01/03/2018 10:57, Maxime Ripard ha scritto:
> > On Wed, Feb 28, 2018 at 06:53:52PM +0100, Giulio Benetti wrote:
> > >   static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
> > >   .get_modes  = sun4i_lvds_get_modes,
> > > + .mode_valid = sun4i_lvds_mode_valid,
> > >   };
> > 
> > This should be on the encoder, not the connector.
> 
> I've seen it is bound to connector in rgb and to encoder in hdmi.
> Is it correct rgb mode_valid under connector funcs?
> Otherwise I send a patch also for that one.

This would need to be fixed as well. Bridges attach to encoder, not
connectors, so if you ever have a bridge connected to the RGB output
(like on the A13-Olinuxino), mode_valid isn't called at the moment.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

[Robert Foss]

Ack, thanks for the heads up!


Rob.

On 03/02/2018 01:41 AM, Stefan Schake wrote:

Hey Rob,

On Wed, Feb 28, 2018 at 11:53 AM, Robert Foss  wrote:

Hey,

Stefan: Are you looking at an entirely kernel side fix now, or are you
pushing this series forward?


I've sent out a kernel side fix for this:

https://patchwork.freedesktop.org/patch/207667/

So I guess for now this can be dropped, pending review.

Thanks,
Stefan
___
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

[Patch 0/4] drm/omap: Add virtual-planes support

[Benoit Parrot]

This patch series adds virtual-plane support to omapdrm driver
to allow the use of display wider than 2048 pixels.

The DT bindings are also cleaned up to remove duplication when
properties are common to all implementations.

Benoit Parrot (4):
  dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt
  dt-bindings: display/ti: Add plane binding to dispc node
  drm/omap: Add virtual plane DT parsing support
  drm/omap: Add virtual plane support to omap_plane

 .../devicetree/bindings/display/ti/ti,dra7-dss.txt |   5 -
 .../devicetree/bindings/display/ti/ti,omap-dss.txt |  70 +++
 .../bindings/display/ti/ti,omap2-dss.txt   |   4 -
 .../bindings/display/ti/ti,omap3-dss.txt   |   4 -
 .../bindings/display/ti/ti,omap4-dss.txt   |   4 -
 .../bindings/display/ti/ti,omap5-dss.txt   |   4 -
 drivers/gpu/drm/omapdrm/dss/dispc.c| 110 
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  11 ++
 drivers/gpu/drm/omapdrm/omap_drv.c |  18 ++-
 drivers/gpu/drm/omapdrm/omap_fb.c  |  66 ++
 drivers/gpu/drm/omapdrm/omap_fb.h  |   4 +-
 drivers/gpu/drm/omapdrm/omap_plane.c   | 139 +++--
 drivers/gpu/drm/omapdrm/omap_plane.h   |   3 +-
 13 files changed, 353 insertions(+), 89 deletions(-)

-- 
2.9.0

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

[Patch 3/4] drm/omap: Add virtual plane DT parsing support

[Benoit Parrot]

Virtual planes are used to extend display size capability for display
larger than 2048 pixels by splitting the frame buffer equally between
two physical planes.

Here we are adding DT support to parse 'plane' child nodes which
describe how logical planes are mapped to physical plane(s) and
which crtc they are available on.

Signed-off-by: Benoit Parrot 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 110 ++
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  11 
 2 files changed, 121 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 624dee22f46b..559b70d9762d 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -4334,6 +4334,115 @@ static u32 dispc_get_memory_bandwidth_limit(void)
return limit;
 }
 
+static struct device_node *dispc_of_get_plane_by_id(struct device_node *node,
+   u32 id)
+{
+   struct device_node *plane;
+
+   for_each_child_of_node(node, plane) {
+   u32 plane_id = 0;
+
+   if (of_node_cmp(plane->name, "plane") != 0)
+   continue;
+   of_property_read_u32(plane, "reg", _id);
+   if (id == plane_id)
+   break;
+   }
+
+   return plane;
+}
+
+static int dispc_parse_dt_plane_data(struct dispc_plane_mappings *plane)
+{
+   struct platform_device *pdev = dispc.pdev;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *ep;
+   struct property *prop;
+   const __be32 *cur;
+   u32 v;
+   u32 num_ovls = dispc_get_num_ovls();
+   unsigned long int hw_plane_mask = (1 << num_ovls) - 1;
+   u32 num_planes;
+   int i, index;
+
+   if (!np)
+   return 0;
+
+   for (i = 0; i < num_ovls; i++) {
+   ep = dispc_of_get_plane_by_id(np, i);
+   if (!ep)
+   break;
+   if (!of_property_read_bool(ep, "hw-planes")) {
+   dev_err(>dev,
+   "malformed plane node: hw-planes missing.\n");
+   return -EINVAL;
+   }
+
+   index = 0;
+   of_property_for_each_u32(ep, "hw-planes", prop, cur, v) {
+   if (v >= num_ovls) {
+   dev_err(>dev,
+   "hw-planes property: '%d' 
out-of-range.\n",
+   v);
+   return -EINVAL;
+   }
+   if (!(hw_plane_mask & BIT_MASK(v))) {
+   dev_err(>dev,
+   "hw-planes property: '%d' used more 
than once.\n",
+   v);
+   return -EINVAL;
+   }
+   clear_bit(v, _plane_mask);
+
+   if (index == 0) {
+   plane->plane[i].main_id = v;
+   } else if (index == 1) {
+   plane->plane[i].aux_id = v;
+   plane->plane[i].is_virtual = true;
+   } else if (index > 1) {
+   dev_err(>dev,
+   "hw-planes property: more than 2 values 
specified.\n");
+   return -EINVAL;
+   }
+   index++;
+   }
+
+   of_property_for_each_u32(ep, "hw-crtcs", prop, cur, v) {
+   if (v >= num_ovls) {
+   dev_err(>dev,
+   "hw-crtcs property: '%d' 
out-of-range.\n",
+   v);
+   return -EINVAL;
+   }
+   plane->plane[i].crtc_mask |= 1 << v;
+   }
+   }
+
+   num_planes = i;
+
+   if (num_planes) {
+   dev_dbg(>dev, "Plane definitions found from DT:");
+   for (i = 0; i < num_planes; i++) {
+   if (plane->plane[i].is_virtual) {
+   dev_dbg(>dev,
+   "plane%d: virtual hw-planes: %d, %d 
crtc_mask: 0x%04x",
+   i, plane->plane[i].main_id,
+   plane->plane[i].aux_id,
+   plane->plane[i].crtc_mask);
+   } else {
+   dev_dbg(>dev,
+   "plane%d: hw-planes: %d crtc_mask: 
0x%04x",
+   i, plane->plane[i].main_id,
+   plane->plane[i].crtc_mask);
+   }
+   }
+   }
+

[PATCH v2 2/3 drm: Check property/enum name length

[Ville Syrjala]

From: Ville Syrjälä 

Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.

v2: drm_property_create() returns a pointer

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_property.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index fe8627fb7ae6..c37ac41125b5 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -78,6 +78,9 @@ struct drm_property *drm_property_create(struct drm_device 
*dev, int flags,
struct drm_property *property = NULL;
int ret;
 
+   if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+   return NULL;
+
property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
if (!property)
return NULL;
@@ -372,6 +375,9 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
 {
struct drm_property_enum *prop_enum;
 
+   if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+   return -EINVAL;
+
if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;
-- 
2.16.1

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

Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express

[Robin Murphy]

On 02/03/18 12:37, Linus Walleij wrote:

On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy  wrote:

On 02/03/18 09:09, Linus Walleij wrote:



Also the Versatile Express CLCD on the motherboard has
a dedicated video memory, and cannot use CMA (ha! complex!)
and I will need to figure out a way to work around that.
The CLCDs synthesized on the core tiles for CA9 work
fine with this though.


Out of curiosity, what's the issue with declaring the VRAM as a CMA region?
That's certainly worked for stuff like local RAM on FPGA tiles in the past,
and I can't think offhand of any way in which VExpress is wildly different
(but I am of course open to being wrong...)


There is nothing wrong with that apart from my ignorance
of that solution. So thanks! :D

My experience with CMA is limited to using the 7 areas
that are defined by default in Kconfig and the DRM helpers
just plugging in on the front.

Do you have some pointers? Is this something I can
handily just set up in the device tree?


It should be - the inner workings of dma-{coherent,contiguous} are a 
maze of twisty little passages, all alike, and it'll take me a while to 
page the details back in, but IIRC it's mostly just a case of having a 
reserved-memory node covering the VRAM with the right combination of 
magic properties for rmem_dma_setup() to pick up, such that it gets 
assigned as the CLCD's private region. The subsequent "just plugging in" 
aspect doesn't change, it just makes allocations start taking this route 
under the covers:


  drm_gem_cma_create()
dma_alloc_wc()
  dma_alloc_attrs()
dma_alloc_from_dev_coherent()

I could have sworn I've exchanged relevant FPGA DT fragments with Liviu 
in the past, but now I can't seem to find one to refer back to :(


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

[Patch 1/4] dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt

[Benoit Parrot]

Add common DISPC bindings into the top level bindings file.
Move common bindings here instead of having multiple copies of
the same information in all of the variant specific files.

Signed-off-by: Benoit Parrot 
---
 Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt  | 5 -
 Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt  | 7 +++
 Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt | 4 
 Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt | 4 
 Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt | 4 
 Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 
 6 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt 
b/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt
index 91279f1060fe..c30f9ec189ed 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt
+++ b/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt
@@ -47,11 +47,6 @@ Required properties:
 - clocks: handle to fclk
 - clock-names: "fck"
 
-Optional properties:
-- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
limit
-   in bytes per second
-
-
 HDMI
 
 
diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt 
b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
index e1ef29569338..249e588d7865 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
+++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
@@ -21,6 +21,13 @@ a RGB pixel stream to encoders.
 The encoder modules encode the received RGB pixel stream to a video output like
 HDMI, MIPI DPI, etc.
 
+DISPC
+-
+
+Optional properties:
+- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
limit
+   in bytes per second
+
 Video Ports
 ---
 
diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt 
b/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt
index ee867c4d1152..afcd5a86c6a4 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt
+++ b/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt
@@ -28,10 +28,6 @@ Required properties:
 - ti,hwmods: "dss_dispc"
 - interrupts: the DISPC interrupt
 
-Optional properties:
-- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
limit
-   in bytes per second
-
 
 RFBI
 
diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt 
b/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt
index cd02516a40b6..dc66e1447c31 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt
+++ b/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt
@@ -37,10 +37,6 @@ Required properties:
 - clocks: handle to fclk
 - clock-names: "fck"
 
-Optional properties:
-- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
limit
-   in bytes per second
-
 
 RFBI
 
diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt 
b/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt
index 0f85f6b3a5a8..bc624dbd 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt
+++ b/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt
@@ -36,10 +36,6 @@ Required properties:
 - clocks: handle to fclk
 - clock-names: "fck"
 
-Optional properties:
-- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
limit
-   in bytes per second
-
 
 RFBI
 
diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt 
b/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt
index 20861218649f..118a486c47bb 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt
+++ b/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt
@@ -36,10 +36,6 @@ Required properties:
 - clocks: handle to fclk
 - clock-names: "fck"
 
-Optional properties:
-- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
limit
-   in bytes per second
-
 
 RFBI
 
-- 
2.9.0

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

[Bug 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

--- Comment #8 from tempel.jul...@gmail.com ---
Video which shows the artifacts:
https://youtu.be/it3d6BjpZjU
(can also be quite worse when doing stuff)

It happens with every desktop environment with and without enabled OGL
compositor. In the video, it's KDE Plasma on Xorg.
But there is no difference with a Wayland session, the artifacts there are the
same.

You are correct that the display's own edid information doesn't know any other
refreshrate than 59.95Hz.
However, these Korean import display's are very often used with higher
refreshrates because their panels allow this without incompatible scaler in
between. With the old display stack, I can even set 85Hz without any issues.

75Hz is also not very uncommon for some 2560x1440p IPS displays, I suppose
there is the realistic possibility that also displays which have a 2560x1440
75Hz resolution in their original edid are affected by this bug (since the old
stack isn't affected, I'm quite sure it's some kind of bug).

-- 
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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

--- Comment #7 from tempel.jul...@gmail.com ---
Created attachment 137754
  --> https://bugs.freedesktop.org/attachment.cgi?id=137754=edit
xrandr.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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

--- Comment #6 from tempel.jul...@gmail.com ---
Created attachment 137753
  --> https://bugs.freedesktop.org/attachment.cgi?id=137753=edit
Xorg.0.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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

--- Comment #5 from tempel.jul...@gmail.com ---
Created attachment 137752
  --> https://bugs.freedesktop.org/attachment.cgi?id=137752=edit
dmesg.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

Re: [PATCH] drm/bridge: sii902x: Fall back to standard modes

[Linus Walleij]

On Fri, Mar 2, 2018 at 9:07 AM, Ville Syrjälä
 wrote:
> On Thu, Mar 01, 2018 at 11:12:15PM +0100, Linus Walleij wrote:
>> On Thu, Mar 1, 2018 at 10:18 PM, Ville Syrjälä
>>  wrote:
>> > On Thu, Mar 01, 2018 at 10:02:55PM +0100, Linus Walleij wrote:
>> >> Hm, hard to get review feedback on this one.
>> >>
>> >> It gives me proper video on an ARM Versatile Express utilizing the
>> >> bridge driver with a plugged in DVI-to-VGA dongle with the new
>> >> PL111 DRI driver.
>> >>
>> >> Liviu? Pawel?
>> >>
>> >> Some ACK is fine to know I am doing the right thing :)
>> >
>> > Why isn't the probe helper's noedid fallback working?
>>
>> Where is that in the call chain?
>>
>> The problem I have is that the bridge is there, it gets properly
>> initialized and used as connector and all. The only problem is
>> that the DDI I2C portion of it is not working, so no modes are
>> really added from the struct drm_connector_helper_funcs
>> .get_modes() callback.
>
> The helper is what calls .get_modes(), and it has a noedid
> fallback for mode count==0.

OK I'll debug from here and try to see what's wrong.

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

[PATCH 2/3] drm: Check property/enum name length

[Ville Syrjala]

From: Ville Syrjälä 

Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_property.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index fe8627fb7ae6..f062adf21b9c 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -78,6 +78,9 @@ struct drm_property *drm_property_create(struct drm_device 
*dev, int flags,
struct drm_property *property = NULL;
int ret;
 
+   if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+   return -EINVAL;
+
property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
if (!property)
return NULL;
@@ -372,6 +375,9 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
 {
struct drm_property_enum *prop_enum;
 
+   if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+   return -EINVAL;
+
if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;
-- 
2.13.6

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

[PATCH v2 3/3] drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property

[Ville Syrjala]

From: Ville Syrjälä 

BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
traditional non-constant luminance and a more complicate constant
luminance one. Add an enum value for the constant luminance variant
as well in case someone has hardware supporting it.

v2: Reduce the enum name to fit within the 31 character uapi limit

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
CC: Uma Shankar 
Cc: Shashank Sharma 
Cc: Jyri Sarha 
Signed-off-by: Ville Syrjälä 
Acked-by: Harry Wentland  #v1
---
 drivers/gpu/drm/drm_color_mgmt.c | 1 +
 include/drm/drm_color_mgmt.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 4ff064623836..cc28c32399af 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -358,6 +358,7 @@ static const char * const color_encoding_name[] = {
[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+   [DRM_COLOR_YCBCR_BT2020_CONST] = "ITU-R BT.2020 YCbCr const",
 };
 
 static const char * const color_range_name[] = {
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index b3b6d302ca8c..175943c87d5b 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -41,7 +41,8 @@ int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
 enum drm_color_encoding {
DRM_COLOR_YCBCR_BT601,
DRM_COLOR_YCBCR_BT709,
-   DRM_COLOR_YCBCR_BT2020,
+   DRM_COLOR_YCBCR_BT2020, /* non-constant luminance */
+   DRM_COLOR_YCBCR_BT2020_CONST, /* constant luminance */
DRM_COLOR_ENCODING_MAX,
 };
 
-- 
2.13.6

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

[PATCH 1/3] drm: Don't create properties without names

[Ville Syrjala]

From: Ville Syrjälä 

Creating a property that doesn't have a name makes no sense to me. Don't
allow it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_property.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index bae50e6b819d..fe8627fb7ae6 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -99,10 +99,8 @@ struct drm_property *drm_property_create(struct drm_device 
*dev, int flags,
property->num_values = num_values;
INIT_LIST_HEAD(>enum_list);
 
-   if (name) {
-   strncpy(property->name, name, DRM_PROP_NAME_LEN);
-   property->name[DRM_PROP_NAME_LEN-1] = '\0';
-   }
+   strncpy(property->name, name, DRM_PROP_NAME_LEN);
+   property->name[DRM_PROP_NAME_LEN-1] = '\0';
 
list_add_tail(>head, >mode_config.property_list);
 
-- 
2.13.6

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

Re: [PATCH] drm/bridge/synopsys: dsi: readl_poll_timeout return value clean up

[Philippe CORNU]

Hi Andrzej,


On 03/02/2018 11:21 AM, Andrzej Hajda wrote:
> On 01.03.2018 10:00, Philippe CORNU wrote:
>> Hi Archit, Andrzej & Laurent,
>>
>> May I ask you please your feedback on this small patch?
>> Many thanks,
>>
>> Philippe :-)
>>
>> On 02/04/2018 10:36 PM, Philippe Cornu wrote:
>>> The readl_poll_timeout() return value is 0 in case of success
>>> so it is better to detect errors without taking care of the
>>> return value sign.
>>>
>>> Signed-off-by: Philippe Cornu 
> 
> The patch is of course correct. However I am not sure if necessary. For
> sure functionally it does not change anything.
> AFAIK kernel CodingStyle says nothing about it, so I suppose it is
> matter of personal taste.

I sent this tiny patch in order to homogenize the dw mipi driver because 
there were both cases "if (ret)" & "if (ret < 0)" in the source code.

I did not really find a preferred way in the kernel source code so I 
selected what sounds the best to me ie "if (ret)" but it is not a 
problem to make another patch for "if (ret < 0)" everywhere :-)

In any case, the most important from my pov is to have a homogeneous 
source code :-)

Does anyone have a preferred choice between "if (ret)" & "if (ret < 0)" 
after a "ret = readl_poll_timeout()"?

> Anyway I can give it:
> Reviewed-by: Andrzej Hajda 

Many thanks,
Philippe :)

> 
>   --
> Regards
> Andrzej
> 
>>> ---
>>>drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 +-
>>>1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> index 65aeb3f78b48..4d0e8471a15c 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> @@ -342,7 +342,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
>>> dw_mipi_dsi *dsi, u32 hdr_val)
>>> ret = qq(dsi->base + DSI_CMD_PKT_STATUS,
>>>  val, !(val & GEN_CMD_FULL), 1000,
>>>  CMD_PKT_STATUS_TIMEOUT_US);
>>> -   if (ret < 0) {
>>> +   if (ret) {
>>> dev_err(dsi->dev, "failed to get available command FIFO\n");
>>> return ret;
>>> }
>>> @@ -353,7 +353,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
>>> dw_mipi_dsi *dsi, u32 hdr_val)
>>> ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
>>>  val, (val & mask) == mask,
>>>  1000, CMD_PKT_STATUS_TIMEOUT_US);
>>> -   if (ret < 0) {
>>> +   if (ret) {
>>> dev_err(dsi->dev, "failed to write command FIFO\n");
>>> return ret;
>>> }
>>> @@ -385,7 +385,7 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
>>> ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
>>>  val, !(val & GEN_PLD_W_FULL), 1000,
>>>  CMD_PKT_STATUS_TIMEOUT_US);
>>> -   if (ret < 0) {
>>> +   if (ret) {
>>> dev_err(dsi->dev,
>>> "failed to get available write payload FIFO\n");
>>> return ret;
>>> @@ -716,13 +716,13 @@ static void dw_mipi_dsi_dphy_enable(struct 
>>> dw_mipi_dsi *dsi)
>>>
>>> ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS, val,
>>>  val & PHY_LOCK, 1000, PHY_STATUS_TIMEOUT_US);
>>> -   if (ret < 0)
>>> +   if (ret)
>>> DRM_DEBUG_DRIVER("failed to wait phy lock state\n");
>>>
>>> ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
>>>  val, val & PHY_STOP_STATE_CLK_LANE, 1000,
>>>  PHY_STATUS_TIMEOUT_US);
>>> -   if (ret < 0)
>>> +   if (ret)
>>> DRM_DEBUG_DRIVER("failed to wait phy clk lane stop state\n");
>>>}
>>>
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: omapdrm: displays: panel-dsi-cm: Fix field access before set

[Tomi Valkeinen]

On 01/03/18 22:02, Laurent Pinchart wrote:
> The driver accesses the ddata->in field before it gets set in the
> dsicm_connect() function. Use the local in pointer variable instead.
> 
> Fixes: 7877632b4cd0 ("drm: omapdrm: displays: Get panel source at connect 
> time")
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Tomi,
> 
> This patch fixes a bug in a commit from your omapdrm-next branch that
> hasn't been merged upstream yet. I'll let you decide whether you want to
> squash it with the offending commit (and thus rebase) or apply it on
> top. Sorry for screwing up :-/

Thanks, I've picked this up and applied on top of omapdrm-next.

 Tomi

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